perm filename COMSCH.MSG[SCH,LSP] blob sn#886457 filedate 1990-08-17 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00452 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00076 00002	
C00077 00003	∂17-Jun-89  2139	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #139 
C00081 00004	∂18-Jun-89  2215	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #140 
C00087 00005	∂19-Jun-89  1414	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	another change for R4RS peek-char   
C00092 00006	∂19-Jun-89  1851	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	another change for R4RS peek-char
C00098 00007	∂19-Jun-89  1852	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	another change for R4RS peek-char   
C00106 00008	∂19-Jun-89  1906	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	another change for R4RS peek-char
C00112 00009	∂19-Jun-89  1907	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	another change for R4RS peek-char   
C00119 00010	∂19-Jun-89  2242	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #141 
C00129 00011	∂20-Jun-89  0721	@mc.lcs.mit.edu:shaff@sesame.stanford.edu 	Useful, but not essential  
C00133 00012	∂20-Jun-89  0754	@mc.lcs.mit.edu:shaff@sesame.stanford.edu 	Useful, but not essential: the reference  
C00135 00013	∂20-Jun-89  1323	@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu 	RE: Sticks and stones
C00138 00014	∂20-Jun-89  1424	@mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:jinx@zurich.ai.mit.edu 	Sticks and stones  
C00142 00015	∂20-Jun-89  1428	@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:mkatz@sesame.stanford.edu 	Sticks and stones    
C00147 00016	∂20-Jun-89  1437	@MC.lcs.mit.edu,@life.ai.mit.edu:Stewart.Clamen@clamen.avalon.cs.cmu.edu 	LIST-REF and LIST-TAIL    
C00150 00017	∂20-Jun-89  1500	@mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:cph@ZURICH.ai.mit.edu 	Sticks and stones   
C00152 00018	∂20-Jun-89  1542	@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:mkatz@sesame.stanford.edu 	Sticks and stones    
C00155 00019	∂20-Jun-89  1644	@mc.lcs.mit.edu,@life.ai.mit.edu,@fog.cs.uoregon.edu:will@cs.uoregon.edu 	LIST-REF, LIST-TAIL  
C00158 00020	∂20-Jun-89  2306	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #142 
C00170 00021	∂21-Jun-89  1450	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@zurich.ai.mit.edu 	Librarian    
C00173 00022	∂21-Jun-89  1457	@mc.lcs.mit.edu,@life.ai.mit.edu:Gateley@tilde.csc.ti.com 	Re: LIST-REF and LIST-TAIL
C00177 00023	∂21-Jun-89  2238	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #143 
C00185 00024	∂22-Jun-89  0706	@mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu 	Useful, but not essential
C00189 00025	∂22-Jun-89  1210	@MC.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	LIST-REF and LIST-TAIL   
C00194 00026	∂22-Jun-89  1257	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	[chaynes@iuvax.cs.indiana.edu: [will@cs.uoregon.edu: LIST-REF, LIST-TAIL]]
C00199 00027	∂22-Jun-89  1913	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Responses to a month of mail 
C00213 00028	∂22-Jun-89  2146	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #144 
C00216 00029	∂23-Jun-89  0934	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	Responses to a month of mail    
C00221 00030	∂23-Jun-89  1328	@mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu 	Responses to a month of mail  
C00225 00031	∂26-Jun-89  0648	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #145 
C00232 00032	∂26-Jun-89  2154	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Responses to a month of mail  
C00235 00033	∂26-Jun-89  2155	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #146 
C00237 00034	∂27-Jun-89  1311	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Responses to responses to responses    
C00243 00035	∂27-Jun-89  1419	@MC.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Responses to responses to responses
C00248 00036	∂27-Jun-89  2001	@MC.lcs.mit.edu,@ZERMATT.lcs.mit.edu:SCHREQ@MC.lcs.mit.edu 	testing   
C00250 00037	∂27-Jun-89  2147	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #147 
C00253 00038	∂28-Jun-89  0847	@mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Responses to a month of mail  
C00259 00039	∂28-Jun-89  0940	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	Responses to responses to responses  
C00265 00040	∂28-Jun-89  1125	@mc.lcs.mit.edu,@ZURICH.ai.mit.edu:mkatz@sesame.stanford.edu 	Declare proposal  
C00268 00041	∂28-Jun-89  1345	@mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com 	Re: A month of mail... 
C00273 00042	∂28-Jun-89  2147	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #148 
C00276 00043	∂28-Jun-89  2257	@mc.lcs.mit.edu:shap@sid.stanford.edu 	A month of mail...   
C00279 00044	∂29-Jun-89  0533	@mc.lcs.mit.edu,@mbunix.mitre.org:ramsdell@linus.mitre.org 	Make the semantics of internal and external definitions identical
C00282 00045	∂29-Jun-89  0956	@MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Responses to a month of mail  
C00288 00046	∂29-Jun-89  1254	@mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com 	Re: A month of mail... 
C00292 00047	∂29-Jun-89  1434	@mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com 	Re: Responses to a month of mail 
C00297 00048	∂29-Jun-89  2112	@mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu 	A month of mail...  
C00303 00049	∂29-Jun-89  2129	@mc.lcs.mit.edu,@relay.cs.net,@mojave.stanford.edu:shap@sid.stanford.edu 	A month of mail...   
C00305 00050	∂30-Jun-89  1052	@mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu 	Draft agenda for 3rd IEEE Scheme standard meeting
C00308 00051	∂30-Jun-89  1229	@mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Location for 3rd IEEE Scheme standard meeting
C00310 00052	∂30-Jun-89  1535	@mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@tekchips.labs.tek.com 	R↑3.95RS: open-input-file open-output-file 
C00314 00053	∂30-Jun-89  2123	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #149 
C00319 00054	∂01-Jul-89  0447	@mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	R↑3.95RS: open-input-file open-output-file   
C00324 00055	∂01-Jul-89  2126	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #150 
C00326 00056	∂02-Jul-89  1434	@mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu 	R↑3.95RS: open-input-file open-output-file   
C00330 00057	∂02-Jul-89  2200	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #151 
C00359 00058	∂03-Jul-89  2219	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #152 
C00382 00059	∂04-Jul-89  1707	@mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com 	R↑3.95RS: open-input-file open-output-file 
C00386 00060	∂05-Jul-89  1411	@mc.lcs.mit.edu,@decwrl.pa.dec.com:jmiller@crl.dec.com 	Responses to a month of mail 
C00389 00061	∂05-Jul-89  1452	@mc.lcs.mit.edu,@decwrl.pa.dec.com:jmiller@crl.dec.com 	R↑3.95RS: open-input-file open-output-file  
C00392 00062	∂05-Jul-89  1835	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Re: R↑3.95RS: open-input-file open-output-file   
C00395 00063	∂05-Jul-89  1856	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Curried definition syntax    
C00397 00064	∂05-Jul-89  1919	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Uniform definition semantics 
C00403 00065	∂05-Jul-89  1941	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Reserving a character for experimentation   
C00409 00066	∂05-Jul-89  2048	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Assignment to standard variables  
C00420 00067	∂05-Jul-89  2227	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #153 
C00427 00068	∂05-Jul-89  2230	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Fluid binding 
C00438 00069	∂05-Jul-89  2240	@mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Assignment to standard variables   
C00452 00070	∂06-Jul-89  0713	@MC.lcs.mit.edu:jmiller@crl.dec.com 	Reserving a character for experimentation  
C00456 00071	∂06-Jul-89  0730	@MC.lcs.mit.edu:sfk@hplb.hpl.hp.com 	Re: Fluid binding 
C00462 00072	∂06-Jul-89  0843	@mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Fluid binding  
C00465 00073	∂06-Jul-89  1012	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	Assignment to standard variables
C00480 00074	∂06-Jul-89  1035	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	Fluid binding    
C00493 00075	∂06-Jul-89  1043	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	Fluid binding    
C00501 00076	∂06-Jul-89  1058	@MC.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Fluid binding  
C00508 00077	∂06-Jul-89  1637	@mc.lcs.mit.edu,@ZURICH.ai.mit.edu:ramsdell@linus.mitre.org 	An International Character Set for R4RS
C00511 00078	∂06-Jul-89  1902	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Re: Assignment to standard variables   
C00513 00079	∂06-Jul-89  2228	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #154 
C00545 00080	∂07-Jul-89  1700	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Re: Reserving a character for experimentation    
C00550 00081	∂07-Jul-89  1740	@mc.lcs.mit.edu,@ti.com:bartley@m2.csc.ti.com 	Responses to a month of mail
C00554 00082	∂08-Jul-89  1717	@mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu 	Fluid binding   
C00557 00083	∂08-Jul-89  1732	@mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu 	Assignment to standard variables    
C00563 00084	∂08-Jul-89  1751	@mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu 	Reserving a character for experimentation
C00566 00085	∂08-Jul-89  2224	@mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Fluid binding  
C00570 00086	∂09-Jul-89  2121	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #155 
C00573 00087	∂10-Jul-89  1447	@MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	R↑3.95RS: open-input-file open-output-file   
C00576 00088	∂10-Jul-89  2055	@mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com 	LIST-REF, revisited   
C00580 00089	∂11-Jul-89  0857	@mc.lcs.mit.edu,@ZURICH.ai.mit.edu:ramsdell@linus.mitre.org 	International character sets.
C00600 00090	∂11-Jul-89  0951	@mc.lcs.mit.edu,@ZURICH.ai.mit.edu:mkatz@sesame.stanford.edu 	Regularization of list, vector, and string procedures
C00613 00091	∂11-Jul-89  1100	@MC.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu 	Fluid binding  
C00615 00092	∂11-Jul-89  1105	@MC.lcs.mit.edu,@ZURICH.ai.mit.edu:shap@sid.stanford.edu 	International character sets.   
C00618 00093	∂11-Jul-89  1136	@mc.lcs.mit.edu,@ZURICH.ai.mit.edu:jar@annabel.stanford.edu 	Regularization of list, vector, and string procedures 
C00622 00094	∂11-Jul-89  2148	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #156 
C00624 00095	∂12-Jul-89  1325	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Fluid binding 
C00635 00096	∂12-Jul-89  1400	@mc.lcs.mit.edu,@LIFE.ai.mit.edu:cph@zurich.ai.mit.edu 	scheme mailing list
C00639 00097	∂12-Jul-89  1433	@mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com 	R↑3.95RS: open-input-file open-output-file
C00643 00098	∂12-Jul-89  1444	@mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com 	EQV? and =  
C00646 00099	∂12-Jul-89  1716	@mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	last call: changes for R4RS
C00655 00100	∂12-Jul-89  1731	@mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	legion 
C00667 00101	∂12-Jul-89  1745	@mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	Regularization of list, vector, and string procedures    
C00676 00102	∂12-Jul-89  2216	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #157 
C00688 00103	∂13-Jul-89  0537	@mc.lcs.mit.edu,@life.ai.mit.edu:ramsdell@linus.mitre.org 	fluid variables 
C00691 00104	∂13-Jul-89  1137	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	last call: changes for R4RS   
C00695 00105	∂13-Jul-89  1141	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	Regularization of list, vector, and string procedures  
C00705 00106	∂13-Jul-89  1156	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	last call: changes for R4RS
C00712 00107	∂13-Jul-89  1202	@mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu 	legion  
C00718 00108	∂13-Jul-89  1233	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	Correction  
C00721 00109	∂13-Jul-89  1238	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Fluid binding   
C00733 00110	∂13-Jul-89  1446	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	last call: changes for R4RS  
C00738 00111	∂13-Jul-89  1520	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	last call: changes for R4RS
C00744 00112	∂13-Jul-89  1537	@mc.lcs.mit.edu,@LIFE.ai.mit.edu:gjs@hpesogg.hp.com 	last call: changes for R4RS
C00747 00113	∂13-Jul-89  1622	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	last call: changes for R4RS   
C00750 00114	∂13-Jul-89  1635	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Confusion  
C00757 00115	∂13-Jul-89  1721	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	last call: changes for R4RS  
C00760 00116	∂13-Jul-89  1726	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	last call: changes for R4RS   
C00764 00117	∂13-Jul-89  1734	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: evaluation order  
C00767 00118	∂13-Jul-89  1747	@mc.lcs.mit.edu,@LIFE.ai.mit.edu:jinx@hpesogg.hp.com 	last call: changes for R4RS    
C00771 00119	∂13-Jul-89  1756	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com 	Re: last call: changes for R4RS 
C00775 00120	∂13-Jul-89  1812	@mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com 	Arg evaluation order   
C00780 00121	∂13-Jul-89  1820	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Arg evaluation order 
C00785 00122	∂13-Jul-89  1925	@mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com 	Re:  Arg evaluation order   
C00793 00123	∂13-Jul-89  2140	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Arg evaluation order 
C00800 00124	∂13-Jul-89  2211	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #158 
C00804 00125	∂14-Jul-89  0433	@mc.lcs.mit.edu,@life.ai.mit.edu:gjs@hpesogg.hp.com 	D. Press, Ing.   
C00811 00126	∂14-Jul-89  0903	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	Released Report
C00814 00127	∂15-Jul-89  0907	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	Released Report
C00817 00128	∂15-Jul-89  0933	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #159 
C00820 00129	∂15-Jul-89  1102	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Arg evaluation order 
C00826 00130	∂15-Jul-89  1210	@mc.lcs.mit.edu,@LIFE.ai.mit.edu:gls@think.com 	[postmaster@ames.UUCP: Returned mail: User unknown] 
C00836 00131	∂15-Jul-89  1217	@mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu 	Minutes of the 3rd IEEE Scheme Working Group meeting  
C00847 00132	∂15-Jul-89  1323	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	Force & Delay manual reorganization
C00850 00133	∂15-Jul-89  1328	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	Distinct types for continuations?  
C00853 00134	∂15-Jul-89  2255	@mc.lcs.mit.edu,@LIFE.ai.mit.edu:shaff@sesame.stanford.edu 	Arg evaluation order
C00856 00135	∂15-Jul-89  2315	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #160 
C00868 00136	∂16-Jul-89  1000	@mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com 	[Scheme-Request@mc.lcs.mit.edu: Scheme Digest #158] 
C00872 00137	∂16-Jul-89  1341	@mc.lcs.mit.edu,@life.ai.mit.edu:danvy@freja.diku.dk 	Re:  Distinct types for continuations?   
C00876 00138	∂16-Jul-89  2144	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #161 
C00900 00139	∂17-Jul-89  0910	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	[gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]  
C00910 00140	∂17-Jul-89  1059	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	[gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]    
C00920 00141	∂17-Jul-89  1337	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	Distinct types for continuations?  
C00923 00142	∂17-Jul-89  1443	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
C00931 00143	∂17-Jul-89  1517	@mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu 	Distinct types for continuations?
C00935 00144	∂17-Jul-89  1533	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	Numbers  
C00941 00145	∂17-Jul-89  1603	@MC.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
C00946 00146	∂17-Jul-89  1757	@MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
C00952 00147	∂17-Jul-89  1905	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
C00958 00148	∂17-Jul-89  2126	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #162 
C00961 00149	∂18-Jul-89  0833	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
C00972 00150	∂18-Jul-89  0901	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	Distinct types for continuations?  
C00977 00151	∂18-Jul-89  0925	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	ELSE in Scheme 
C00981 00152	∂18-Jul-89  1014	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	Numbers  
C00990 00153	∂18-Jul-89  1206	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
C00993 00154	∂18-Jul-89  1528	cph@zurich.ai.mit.edu 	test message
C00994 00155	∂18-Jul-89  2204	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #163 
C00997 00156	∂19-Jul-89  2155	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #164 
C01000 00157	∂20-Jul-89  1457	@mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu 	BYTES (a.k.a. 1's and 0's)
C01004 00158	∂20-Jul-89  1631	@mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu 	Bitwise logical operations    
C01009 00159	∂21-Jul-89  0124	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: last call: changes for R4RS 
C01013 00160	∂21-Jul-89  0125	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: last call: changes for R4RS 
C01020 00161	∂21-Jul-89  0342	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: legion  
C01026 00162	∂21-Jul-89  0346	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Regularization of list, vector, and string procedures
C01032 00163	∂21-Jul-89  0453	ramsdell@linus.mitre.org 	Priorities    
C01036 00164	∂21-Jul-89  0553	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: ELSE in Scheme    
C01039 00165	∂21-Jul-89  0807	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Fluid binding
C01047 00166	∂21-Jul-89  0812	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	last call: changes for R4RS    
C01056 00167	∂21-Jul-89  1019	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	legion
C01061 00168	∂21-Jul-89  1220	cph@zurich.ai.mit.edu 	test   
C01062 00169	∂21-Jul-89  1449	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Regularization of list, vector, and string procedures   
C01069 00170	∂21-Jul-89  1642	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	last call: changes for R4RS
C01075 00171	∂21-Jul-89  1649	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	ELSE in Scheme 
C01079 00172	∂21-Jul-89  1854	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	last call: changes for R4RS  
C01083 00173	∂21-Jul-89  1856	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Bitwise logical operations  
C01085 00174	∂21-Jul-89  2101	@mc.lcs.mit.edu,@life.ai.mit.edu:jmiller@crl.dec.com 	Regularization of list, vector, and string procedures   
C01095 00175	∂21-Jul-89  2104	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Fluid binding   
C01100 00176	∂21-Jul-89  2316	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
C01112 00177	∂21-Jul-89  2322	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Fluid binding
C01116 00178	∂21-Jul-89  2331	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Regularization of list, vector, and string procedures   
C01122 00179	∂23-Jul-89  0001	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #167 
C01125 00180	∂24-Jul-89  0904	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
C01131 00181	∂24-Jul-89  0945	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	Regularization of list, vector, and string procedures  
C01137 00182	∂24-Jul-89  0948	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	Regularization of list, vector, and string procedures    
C01141 00183	∂24-Jul-89  1216	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@mrloog.la.tek.com 	Re: Regularization of apply Show of hands    
C01146 00184	∂24-Jul-89  1255	@mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu 	Regularization of list, vector, and string procedures
C01150 00185	∂24-Jul-89  1549	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
C01157 00186	∂25-Jul-89  1259	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
C01163 00187	∂25-Jul-89  1454	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Regularization of apply Show of hands   
C01167 00188	∂25-Jul-89  1524	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	Regularization of apply Show of hands    
C01172 00189	∂25-Jul-89  1909	@mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com 	INF/SUP/MIN/MAX, LIST?/PROPER-LIST?, APPLY    
C01186 00190	∂25-Jul-89  1915	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Regularization of apply (long) 
C01197 00191	∂25-Jul-89  2003	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
C01201 00192	∂26-Jul-89  0359	@mc.lcs.mit.edu,@life.ai.mit.edu:Alan@reagan.ai.mit.edu 	INF/SUP/MIN/MAX   
C01211 00193	∂26-Jul-89  0408	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #169 
C01214 00194	∂26-Jul-89  0617	ramsdell@linus.mitre.org 	INF/SUP/MIN/MAX    
C01216 00195	∂26-Jul-89  0745	wand@corwin.ccs.northeastern.edu 	INF/SUP/MIN/MAX 
C01219 00196	∂26-Jul-89  1103	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	INF/SUP/MIN/MAX  
C01228 00197	∂26-Jul-89  1119	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	INF/SUP/MIN/MAX    
C01231 00198	∂26-Jul-89  1122	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	INF/SUP/MIN/MAX follow-up  
C01234 00199	∂26-Jul-89  1215	@mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com 	INF/SUP/MIN/MAX 
C01246 00200	∂26-Jul-89  1334	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	INF/SUP/MIN/MAX    
C01254 00201	∂26-Jul-89  1405	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	INF/SUP/MIN/MAX  
C01265 00202	∂26-Jul-89  1437	@mc.lcs.mit.edu,@life.ai.mit.edu:gjs@hpesogg.hp.com 	INF/SUP/MIN/MAX  
C01268 00203	∂26-Jul-89  1952	@mc.lcs.mit.edu,@life.ai.mit.edu:kempf@sun.com 	Please Remove    
C01271 00204	∂27-Jul-89  0855	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	INF/SUP/MIN/MAX  
C01281 00205	∂27-Jul-89  1106	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	INF/SUP/MIN/MAX and correct use of time   
C01286 00206	∂27-Jul-89  1116	@mc.lcs.mit.edu,@life.ai.mit.edu:wand@corwin.ccs.northeastern.edu 	INF/SUP/MIN/MAX   
C01301 00207	∂27-Jul-89  1122	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@mrloog.la.tek.com 	Re: Regularization of apply (long)  
C01307 00208	∂27-Jul-89  1209	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	Multiple Values for R5RS (VERY LONG)    
C01323 00209	∂28-Jul-89  1154	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Regularization of apply (long) 
C01328 00210	∂28-Jul-89  1219	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	INF/SUP/MIN/MAX 
C01332 00211	∂28-Jul-89  1401	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
C01342 00212	∂28-Jul-89  1635	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #170 
C01356 00213	∂28-Jul-89  1839	@mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu 	INF/SUP/MIN/MAX
C01359 00214	∂28-Jul-89  2243	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #171 
C01364 00215	∂30-Jul-89  1023	@mc.lcs.mit.edu,@life.ai.mit.edu:jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk 	Re: INF/SUP/MIN/MAX  
C01372 00216	∂01-Aug-89  1716	@mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu 	revisiting lambda*    
C01383 00217	∂01-Aug-89  1731	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #172 
C01386 00218	∂01-Aug-89  1806	@mc.lcs.mit.edu,@life.ai.mit.edu:hal@zurich.ai.mit.edu 	Take Two 
C01388 00219	∂01-Aug-89  1810	@mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu 	Take Two  
C01392 00220	∂02-Aug-89  0359	ramsdell@linus.mitre.org 	Re: Take Two  
C01394 00221	∂02-Aug-89  1357	@mc.lcs.mit.edu:dyb@iuvax.cs.indiana.edu 	Re:  Take Two
C01396 00222	∂06-Aug-89  1352	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	revisiting lambda*   
C01414 00223	∂07-Aug-89  1734	@mc.lcs.mit.edu,@LIFE.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	LIST?   
C01420 00224	∂07-Aug-89  1756	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	sequential order of evaluation   
C01425 00225	∂07-Aug-89  1949	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	R3.99RS issues (long message)    
C01444 00226	∂07-Aug-89  2002	@mc.lcs.mit.edu,@LIFE.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	MIN and MAX (long message)  
C01472 00227	∂07-Aug-89  2206	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	LIST?    
C01475 00228	∂07-Aug-89  2216	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	LIST? 
C01479 00229	∂07-Aug-89  2237	cph@zurich.ai.mit.edu 	Scheme Digest #174    
C01483 00230	∂08-Aug-89  0015	@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu 	RE: sequential evaluation of arguments   
C01488 00231	∂08-Aug-89  0241	@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:jinx@hpesogg.hp.com 	sequential evaluation of arguments   
C01492 00232	∂08-Aug-89  0258	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #175 
C01495 00233	∂08-Aug-89  1701	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	R3.99RS issues (else)    
C01498 00234	∂08-Aug-89  1733	@mc.lcs.mit.edu,@life.ai.mit.edu:hudak-paul@yale.edu 	Re: sequential order of evaluation  
C01502 00235	∂08-Aug-89  1910	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	LIST?
C01505 00236	∂08-Aug-89  2158	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	sequential order of evaluation
C01509 00237	∂08-Aug-89  2334	@mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:RPG@sail.stanford.edu 	re: sequential evaluation of arguments  
C01512 00238	∂09-Aug-89  0009	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	R3.99RS issues (macros in R4RS)    
C01516 00239	∂09-Aug-89  0012	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu 	RE: evaluation order rule
C01520 00240	∂09-Aug-89  0148	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: R3.99RS issues (else)  
C01523 00241	∂09-Aug-89  0355	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Dynamic variables
C01532 00242	∂09-Aug-89  0440	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	sequential order of evaluation 
C01536 00243	∂09-Aug-89  0657	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	MIN and MAX (long message)
C01542 00244	∂09-Aug-89  1545	@mc.lcs.mit.edu,@life.ai.mit.edu:bartlett@decwrl.dec.com 	First BASH Meeting    
C01563 00245	∂10-Aug-89  0646	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	R3.99RS issues (else)    
C01567 00246	∂10-Aug-89  0717	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	Dynamic variables   
C01571 00247	∂10-Aug-89  0725	@mc.lcs.mit.edu,@life.ai.mit.edu:jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk 	No mail    
C01574 00248	∂10-Aug-89  0846	ramsdell@linus.mitre.org 	Re: First BASH Meeting (Let's meet at POPL) 
C01578 00249	∂10-Aug-89  0902	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	R3.99RS issues (macros in R4RS)
C01582 00250	∂10-Aug-89  1246	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	Dynamic variables    
C01585 00251	∂10-Aug-89  1332	mkatz@sesame.stanford.edu 	First BASH Meeting (Let's meet at POPL)    
C01588 00252	∂10-Aug-89  1625	shaff@sesame.stanford.edu 	First BASH Meeting (macros) 
C01590 00253	∂12-Aug-89  0228	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	Re:  Dynamic variables 
C01594 00254	∂12-Aug-89  1538	@mc.lcs.mit.edu,@life.ai.mit.edu:danvy@gang-of-four.stanford.edu 	Re:  Dynamic variables  
C01598 00255	∂13-Aug-89  0537	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Dynamic variables 
C01601 00256	∂13-Aug-89  2354	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Dynamic variables 
C01605 00257	∂14-Aug-89  0829	@mc.lcs.mit.edu,@life.ai.mit.edu:halstead@crl.dec.com 	Re: Arg evaluation order 
C01610 00258	∂14-Aug-89  1634	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	Re: Dynamic variables  
C01613 00259	∂15-Aug-89  1812	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #177 
C01622 00260	∂20-Aug-89  1056	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Programmer-defined data types   
C01634 00261	∂21-Aug-89  1359	ramsdell@linus.mitre.org 	Multiple values for R4RS.    
C01638 00262	∂21-Aug-89  1450	cph@zurich.ai.mit.edu 	Multiple values for R4RS.  
C01642 00263	∂21-Aug-89  1539	harris%hplwhh@hplabs.hp.com 	Re: Multiple values for R4RS.  
C01648 00264	∂21-Aug-89  1543	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
C01654 00265	∂21-Aug-89  1652	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
C01657 00266	∂22-Aug-89  0445	ramsdell@linus.mitre.org 	Re: Multiple values for R4RS.     
C01664 00267	∂22-Aug-89  1052	harris%hplwhh@hplabs.hp.com 	Re: Multiple values for R4RS.  
C01666 00268	∂22-Aug-89  1130	ramsdell@linus.mitre.org 	Re: Multiple values for R4RS.     
C01671 00269	∂22-Aug-89  1150	mkatz@sesame.stanford.edu 	Multiple values for R4RS.   
C01673 00270	∂22-Aug-89  1221	dyb@iuvax.cs.indiana.edu 	Re:  Multiple values for R4RS.    
C01676 00271	∂22-Aug-89  1234	mkatz@sesame.stanford.edu 	Multiple values for R4RS.   
C01680 00272	∂22-Aug-89  1339	mkatz@sesame.stanford.edu 	Multiple values for R4RS.   
C01683 00273	∂22-Aug-89  1359	mkatz@sesame.stanford.edu 	Multiple values for R4RS.   
C01687 00274	∂22-Aug-89  1415	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
C01690 00275	∂22-Aug-89  1432	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
C01694 00276	∂22-Aug-89  1445	@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	Multiple values for R4RS.   
C01698 00277	∂22-Aug-89  1448	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
C01702 00278	∂22-Aug-89  1606	mkatz%sesame.stanford.edu@relay.cs.net 	Multiple values for R4RS.
C01705 00279	∂22-Aug-89  1634	cph@zurich.ai.mit.edu 	Multiple values for R4RS.  
C01711 00280	∂22-Aug-89  1713	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
C01714 00281	∂22-Aug-89  1740	@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	Multiple values for R4RS.   
C01718 00282	∂22-Aug-89  1824	@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	multiple values
C01722 00283	∂22-Aug-89  1838	@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	theology MAX and MIN    
C01728 00284	∂22-Aug-89  1842	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
C01735 00285	∂22-Aug-89  2037	dyb@iuvax.cs.indiana.edu 	Re:  Multiple values for R4RS.    
C01738 00286	∂22-Aug-89  2052	dyb@iuvax.cs.indiana.edu 	Re:  Multiple values for R4RS.    
C01741 00287	∂22-Aug-89  2105	dyb@iuvax.cs.indiana.edu 	Re:  multiple values    
C01743 00288	∂23-Aug-89  0440	jinx@hpesogg.hp.com 	multiple values    
C01748 00289	∂23-Aug-89  0458	ramsdell@linus.mitre.org 	Just add WITH-VALUES and VALUES.  
C01753 00290	∂23-Aug-89  0458	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
C01756 00291	∂23-Aug-89  0508	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
C01762 00292	∂23-Aug-89  0853	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
C01770 00293	∂23-Aug-89  0856	@mc.lcs.mit.edu:bawden.pa@xerox.com 	Numbers 
C01777 00294	∂23-Aug-89  0905	dyb@iuvax.cs.indiana.edu 	Re:  multiple values    
C01780 00295	∂23-Aug-89  0925	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #180 
C01788 00296	∂23-Aug-89  0939	dyb@iuvax.cs.indiana.edu 	Re:  Multiple values for R4RS.    
C01792 00297	∂23-Aug-89  1027	mkatz%sesame.stanford.edu@relay.cs.net 	Multiple values for R4RS.
C01797 00298	∂23-Aug-89  1102	cph@zurich.ai.mit.edu 	Multiple values for R4RS.  
C01801 00299	∂23-Aug-89  1104	KMP@stony-brook.scrc.symbolics.com 	Re: Multiple values for R4RS.     
C01808 00300	∂23-Aug-89  1104	mkatz@sesame.stanford.edu 	multiple values   
C01811 00301	∂23-Aug-89  1105	mkatz@sesame.stanford.edu 	multiple values   
C01815 00302	∂23-Aug-89  1118	mkatz@sesame.stanford.edu 	Multiple values for R4RS.   
C01818 00303	∂23-Aug-89  1118	@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	Multiple values for R4RS.   
C01821 00304	∂23-Aug-89  1126	jar@zurich.ai.mit.edu 	Just add WITH-VALUES and VALUES.
C01824 00305	∂23-Aug-89  1126	jar@zurich.ai.mit.edu 	Just add WITH-VALUES and VALUES.
C01828 00306	∂23-Aug-89  1134	@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	Multiple values for R4RS.   
C01832 00307	∂23-Aug-89  1200	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
C01835 00308	∂23-Aug-89  1200	jinx@hpesogg.hp.com 	multiple values    
C01838 00309	∂23-Aug-89  1201	jinx@hpesogg.hp.com 	Just add WITH-VALUES and VALUES.  
C01841 00310	∂23-Aug-89  1203	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
C01843 00311	∂23-Aug-89  1235	@relay.cs.net,@gateway.think.com:gls@THINK.COM 	Multiple values for R4RS.  
C01847 00312	∂23-Aug-89  1237	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
C01856 00313	∂23-Aug-89  1238	jinx@hpesogg.hp.com 	Just add WITH-VALUES and VALUES.  
C01861 00314	∂23-Aug-89  1407	gls@think.com 	theology MAX and MIN    
C01866 00315	∂23-Aug-89  1407	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
C01869 00316	∂23-Aug-89  1418	ramsdell@linus.mitre.org 	Amended WITH-VALUES and VALUES.   
C01875 00317	∂23-Aug-89  1502	dyb@iuvax.cs.indiana.edu 	Re:  Multiple values for R4RS.    
C01878 00318	∂23-Aug-89  1506	@zermatt.lcs.mit.edu:ziggy@HX.LCS.MIT.EDU 	RE: RECORDs proposal  
C01885 00319	∂23-Aug-89  1513	jinx@hpesogg.hp.com 	Amended WITH-VALUES and VALUES.   
C01888 00320	∂23-Aug-89  1516	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	INF/SUP/MIN/MAX  
C01897 00321	∂23-Aug-89  1519	dyb@iuvax.cs.indiana.edu 	Re:  Multiple values for R4RS.    
C01899 00322	∂23-Aug-89  1718	dyb@iuvax.cs.indiana.edu 	Re:  multiple values    
C01902 00323	∂23-Aug-89  1759	halstead@crl.dec.com     
C01909 00324	∂23-Aug-89  1954	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	MIN and MAX (long message) 
C01916 00325	∂23-Aug-89  2120	@mc.lcs.mit.edu,@life.ai.mit.edu:bawden.pa@xerox.com 	Programmer-defined data types  
C01923 00326	∂23-Aug-89  2230	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	Programmer-defined data types  
C01927 00327	∂24-Aug-89  0210	@mc.lcs.mit.edu:bawden.pa@xerox.com 	Numbers and Pork Rinds 
C01932 00328	∂24-Aug-89  0323	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #186 
C01940 00329	∂24-Aug-89  0428	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #182 
C01944 00330	∂24-Aug-89  0504	ramsdell@linus.mitre.org 	Revised WITH-VALUES and VALUES (I think we are near agreement!) 
C01949 00331	∂24-Aug-89  0600	@mc.lcs.mit.edu:bawden.pa@xerox.com 	Numbers 
C01954 00332	∂24-Aug-89  0629	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #183 
C01956 00333	∂24-Aug-89  1002	cph@zurich.ai.mit.edu 	Revised WITH-VALUES and VALUES (I think we are near agreement!)    
C01959 00334	∂24-Aug-89  1009	gls@think.com 	Multiple values for R4RS.
C01963 00335	∂24-Aug-89  1202	ramsdell@linus.mitre.org 	Re: Revised WITH-VALUES and VALUES (I think we are near agreement!)  
C01966 00336	∂25-Aug-89  0414	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	Programmer-defined data types
C01971 00337	∂25-Aug-89  1016	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers and Pork Rinds   
C01981 00338	∂25-Aug-89  1054	jinx@hpesogg.hp.com 	Revised WITH-VALUES and VALUES (I think we are near agreement!) 
C01984 00339	∂25-Aug-89  1151	ramsdell@linus.mitre.org 	Re: Revised WITH-VALUES and VALUES (I think we are near agreement!)  
C01988 00340	∂25-Aug-89  1221	jinx@hpesogg.hp.com 	Revised WITH-VALUES and VALUES (I think we are near agreement!) 
C01990 00341	∂25-Aug-89  1234	ramsdell@linus.mitre.org 	"is an error" -> "is undefined"   
C01993 00342	∂25-Aug-89  1237	KMP@stony-brook.scrc.symbolics.com 	Revised WITH-VALUES and VALUES (I think we are near agreement!) 
C02001 00343	∂25-Aug-89  1726	jinx@hpesogg.hp.com 	"is an error" -> "is undefined"   
C02004 00344	∂25-Aug-89  1749	jinx@hpesogg.hp.com 	Revised WITH-VALUES and VALUES (I think we are near agreement!) 
C02010 00345	∂25-Aug-89  2303	@mc.lcs.mit.edu:bawden.pa@xerox.com 	Numbers and Pork Rinds 
C02021 00346	∂26-Aug-89  0100	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	Programmer-defined data types  
C02025 00347	∂26-Aug-89  0315	@mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com 	Programmer-defined data types  
C02040 00348	∂26-Aug-89  0529	@mc.lcs.mit.edu:harrison@s45.csrd.uiuc.edu 	Numbers and Pork Rinds    
C02045 00349	∂26-Aug-89  0532	@mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com 	Numbers  
C02050 00350	∂27-Aug-89  0028	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	Multiple values for R4RS    
C02062 00351	∂27-Aug-89  1443	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	last call for MIN and MAX   
C02066 00352	∂27-Aug-89  1647	@mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com 	Numbers and Pork Rinds  
C02071 00353	∂27-Aug-89  1653	@mc.lcs.mit.edu:bawden@arisia.xerox.com 	Numbers and Pork Rinds  
C02080 00354	∂28-Aug-89  0455	ramsdell@linus.mitre.org 	Kent, please bless this multiple values proposal.
C02085 00355	∂28-Aug-89  0925	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #189 
C02089 00356	∂28-Aug-89  1120	@mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu 	multiple values  
C02094 00357	∂28-Aug-89  1412	ramsdell@linus.mitre.org 	Re: multiple values     
C02098 00358	∂28-Aug-89  1619	bawden@arisia.xerox.com 	Re: multiple values 
C02101 00359	∂28-Aug-89  1955	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers and Pork Rinds   
C02105 00360	∂28-Aug-89  2212	@mc.lcs.mit.edu:bawden@arisia.xerox.com 	Numbers and Pork Rinds  
C02109 00361	∂29-Aug-89  0050	@mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com 	multiple values    
C02112 00362	∂29-Aug-89  0517	ramsdell@linus.mitre.org 	Re: multiple values     
C02116 00363	∂29-Aug-89  0657	ramsdell@linus.mitre.org 	rrrs-authors-request@life.ai.mit.edu is broken.  
C02121 00364	∂29-Aug-89  0732	@mc.lcs.mit.edu,@hp-sde.sde.hp.com:jinx@hpesogg.hp.com 	Numbers and Pork Rinds  
C02124 00365	∂29-Aug-89  0838	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #188 
C02129 00366	∂29-Aug-89  0915	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #190 
C02132 00367	∂29-Aug-89  1316	mkatz@sesame.stanford.edu 	Kent, please bless this multiple values proposal.    
C02136 00368	∂29-Aug-89  1920	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Programmer-defined data types, version 2  
C02153 00369	∂30-Aug-89  0021	Pavel.pa@xerox.com 	Multiple values
C02159 00370	∂30-Aug-89  0522	ramsdell@linus.mitre.org 	multiple values and call/cc. 
C02164 00371	∂30-Aug-89  0528	ramsdell@linus.mitre.org 	Re: Multiple values     
C02167 00372	∂30-Aug-89  1205	katz@polya.stanford.edu 	Multiple values
C02170 00373	∂30-Aug-89  1310	ramsdell@linus.mitre.org 	Revised multiple values and call/cc.   
C02175 00374	∂30-Aug-89  1522	dyb@iuvax.cs.indiana.edu 	Re:  Multiple values for R4RS
C02181 00375	∂30-Aug-89  1802	@mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu 	mv continuations 
C02186 00376	∂30-Aug-89  1833	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Programmer-defined data types, version 2   
C02190 00377	∂30-Aug-89  2012	@mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com 	Re:  Programmer-defined data types, version 2   
C02196 00378	∂30-Aug-89  2042	@mc.lcs.mit.edu,@life.ai.mit.edu:katz@polya.stanford.edu 	Programmer-defined data types, version 2  
C02200 00379	∂31-Aug-89  0231	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #192 
C02243 00380	∂31-Aug-89  0542	ramsdell@linus.mitre.org 	Re: Multiple values for R4RS 
C02249 00381	∂31-Aug-89  1103	ramsdell@linus.mitre.org 	Multiple values not for R4RS 
C02254 00382	∂31-Aug-89  1106	dyb@iuvax.cs.indiana.edu 	Re: Multiple values for R4RS 
C02257 00383	∂31-Aug-89  1111	katz@polya.stanford.edu 	Multiple values for R4RS 
C02262 00384	∂31-Aug-89  1121	ramsdell@linus.mitre.org 	Re: Multiple values for R4RS 
C02266 00385	∂31-Aug-89  1134	katz@polya.stanford.edu 	Revised multiple values and call/cc.    
C02270 00386	∂31-Aug-89  2019	@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	Re:  Multiple values not for R4RS  
C02273 00387	∂31-Aug-89  2026	katz@polya.stanford.edu 	Multiple values not for R4RS  
C02276 00388	∂01-Sep-89  0001	Pavel.pa@xerox.com 	An alternate description of the multiple values proposal    
C02283 00389	∂01-Sep-89  0052	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	Programmer-defined data types, version 2    
C02286 00390	∂01-Sep-89  0054	@mc.lcs.mit.edu,@life.ai.mit.edu:jar@zurich.ai.mit.edu 	Programmer-defined data types, version 2    
C02289 00391	∂01-Sep-89  0259	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	Programmer-defined data types, version 2    
C02293 00392	∂01-Sep-89  0304	@mc.lcs.mit.edu,@life.ai.mit.edu:katz@polya.stanford.edu 	Programmer-defined data types, version 2  
C02297 00393	∂01-Sep-89  0333	jinx@zurich.ai.mit.edu 	An alternate description of the multiple values proposal
C02300 00394	∂01-Sep-89  0544	ramsdell@linus.mitre.org 	Please rename BABY-DOE and agree on an agenda item    
C02306 00395	∂01-Sep-89  0610	ramsdell@linus.mitre.org 	Re: Multiple values not for R4RS  
C02310 00396	∂01-Sep-89  0623	ramsdell@linus.mitre.org 	Re: An alternate description of the multiple values proposal    
C02314 00397	∂01-Sep-89  0757	ramsdell@linus.mitre.org 	An alternative to ACCEPTS?   
C02317 00398	∂01-Sep-89  0900	@mc.lcs.mit.edu,@life.ai.mit.edu:katz@polya.stanford.edu 	Programmer-defined data types, version 2  
C02322 00399	∂01-Sep-89  0909	katz@polya.stanford.edu 	Multiple values not for R4RS  
C02326 00400	∂01-Sep-89  0914	katz@polya.stanford.edu 	An alternative to ACCEPTS?    
C02330 00401	∂01-Sep-89  0949	ramsdell@linus.mitre.org 	Re: Multiple values not for R4RS  
C02333 00402	∂01-Sep-89  1050	Pavel.pa@xerox.com 	Re: An alternate description of the multiple values proposal
C02339 00403	∂01-Sep-89  1404	cph@zurich.ai.mit.edu 	An alternate description of the multiple values proposal 
C02341 00404	∂01-Sep-89  1419	cph@zurich.ai.mit.edu 	An alternate description of the multiple values proposal 
C02345 00405	∂01-Sep-89  1505	Pavel.pa@xerox.com 	Re: An alternate description of the multiple values proposal
C02349 00406	∂01-Sep-89  1507	jinx@zurich.ai.mit.edu 	An alternate description of the multiple values proposal
C02353 00407	∂01-Sep-89  1516	cph@zurich.ai.mit.edu 	An alternate description of the multiple values proposal 
C02357 00408	∂01-Sep-89  1635	Pavel.pa@xerox.com 	Re: An alternate description of the multiple values proposal
C02359 00409	∂01-Sep-89  1653	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	Programmer-defined data types, version 2    
C02364 00410	∂01-Sep-89  1857	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Programmer-defined data types, last (?) version
C02377 00411	∂05-Sep-89  0916	ramsdell@linus.mitre.org 	Name for BABY-DOE should not include "values".   
C02380 00412	∂05-Sep-89  0918	ramsdell@linus.mitre.org 	Re: An alternate description of the multiple values proposal    
C02384 00413	∂05-Sep-89  1446	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net:jmiller@cs.brandeis.edu 	Programmer-defined data types, last (?) version  
C02388 00414	∂05-Sep-89  2222	Pavel.pa@xerox.com 	Re: Name for BABY-DOE should not include "values".
C02391 00415	∂05-Sep-89  2349	@mc.lcs.mit.edu,@life.ai.mit.edu:bawden@arisia.xerox.com 	Programmer-defined data types, last (?) version
C02396 00416	∂06-Sep-89  0006	KMP@stony-brook.scrc.symbolics.com 	Baby-Doe and friends    
C02403 00417	∂06-Sep-89  0626	ramsdell@linus.mitre.org 	Re: Baby-Doe and friends     
C02408 00418	∂06-Sep-89  0821	gls@think.com 	Baby-Doe and friends
C02412 00419	∂06-Sep-89  0859	katz@neon.stanford.edu 	Baby-Doe and friends 
C02414 00420	∂06-Sep-89  1018	@mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu 	mutiple values, procedures and continuations   
C02418 00421	∂06-Sep-89  1428	@mc.lcs.mit.edu,@life.ai.mit.edu:bawden@arisia.xerox.com 	Baby-Doe and friends  
C02423 00422	∂06-Sep-89  1619	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@zurich.ai.mit.edu 	Baby-Doe and friends   
C02426 00423	∂07-Sep-89  0942	@mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu 	RE: name for VALUES  
C02429 00424	∂07-Sep-89  1013	@mc.lcs.mit.edu,@life.ai.mit.edu:jar@zurich.ai.mit.edu 	Baby-Doe and friends    
C02432 00425	∂08-Sep-89  0426	ramsdell@linus.mitre.org 	ARGUMENTS/VALUES -> CONSUME/PRODUCE    
C02436 00426	∂08-Sep-89  1024	@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	ARGUMENTS/VALUES -> CONSUME/PRODUCE   
C02439 00427	∂08-Sep-89  1318	KMP@stony-brook.scrc.symbolics.com 	ARGUMENTS/VALUES -> CONSUME/PRODUCE    
C02444 00428	∂08-Sep-89  1329	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	Baby-Doe and friends   
C02447 00429	∂08-Sep-89  1426	gls@think.com 	ARGUMENTS/VALUES -> CONSUME/PRODUCE
C02451 00430	∂08-Sep-89  1542	@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	name that baby    
C02455 00431	∂08-Sep-89  1759	KMP@stony-brook.scrc.symbolics.com 	name that baby
C02457 00432	∂11-Sep-89  0516	ramsdell@linus.mitre.org 	PIPE/CONTINUE 
C02460 00433	∂11-Sep-89  0940	katz@neon.stanford.edu 	ARGUMENTS/VALUES -> CONSUME/PRODUCE 
C02463 00434	∂17-Sep-89  0101	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #205 
C02467 00435	∂17-Sep-89  0157	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #200 
C02474 00436	∂17-Sep-89  0321	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #204 
C02477 00437	∂17-Sep-89  0410	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #199 
C02480 00438	∂17-Sep-89  0412	@relay.cs.net,@tektronix.tek.com:kend@mrloog.wr.tek.com 	DOE-SEE-DOE and HEY-BABY!   
C02483 00439	∂17-Sep-89  0413	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #203 
C02489 00440	∂21-Sep-89  0400	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #206 
C02500 00441	∂21-Sep-89  1251	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #208 
C02509 00442	∂22-Sep-89  0517	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #209 
C02512 00443	∂28-Sep-89  1124	ramsdell@linus.mitre.org 	Naming BABY-DOE    
C02515 00444	∂28-Sep-89  1238	@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	Naming BABY-DOE oportunistically 
C02517 00445	∂29-Sep-89  0350	ramsdell@linus.mitre.org 	Re: Naming BABY-DOE     
C02520 00446	∂29-Sep-89  0418	ramsdell@linus.mitre.org 	Re: Naming BABY-DOE     
C02523 00447	∂29-Sep-89  1610	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #214 
C02527 00448	∂29-Sep-89  2236	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #215 
C02538 00449	∂04-Oct-89  1545	KMP@stony-brook.scrc.symbolics.com 	Re: Naming BABY-DOE
C02550 00450	∂07-Oct-89  0654	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #221 
C02553 00451	∂11-Oct-89  2309	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #223 
C02557 00452	∂12-Oct-89  2201	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #224 
C02560 ENDMK
C⊗;
∂17-Jun-89  2139	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #139 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jun 89  21:39:33 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00495;
          18 Jun 89 0:30 EDT
Date: 18 JUN 89  00:04:06 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #139 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8906180030.aa00495@mintaka.lcs.mit.edu>

Scheme Digest #139                             18 JUN 89  00:04:06 EDT

Today's Topics:

        BUG IN EXPANDED MEMORY TI PC-SCHEME?

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

Date: 16 Jun 89 21:43:25 GMT
From: Brian Leverich <leverich@RAND.ORG>
Subject: BUG IN EXPANDED MEMORY TI PC-SCHEME?
Message-Id: <2102@randvax.UUCP>


On "long" simulation runs (20+ minutes on a 12mHz 286 with LIM 4.0 EMS...)
using PCSEXP, the _expanded memory_ version of Texas Instrument's
PC-Scheme, I apparently run low on space, the gc starts thrashing around,
and finally I get a Scheme reset because the system is out of space.

Problem is, I can't find anywhere near enough current structures to
fill memory.  Moreover, (freesp) returns 400K + of memory, then if I
invoke (freesp) again (or anything else...) it triggers another gc
and sometimes another Scheme reset.  I don't have the problem when I
use PCSEXT and jumper my expanded memory to act like extended.  Looks
like (freesp) can see a big chunk of free space, but the gc isn't
adding it to the free list.

Anyone else had this problem with PCSEXP?  Anyone have any workaround
suggestions?  Tnx.  -B
-- 
  "Simulate it in ROSS"
  Brian Leverich                       | U.S. Snail: 1700 Main St.
  ARPAnet: leverich@rand.org           |             Santa Monica, CA 90406
  UUCP:    decvax!randvax!leverich     | Ma Bell:    (213) 393-0411 X7769

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

End of Scheme Digest
********************

∂18-Jun-89  2215	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #140 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jun 89  22:15:10 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22536;
          19 Jun 89 1:05 EDT
Date: 19 JUN 89  00:06:11 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #140 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8906190105.aa22536@mintaka.lcs.mit.edu>

Scheme Digest #140                             19 JUN 89  00:06:11 EDT

Today's Topics:

        "unspecified" and SET!

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

Date: 18 Jun 89 23:17:50 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: "unspecified" and SET!
Message-Id: <3902@kalliope.rice.edu>

The recent discussion of "unspecified" values reveals that Scheme is
not as syntactically uniform as it is claimed to be. Some Scheme
syntactic forms return meaningful values, others don't: the former are
"expressions" and the latter "commands". "Commands" are usually used
to represent side-effects, e.g., assignment in the form of set!.  In
an expression-oriented language, a "command" is awkwardly "expressed"
by an expression returning an arbitrary "unspecified" value.

Perhaps, SET! is not the ideal side-effecting construct for an
expression-oriented language. Felleisen and Friedman [1] propose a
side-effecting construct called a SIGMA-capability. This looks just
like a LAMBDA-expression, but whereas LAMBDA introduces new bound
variables, SIGMA modifies the binding of existing lexical variables.
In other words, on applying a SIGMA-capability to arguments, the
variables corresponding to the SIGMA-parameters are side-effected.

Problems about "unspecified" return values disappear. The application
of a SIGMA-capability side-effects the SIGMA-parameters and returns
the result of evaluating the SIGMA-body (the parallel being the
application of a LAMBDA-expression). In addition, SIGMA gives a very
natural method for parallel assignment, since the arguments to a
SIGMA-capability are all evaluated before the application performs the
side-effects.

We can retrieve the old SET! from SIGMA as follows:
	(set! x a) == ((sigma (x) <what-now>) a)
where <what-now> is the "unspecified" value of your choice. Thus,
there is no dependence on a system-chosen unspecified value.

Even better, we need not fall back on a command with its necessarily
arbitrary choice of unspecified return value. We can define a
_generalized_ SET! in terms of SIGMA that is more along the lines of
LET in terms of LAMBDA:
	(set! ([x a] ...) e ...) == ((sigma (x ...) e ...) a ...)

The upshot of all this is that while we have side-effects, we still
have a syntactically uniform language.

--dorai

[1] Felleisen & Friedman, A calculus for assigments ..., POPL 1987,
314 - 325.

ps: In terms of SET!, SIGMA's effect is as follows:
	(sigma (x ...) e ...) == (lambda (x↑ ...) (set! x x↑) ... e ...)
where x↑ ... are new variables, used only to show what's going on. A
native implementation of SIGMA is simply got by mimicking LAMBDA,
except for the following: where LAMBDA has extend-environment, SIGMA
has update-environment.
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------

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

End of Scheme Digest
********************

∂19-Jun-89  1414	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	another change for R4RS; peek-char   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89  14:14:15 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04503;
          19 Jun 89 16:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 16:42:22 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa18914;
          19 Jun 89 12:56 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA09188; Mon, 19 Jun 89 09:55:15 PDT
Date: Mon, 19 Jun 89 09:55:15 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906191655.AA09188@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: will@fog.cs.uoregon.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Fri, 2 Jun 89 15:15:37 edt <8906021915.AA02759@ZURICH.AI.MIT.EDU>
Subject: another change for R4RS; peek-char

   Date: Fri, 2 Jun 89 15:15:37 edt
   From: Chris Hanson <cph@zurich.ai.mit.edu>
   Reply-To: cph@zurich.ai.mit.edu

      Date: Tue, 30 May 89 17:08:52 PDT
      From: William Clinger <will@fog.cs.uoregon.edu>

      One person has objected, strongly, to making list-ref and list-tail
      essential.  Does anyone wish to counter by explaining just why it
      is essential that these procedures be essential?

   The reason is the following (extracted from the Working Group on
   Scheme's unapproved minutes of the Feb. 3 meeting):

       6.1  Procedures to be deleted from the standard.

       Moved, seconded, and approved: keep LIST-REF, LIST-TAIL, and
       SUBSTRING, and delete STRING->LIST, LIST->STRING, STRING-COPY,
       STRING-FILL!, VECTOR->LIST, LIST->VECTOR, and VECTOR-FILL!.  Since
       LIST-REF and LIST-TAIL are non-essential features in R4RS, we need the
       author's agreement to change them to essential.

   This is required because the Working Group does not wish to
   standardize on anything that is inessential in R*RS.  If R*RS decides
   to keep these procedures inessential, the WG will be forced to drop
   them from the standard.

   I suppose this can be thought of as a strong recommendation from the
   WG to R*RS that it is desirable to keep these procedures.


In the original discussions on standardization, a concern was expressed that
the standards effort would try to foist changes on the R*RS community.  We were
assured that this was not the case and any changes to R*RS would be made on
their own merits.  I hope this position has not changed already!!!  It is the
Working Groups decision to create a standard which only includes essential
features from R*RS.  This decision should have not standing in R*RS
discussions. 
					Morry Katz
					katz@polya.stanford.edu

∂19-Jun-89  1851	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	another change for R4RS; peek-char
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89  18:51:09 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29683;
          19 Jun 89 20:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 19:58:15 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12030;
          19 Jun 89 19:46 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA04980; Mon, 19 Jun 89 19:46:07 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Mon, 19 Jun 89 19:43:16 edt
Date: Mon, 19 Jun 89 19:43:16 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8906192343.AA23241@ZURICH.AI.MIT.EDU>
To: mkatz@sesame.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Morris Katz's message of Mon, 19 Jun 89 14:52:57 PDT <8906192152.AA10258@sesame.Stanford.EDU>
Subject: another change for R4RS; peek-char

   Date: Mon, 19 Jun 89 14:52:57 PDT
   From: mkatz@sesame.stanford.edu (Morris Katz)

   Maybe I reacted too strongly to this request, and I apologize to all if I did.
   However, it is my opinion that a change is being advocated to R*RS based on no
   technical arguments, but only political ones.  At Snowbird, there were those of
   us who advocated removing the functions in question from R*RS altogether and
   others who wanted to make them essential.  We reached a compromise that these
   functions would remain inessential.  I am afraid that if the question is
   phrased in such a way that essential status and elimination become the only
   viable alternatives, I will be forced to also break the truce and crusade for
   elimination. 

Again, the issue is much simpler than you are making out.

From the point of view of R*RS, the possible options are the same as
they were at Snowbird.  Indeed, it entirely reasonable for the authors
group to take the position that there is no reason to change the
status quo.  In that case, by decisions independent of R*RS, the
Scheme standard will *not* contain `list-ref' and `list-tail', but the
R*RS will still contain them as inessential procedures.

Let me reiterate: no one is reducing the authors' possible
alternatives or attempting to force a choice in any way.

The point of the request is that the standardization Working Group
feels that it is desirable to include these procedures in the
standard.  Inclusion of the procedures requires that they be essential
in R*RS, because of the intention to make the standard a conservative
subset of R*RS.  So the Working Group is asking the authors to
reconsider their decision in light of this situation, feeling that
perhaps the tide of opinion within the authors' community might shift.

A parting shot: your comment regarding technical vs. political
arguments is misleading.  The comment attempts to make the (partially)
political argument of the Working Group appear unworthy of serious
consideration by the implication that previous arguments have
technical merit.  As I understand it, there are few or no technical
arguments on either side of this issue; the arguments are primarily
aesthetic and/or practical.  If there was a cogent technical reason
for doing things one way or the other, I suspect there would be wider
agreement about the status of these procedures.

∂19-Jun-89  1852	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	another change for R4RS; peek-char   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89  18:52:00 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00281;
          19 Jun 89 20:39 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 20:37:24 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa29962;
          19 Jun 89 20:24 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA10742; Mon, 19 Jun 89 17:19:51 PDT
Date: Mon, 19 Jun 89 17:19:51 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906200019.AA10742@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Mon, 19 Jun 89 19:43:16 edt <8906192343.AA23241@ZURICH.AI.MIT.EDU>
Subject: another change for R4RS; peek-char

   Date: Mon, 19 Jun 89 19:43:16 edt
   From: cph@ZURICH.AI.MIT.EDU (Chris Hanson)

      Date: Mon, 19 Jun 89 14:52:57 PDT
      From: mkatz@sesame.stanford.edu (Morris Katz)

      Maybe I reacted too strongly to this request, and I apologize to all if I did.
      However, it is my opinion that a change is being advocated to R*RS based on no
      technical arguments, but only political ones.  At Snowbird, there were those of
      us who advocated removing the functions in question from R*RS altogether and
      others who wanted to make them essential.  We reached a compromise that these
      functions would remain inessential.  I am afraid that if the question is
      phrased in such a way that essential status and elimination become the only
      viable alternatives, I will be forced to also break the truce and crusade for
      elimination. 

   Again, the issue is much simpler than you are making out.

   >From the point of view of R*RS, the possible options are the same as
   they were at Snowbird.  Indeed, it entirely reasonable for the authors
   group to take the position that there is no reason to change the
   status quo.  In that case, by decisions independent of R*RS, the
   Scheme standard will *not* contain `list-ref' and `list-tail', but the
   R*RS will still contain them as inessential procedures.

   Let me reiterate: no one is reducing the authors' possible
   alternatives or attempting to force a choice in any way.

   The point of the request is that the standardization Working Group
   feels that it is desirable to include these procedures in the
   standard.  Inclusion of the procedures requires that they be essential
   in R*RS, because of the intention to make the standard a conservative
   subset of R*RS.  So the Working Group is asking the authors to
   reconsider their decision in light of this situation, feeling that
   perhaps the tide of opinion within the authors' community might shift.

   A parting shot: your comment regarding technical vs. political
   arguments is misleading.  The comment attempts to make the (partially)
   political argument of the Working Group appear unworthy of serious
   consideration by the implication that previous arguments have
   technical merit.  As I understand it, there are few or no technical
   arguments on either side of this issue; the arguments are primarily
   aesthetic and/or practical.  If there was a cogent technical reason
   for doing things one way or the other, I suspect there would be wider
   agreement about the status of these procedures.

Let me attempt a short and cogent argument.  It has always been my impression
that the Scheme community is attempting to create a small, but powerful, core
language on which real systems can be built.  For our failure to include in
R*RS many useful functions that are easily implementable using the core
language, we have often been criticized by proponents of CommonLisp.  I have
always believed that the Scheme approach was correct; however, it is my
personal opinion that if we are going to make list-tail and list-ref essential
then there are probably 50 other equivalently useful functions that should be
included in R*RS.  I believe that this is a slipery slope onto which we don't
want to tread.  If there is some reason that people think that these two
functions are particularly useful or are not easily implemented in the core
language, I would be very interested in hearing those arguments.  Noone seemed
to be able to generate them at Snowbird.
					Morry Katz
					katz@polya.stanford.edu

∂19-Jun-89  1906	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	another change for R4RS; peek-char
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89  19:05:56 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25509;
          19 Jun 89 17:31 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 16:59:37 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20986;
          19 Jun 89 16:36 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA02216; Mon, 19 Jun 89 16:36:40 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Mon, 19 Jun 89 16:33:22 edt
Date: Mon, 19 Jun 89 16:33:22 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8906192033.AA22514@ZURICH.AI.MIT.EDU>
To: mkatz@sesame.stanford.edu
Cc: will@fog.cs.uoregon.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Morris Katz's message of Mon, 19 Jun 89 09:55:15 PDT <8906191655.AA09188@sesame.Stanford.EDU>
Subject: another change for R4RS; peek-char

   Date: Mon, 19 Jun 89 09:55:15 PDT
   From: mkatz@sesame.stanford.edu (Morris Katz)

      Date: Fri, 2 Jun 89 15:15:37 edt
      From: Chris Hanson <cph@zurich.ai.mit.edu>
      Reply-To: cph@zurich.ai.mit.edu

	 Date: Tue, 30 May 89 17:08:52 PDT
	 From: William Clinger <will@fog.cs.uoregon.edu>

	 One person has objected, strongly, to making list-ref and list-tail
	 essential.  Does anyone wish to counter by explaining just why it
	 is essential that these procedures be essential?

      The reason is the following (extracted from the Working Group on
      Scheme's unapproved minutes of the Feb. 3 meeting):

	  6.1  Procedures to be deleted from the standard.

	  Moved, seconded, and approved: keep LIST-REF, LIST-TAIL, and
	  SUBSTRING, and delete STRING->LIST, LIST->STRING, STRING-COPY,
	  STRING-FILL!, VECTOR->LIST, LIST->VECTOR, and VECTOR-FILL!.  Since
	  LIST-REF and LIST-TAIL are non-essential features in R4RS, we need the
	  author's agreement to change them to essential.

      This is required because the Working Group does not wish to
      standardize on anything that is inessential in R*RS.  If R*RS decides
      to keep these procedures inessential, the WG will be forced to drop
      them from the standard.

      I suppose this can be thought of as a strong recommendation from the
      WG to R*RS that it is desirable to keep these procedures.


   In the original discussions on standardization, a concern was expressed that
   the standards effort would try to foist changes on the R*RS community.  We were
   assured that this was not the case and any changes to R*RS would be made on
   their own merits.  I hope this position has not changed already!!!  It is the
   Working Groups decision to create a standard which only includes essential
   features from R*RS.  This decision should have not standing in R*RS
   discussions. 
					   Morry Katz
					   katz@polya.stanford.edu

No one is trying to "foist changes" on the R*RS community.  The
standards Working Group has made a REQUEST that this be changed.  If
the authors refuse the request, as is their prerogative, the Working
Group will accept that decision.

Please don't read more political intent into my message than was there
already, even if it does help to reinforce your position.  I thought I
was quite clear as to the nature of the request, including the
possibility that the working group might have to deal with a refusal.

∂19-Jun-89  1907	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	another change for R4RS; peek-char   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89  19:07:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17117;
          19 Jun 89 19:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 19 Jun 89 19:25:51 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa11775;
          19 Jun 89 19:24 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA10258; Mon, 19 Jun 89 14:52:57 PDT
Date: Mon, 19 Jun 89 14:52:57 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906192152.AA10258@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: will@fog.cs.uoregon.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Mon, 19 Jun 89 16:33:22 edt <8906192033.AA22514@ZURICH.AI.MIT.EDU>
Subject: another change for R4RS; peek-char

   Date: Mon, 19 Jun 89 16:33:22 edt
   From: cph@ZURICH.AI.MIT.EDU (Chris Hanson)

      Date: Mon, 19 Jun 89 09:55:15 PDT
      From: mkatz@sesame.stanford.edu (Morris Katz)

	 Date: Fri, 2 Jun 89 15:15:37 edt
	 From: Chris Hanson <cph@zurich.ai.mit.edu>
	 Reply-To: cph@zurich.ai.mit.edu

	    Date: Tue, 30 May 89 17:08:52 PDT
	    From: William Clinger <will@fog.cs.uoregon.edu>

	    One person has objected, strongly, to making list-ref and list-tail
	    essential.  Does anyone wish to counter by explaining just why it
	    is essential that these procedures be essential?

	 The reason is the following (extracted from the Working Group on
	 Scheme's unapproved minutes of the Feb. 3 meeting):

	     6.1  Procedures to be deleted from the standard.

	     Moved, seconded, and approved: keep LIST-REF, LIST-TAIL, and
	     SUBSTRING, and delete STRING->LIST, LIST->STRING, STRING-COPY,
	     STRING-FILL!, VECTOR->LIST, LIST->VECTOR, and VECTOR-FILL!.  Since
	     LIST-REF and LIST-TAIL are non-essential features in R4RS, we need the
	     author's agreement to change them to essential.

	 This is required because the Working Group does not wish to
	 standardize on anything that is inessential in R*RS.  If R*RS decides
	 to keep these procedures inessential, the WG will be forced to drop
	 them from the standard.

	 I suppose this can be thought of as a strong recommendation from the
	 WG to R*RS that it is desirable to keep these procedures.


      In the original discussions on standardization, a concern was expressed that
      the standards effort would try to foist changes on the R*RS community.  We were
      assured that this was not the case and any changes to R*RS would be made on
      their own merits.  I hope this position has not changed already!!!  It is the
      Working Groups decision to create a standard which only includes essential
      features from R*RS.  This decision should have not standing in R*RS
      discussions. 
					      Morry Katz
					      katz@polya.stanford.edu

   No one is trying to "foist changes" on the R*RS community.  The
   standards Working Group has made a REQUEST that this be changed.  If
   the authors refuse the request, as is their prerogative, the Working
   Group will accept that decision.

   Please don't read more political intent into my message than was there
   already, even if it does help to reinforce your position.  I thought I
   was quite clear as to the nature of the request, including the
   possibility that the working group might have to deal with a refusal.

Maybe I reacted too strongly to this request, and I apologize to all if I did.
However, it is my opinion that a change is being advocated to R*RS based on no
technical arguments, but only political ones.  At Snowbird, there were those of
us who advocated removing the functions in question from R*RS altogether and
others who wanted to make them essential.  We reached a compromise that these
functions would remain inessential.  I am afraid that if the question is
phrased in such a way that essential status and elimination become the only
viable alternatives, I will be forced to also break the truce and crusade for
elimination. 
					Morry Katz
					katz@polya.stanford.edu

∂19-Jun-89  2242	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #141 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 19 Jun 89  22:42:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25176;
          20 Jun 89 1:12 EDT
Date: 20 JUN 89  00:07:16 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #141 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8906200112.aa25176@mintaka.lcs.mit.edu>

Scheme Digest #141                             20 JUN 89  00:07:16 EDT

Today's Topics:

        "unspecified" and SET!
        "unspecified" and SET!

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

Date: Mon, 19 Jun 89 15:26 EDT
From: Alan Bawden <Alan@REAGAN.AI.MIT.EDU>
Subject: "unspecified" and SET!
Message-ID: <19890619192610.2.ALAN@PIGPEN.AI.MIT.EDU>

    Date: 18 Jun 89 23:17:50 GMT
    From: Dorai Sitaram <titan!dorai@rice.edu>
    ...
    Perhaps, SET! is not the ideal side-effecting construct for an
    expression-oriented language. Felleisen and Friedman [1] propose a
    side-effecting construct called a SIGMA-capability. This looks just
    like a LAMBDA-expression, but whereas LAMBDA introduces new bound
    variables, SIGMA modifies the binding of existing lexical variables.
    In other words, on applying a SIGMA-capability to arguments, the
    variables corresponding to the SIGMA-parameters are side-effected.

    Problems about "unspecified" return values disappear....

I'm having a hard time applying this idea to the NEWLINE procedure -- which
is specified in R3RS to return an unspecified value.  Is the idea to
introduce a side-effecting construct that looks like LAMBDA, but performs a
newline when applied to an output port?

  ((NULINE () <body>)
   (CURRENT-OUTPUT-PORT))


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

Date: 19 Jun 89 23:24:37 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <3904@kalliope.rice.edu>

In response to my posting suggesting SIGMA and SIGMA-based SET! (a la
LAMBDA and LET) instead of traditional SET!, I received email which
basically states that SIGMA violates the orthogonality of Scheme
constructs, viz., SIGMA does "two" things: it "side-effects the
environment" _and_ "returns a value".

In other words, it is felt that any side-effecting construct should
just perform the job it was made for, viz., side-effecting, and not do
something else too, like returning values. SIGMA allegedly "fails" in
the latter detail.

But then, we should remember that our goal was to preserve the
syntactic uniformity of Scheme. Scheme is (and very deliberately too)
an expression-oriented language. In spite of our best efforts,
traditional SET! does return a value. Given that whichever primitive
side-effecting construct we pick will inevitably return a value, which
construct should we choose? I would prefer one where the returned
value is not only meaningful but _necessary_.

The value that SET! returns is totally arbitrary. What SIGMA returns
is crucial to its correctness. Recall that SIGMA does not perform a
side-effect immediately; it returns a closure, which needs to be
applied to value(s) before any side-effecting can take place.

(Incidentally, LAMBDA, the cornerstone of Scheme, also has "two"
purposes _if_ we take "returning a value" as a distinguishing property
in assessing the orthogonality of Scheme. LAMBDA introduces fresh
lexical variables _and_ returns a closure. I don't think anyone
seriously wants to reject LAMBDA for lack of orthogonality!)

--dorai

ps: Other questions:

* Why was SIGMA created? Felleisen & Friedman (POPL 1987) devised a
  calculus for a lambda-calculus-like language with assignments. SIGMA
  kind of falls out naturally. 

* Why is it "superior" to SET!? "Superior" is a tough word. However, I
  did mention the naturalness of parallel assignment in my orig.
  posting. Using SIGMA-capabilities as arguments to control-reifiers
  like call/cc is also delicious.

* There is also another reason why the SIGMA-model of assignment, viz.,
  (sigma (x ...) e ...) or (set! ([x a] ...) e ...), makes sense. In any
  program, one always performs some operation _after_ the
  side-effecting (of variable-bindings(see + below)) has been done. If
  the side-effecting were the last thing done in the program, there is
  no way it could be detected, hence no way it could be meaningful.
  Thus the application of a SIGMA-capability returns the value of the
  body of the SIGMA-expression, something (and such a something
  invariably exists) that is evaluated _after_ the side-effecting has
  taken place.

+{PRINTF is the only side-effect which can meaningfully be the last
  thing in a program.}

* [Alan Bawden's question about NEWLINE...]
  How do you deal with the other "commands" of Scheme? (E.g., READ,
  SET-CAR!, PRINTF.) Easier than SET!. SIGMA-like counterparts need
  _not_ be made for these, as that would lead to a plethora of special
  forms (as opposed to 'procedures'). All of these "command"
  procedures now take an additional argument for "the body" (thunk
  actually) whose value is returned. 

{* SIGMA of course is necessarily a special form (i.e., it cannot be
   substituted by a procedure as for READ, SET-CAR!, PRINTF above).
   The reason is variable names can't be passed as procedure arguments.}

--dorai
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------

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

End of Scheme Digest
********************

∂20-Jun-89  0721	@mc.lcs.mit.edu:shaff@sesame.stanford.edu 	Useful, but not essential  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89  07:21:30 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ab06077;
          20 Jun 89 10:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 10:14:15 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa19354;
          20 Jun 89 10:10 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA13286; Tue, 20 Jun 89 07:09:44 PDT
Date: Tue, 20 Jun 89 07:09:44 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8906201409.AA13286@sesame.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Useful, but not essential


ciao,

I hesitate to enter into this seemingly charged arena, but...

It is my opinion that non-essential procedures, were to be considered
potentially useful for the user, hence implementors were given a possible
binding for the specified functionality.  This was a method by which we could
avoid having standard 'user environment' procedures with wildly divergent
names/functionality.

I must admit my bias away from the inclusion of easily built procedures (and
macros, someday... ahhh someday ;>).  If one looks at the Brooks and Gabriel
paper entitled 'A Critique of Common Lisp' (reference below) the first
desirable property is written of as:

 Intellectual Conciseness.  A language should be small enough for a programmer
  to be able to keep all of it in mind when programming.

I recognize that the introduction of essential procedures does not introduce
primitives (the focus of Brooks and Gabriel's paragraph), however I do think
that the principle can be applied here.  (NOTE: I was one of the people that
advocated the complete removal of a number of non-essential constructs).

I share Chris Hansons's hope that this (and all future) discussions return to
a tone of tech/fun.

(peace chance)

	mas

∂20-Jun-89  0754	@mc.lcs.mit.edu:shaff@sesame.stanford.edu 	Useful, but not essential: the reference  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89  07:54:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14878;
          20 Jun 89 10:35 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 10:19:48 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa04769;
          20 Jun 89 10:16 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA13322; Tue, 20 Jun 89 07:16:22 PDT
Date: Tue, 20 Jun 89 07:16:22 PDT
From: shaff@sesame.stanford.edu (Mike Shaff)
Message-Id: <8906201416.AA13322@sesame.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Useful, but not essential: the reference


ciao,

Not being of sound mind I forgot the promised reference.

Brooks, R. A. & Gabriel R. P., A Critique of Common Lisp, Proceedings of 1984
Symposium on LISP and Functional Programming, ACM, New York, 1984.

(peace chance)

	mas

∂20-Jun-89  1323	@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu 	RE: Sticks and stones
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89  13:23:48 PDT
Received: by mintaka.lcs.mit.edu id af03592; 20 Jun 89 16:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03474;
          20 Jun 89 16:01 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 15:59:32 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267427; 20 Jun 89 15:58:29 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 20 Jun 89 15:58:40 EDT
Date: Tue, 20 Jun 89 15:58:40 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
Message-Id: <8906201958.AA15522@hx.LCS.MIT.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: RE: Sticks and stones


 I vaguely recall an agreement a short time ago that there was going to
be a Standard Library of Scheme procedures. It was my understanding at the
time that all inessential procedures were going to be migrated to this
section (this may have been a halucination on my part).

 Perhaps we could rechannel our hostilities between the Standards folks
and the R* folks into fulfilling that unforced promise to all submit
useful nonessential stuff to the Librarian.

 This should also stimulate a discussion among the standards folks on
whether the R* Standardized Library stuff should be in the Standard
or not. That, I think, should be the sole issue to be discussed...
blackmailing the R* folks should not be the issue (you know, ``if
you folks don;t make this essential in *your* report then you can't
have it in *our* standard''. That is the ultimatum as I see it.)

 Is focussing on the Library a viable alternative to sticks and stones
or am I just tossing another stick/stone?

 This is not a flame.					~Ziggy

∂20-Jun-89  1424	@mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:jinx@zurich.ai.mit.edu 	Sticks and stones  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89  14:24:17 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14327;
          20 Jun 89 17:04 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 17:02:14 EDT
Received: from ZURICH.AI.MIT.EDU (CHAMARTIN.AI.MIT.EDU) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267471; 20 Jun 89 17:01:11 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Tue, 20 Jun 89 16:58:22 edt
Date: Tue, 20 Jun 89 16:58:22 edt
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Message-Id: <8906202058.AA02376@ZURICH.AI.MIT.EDU>
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@ZERMATT.lcs.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Tue, 20 Jun 89 15:58:40 EDT <8906201958.AA15522@hx.LCS.MIT.EDU>
Subject: Sticks and stones
Reply-To: jinx@zurich.ai.mit.edu

I'm confused about the perceived ultimatum and hostilities between the
IEEE and RnRS communities.

To start with, please remember that the intersection between the IEEE
working group and the RnRS community is almost exactly the IEEE WG.
Thus this is internal fighting inside the RnRS community.

Second, some of you have perceived the request to reexamine the
decision to make the LIST-MUMBLEs essential as an ultimatum.  It is
nothing of the sort, nor does it want to be.

The IEEE WG decided that the procedures were usefuly enough that they
deserved to be in the standard.  Note that the decision of exactly
what set of procedures to standardize over is purely a matter of
aesthetics and practicality, never a technical reason.  While everyone
(as far as I know) agrees that we should standardize on LENGTH, it is
obvious that other procedures are much more controversial.

The WG has very strong feelings about making the IEEE draft standard a
strict subset of the essential subset of the appropriate RnRS.  It
therefore politely requested reexamination of the decision to make the
LIST-MUMBLEs essential.  The answer came back saying NO.  There was no
intended coercion or anything after that.  Why all the antagonism?

Please calm down, and READ the messages being sent.

∂20-Jun-89  1428	@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:mkatz@sesame.stanford.edu 	Sticks and stones    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89  14:27:58 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29905;
          20 Jun 89 16:56 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 16:31:55 EDT
Received: from sesame.Stanford.EDU (INTERNET|36.22.0.169) by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267450; 20 Jun 89 16:30:43 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA14897; Tue, 20 Jun 89 13:29:37 PDT
Date: Tue, 20 Jun 89 13:29:37 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906202029.AA14897@sesame.Stanford.EDU>
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zermatt.lcs.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Tue, 20 Jun 89 15:58:40 EDT <8906201958.AA15522@hx.LCS.MIT.EDU>
Subject: Sticks and stones

   Date: Tue, 20 Jun 89 15:58:40 EDT
   From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>


    I vaguely recall an agreement a short time ago that there was going to
   be a Standard Library of Scheme procedures. It was my understanding at the
   time that all inessential procedures were going to be migrated to this
   section (this may have been a halucination on my part).

    Perhaps we could rechannel our hostilities between the Standards folks
   and the R* folks into fulfilling that unforced promise to all submit
   useful nonessential stuff to the Librarian.

    This should also stimulate a discussion among the standards folks on
   whether the R* Standardized Library stuff should be in the Standard
   or not. That, I think, should be the sole issue to be discussed...
   blackmailing the R* folks should not be the issue (you know, ``if
   you folks don;t make this essential in *your* report then you can't
   have it in *our* standard''. That is the ultimatum as I see it.)

    Is focussing on the Library a viable alternative to sticks and stones
   or am I just tossing another stick/stone?

    This is not a flame.					~Ziggy


I strongly support your call for resurrecting the library (yellow pages).
Somehow the library seems to have died, I suspect as a result of the lack of a
standard macro facility.  Many of the things people wanted to place in the
library cannot be written in an implementation independent fashion (i.e., in
R*RS) without standard macros.  Therefore, lets get macros and the library
going ASAP.

					Morry Katz
					katz@polya.stanford.edu

∂20-Jun-89  1437	@MC.lcs.mit.edu,@life.ai.mit.edu:Stewart.Clamen@clamen.avalon.cs.cmu.edu 	LIST-REF and LIST-TAIL    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89  14:37:27 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ac01489;
          20 Jun 89 17:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 17:08:27 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id ab12917;
          20 Jun 89 17:03 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA03103; Tue, 20 Jun 89 17:03:11 EDT
Return-Path: <Stewart.Clamen@clamen.avalon.cs.cmu.edu>
Received: from CLAMEN.AVALON.CS.CMU.EDU ([128.2.220.41]) by ZURICH.AI.MIT.EDU; Tue, 20 Jun 89 17:00:22 edt
Message-Id: <8906202100.AA02883@ZURICH.AI.MIT.EDU>
Date: Tue, 20 Jun 89 17:02:10 EDT 
From: Stewart.Clamen@cs.cmu.edu
To: scheme-standard@zurich.ai.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
Subject: LIST-REF and LIST-TAIL
Reply-To: clamen@cs.cmu.edu



Does anyone who was at the last Standardization meeting remember the
motivations which led to our desire to have LIST-REF and LIST-TAIL in
the language (and thus resulting in a request of the R*RS Group to
promote the two procedures from "optional" to "essential")?  I was
there, but I cannot recall the discussion that led to this decision.
Perhaps if those ideas were resurrected now for the benefit of R*RS,
we might be able to resolve this issue and get on to more important
things?


						SMC


P.S. I really don't want to send this to BOTH lists, but what choice
     do I have?

∂20-Jun-89  1500	@mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:cph@ZURICH.ai.mit.edu 	Sticks and stones   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89  14:59:52 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16724;
          20 Jun 89 17:50 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 17:48:00 EDT
Received: from ZURICH.AI.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267499; 20 Jun 89 17:47:00 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Tue, 20 Jun 89 17:44:14 edt
Date: Tue, 20 Jun 89 17:44:14 edt
From: Chris Hanson <cph@ZURICH.ai.mit.edu>
Message-Id: <8906202144.AA03583@ZURICH.AI.MIT.EDU>
To: jinx@ZURICH.ai.mit.edu
Cc: rrrs-authors@ZERMATT.lcs.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Tue, 20 Jun 89 16:58:22 edt <8906202058.AA02376@ZURICH.AI.MIT.EDU>
Subject: Sticks and stones

   Date: Tue, 20 Jun 89 16:58:22 edt
   From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>

   It
   therefore politely requested reexamination of the decision to make the
   LIST-MUMBLEs essential.  The answer came back saying NO.

More precisely: some members of the authors committee have replied NO.

∂20-Jun-89  1542	@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:mkatz@sesame.stanford.edu 	Sticks and stones    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89  15:39:19 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05171;
          20 Jun 89 18:27 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jun 89 18:25:21 EDT
Received: from SESAME.STANFORD.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 267520; 20 Jun 89 18:24:16 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA15385; Tue, 20 Jun 89 15:23:41 PDT
Date: Tue, 20 Jun 89 15:23:41 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906202223.AA15385@sesame.Stanford.EDU>
To: rrrs-authors@zermatt.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 20 Jun 89 17:44:14 edt <8906202144.AA03583@ZURICH.AI.MIT.EDU>
Subject: Sticks and stones

The general consensus seems to be that my original message on list-tail and
list-ref read much more strongly than I intended.  Again, my sincerest
apologies to cph and anyone else in the WG who I offended.  I only wanted to
express my feeling that standardization should not carry any more weight in
R*RS discussions than that which would normally be given to members of
the WG as members of the R*RS community.  I continue to believe that list-tail
and list-ref should not become essential procedures, but not at the expense of
losing friends.  There are more important battles to be fought.
					Morry Katz
					katz@polya.stanford.edu

∂20-Jun-89  1644	@mc.lcs.mit.edu,@life.ai.mit.edu,@fog.cs.uoregon.edu:will@cs.uoregon.edu 	LIST-REF, LIST-TAIL  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89  16:44:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07266;
          20 Jun 89 19:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jun 89 19:32:57 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07207;
          20 Jun 89 19:27 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA05327; Tue, 20 Jun 89 19:27:03 EDT
Return-Path: <@fog.cs.uoregon.edu:will@cs.uoregon.edu>
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by ZURICH.AI.MIT.EDU; Tue, 20 Jun 89 19:24:08 edt
Received: from fog.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
	(5.59++/IDA-1.2.8) id AA14125; Tue, 20 Jun 89 16:26:27 PDT
Received: by fog.cs.uoregon.edu; Tue, 20 Jun 89 16:24:24 PDT
Date: Tue, 20 Jun 89 16:24:24 PDT
From: will@cs.uoregon.edu
Message-Id: <8906202324.AA11051@fog.cs.uoregon.edu>
To: cph@zurich.ai.mit.edu
Subject: LIST-REF, LIST-TAIL
Cc: rrrs-authors@zurich.ai.mit.edu

Chris, I think it would help the authors if you could explain why the
P1178 group feels that LIST-REF and LIST-TAIL need to be in the IEEE
standard.  Right now the only thing we've got to go on is the fact that
P1178 has requested that they be made essential.  As an editor of R4RS,
I don't feel comfortable making that change (in the face of a contrary
decision at Snowbird and an objection recently registered on rrrs-authors)
without some kind of technical rationale.

Peace, Will

∂20-Jun-89  2306	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #142 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 20 Jun 89  23:06:44 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12949;
          21 Jun 89 1:19 EDT
Date: 21 JUN 89  00:08:03 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #142 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8906210119.aa12949@mintaka.lcs.mit.edu>

Scheme Digest #142                             21 JUN 89  00:08:03 EDT

Today's Topics:

        "unspecified" and SET!
        "unspecified" and SET!
        "unspecified" and SET!

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

Date: 20 Jun 89 01:48:58 GMT
From: Vincent Manis <att!alberta!ubc-cs!grads.cs.ubc.ca!manis@bloom-beacon.mit.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <2281@ubc-cs.UUCP>

I've bitten my tongue on this, but I really can't see the point of
#!unspecified. Perhaps it would be nice in theory (especially if 

(define loop  
  (lambda (x)
      (loop (1+ x))))

returned #!unspecified, which would then be equivalent to `bottom' in
the Scott-Strachey world), but it seems pointless.

One can argue, as somebody has, that the existing behaviour
distinguishes between expressions and commands; however, Scheme already
has a strong notion of side effects (unlike, say, Miranda), and
whether a side-effecting procedure yields (), #f, an unspecified
result, or #!unspecified really makes no difference to anybody, except
in one place, which I'll mention in a moment. 

I regard `returns an unspecified result' as an injunction not to place
a call to a procedure in a value-returning position, e.g., the last
step in a lambda or begin. If I wrote a Scheme compiler, fascist that
I am, I would probably generate an error message for such a usage.
Going to the trouble to develop a calculus of unspecified values
strikes me as almost as silly as some of the things I did when I was
involved in writing an Algol 68 compiler.

The one place where #!unspecified makes some sense is in
Read-Eval-Print loops. One can use #!unspecified as a trigger that the
result is not to be printed. But then one does not need to change the
language: PC Scheme, for example, has *the-non-printing-object*. 

If it ain't broke, don't fix it.
____________  Vincent Manis                    | manis@cs.ubc.ca
___ \  _____  The Invisible City of Kitezh     | manis@cs.ubc.cdn
____ \  ____  Department of Computer Science   | manis%cs.ubc@relay.cs.net
___  /\  ___  University of British Columbia   | uunet!ubc-cs!manis
__  /  \  __  Vancouver, BC, Canada V6T 1W5    | (604) 228-2394
_  / __ \  _  "Theoretical computer science helps me convince people that
____________  my indecisiveness is really Nondeterminism, which sounds like
              a much more positive characteristic." -- a student
              

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

Date: 20 Jun 89 16:29:44 GMT
From: Brad Pierce <pierce@locus.ucla.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <25058@shemp.CS.UCLA.EDU>

In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes:
  << Stuff omitted. >>
>I regard `returns an unspecified result' as an injunction not to place
>a call to a procedure in a value-returning position, e.g., the last
>step in a lambda or begin. If I wrote a Scheme compiler, fascist that
>I am, I would probably generate an error message for such a usage.
  << Stuff omitted. >>

This is really not a criticsm, only a question. How does one go about
building a compiler that can detect when a procedure is going to 
return an unspecified result, especially those which sometime return
unspecified values and sometimes return specified values? For example,
in an object-oriented program most objects will respond to some
messages with actual information and to some messages with unspecified
values. On the face of it, it sounds very difficult to determine such
things syntactically. And wouldn't runtime checking amount to 
introducing the unspecified object?

It doesn't seem right to me that a user should have to know the 
full specifications of an object before being able to confidently
send messages to that object.  It would seem preferable to me to
be able to check whether the result returned has any information
content.

Also in this discussion I haven't heard any mention of my suggestion
to see the unspecified object as being analogous to NaN in the IEEE
numeric standard. Is that a bad analogy? Is NaN a bad idea? Just
wondering.

-- Brad

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

Date: Tue, 20 Jun 89 18:15:21 EDT
From: Alan Bawden <ALAN%ML.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU>
Subject:  "unspecified" and SET!
Message-ID: <10160.890620.ALAN@ML.AI.MIT.EDU>

    Date: 19 Jun 89 23:24:37 GMT
    From: Dorai Sitaram <titan!dorai@rice.edu>
      How do you deal with the other "commands" of Scheme? (E.g., READ,
      SET-CAR!, PRINTF.) Easier than SET!. SIGMA-like counterparts need
      _not_ be made for these, as that would lead to a plethora of special
      forms (as opposed to 'procedures'). All of these "command"
      procedures now take an additional argument for "the body" (thunk
      actually) whose value is returned. 

So we would write

  (NEWLINE (CURRENT-OUTPUT-PORT)
    (LAMBDA ()
      (WRITE X (CURRENT-OUTPUT-PORT)
	(LAMBDA () X))))

to newline, and then output and return the current value of X.  (Or perhaps
the continuations are passed as the first argument -- it doesn't matter in
the current discussion.)

Now it would seem to me that the most uniform way to include assignment in
this scheme, is to have SET! take a continuation as well.  So

  (SET! X (+ X 1)
    (LAMBDA () X))

would increment the value of X and return the new value.

SET! is still a keyword, so this isn't -exactly- parallel with the
side-effecting procedures.  But I'll bet that once people start writing
programs using this scheme, the thing that will impress them the most is
that whenever they perform a side-effect they have to create an explicit
continuation to wait for the side-effect to happen.  And I'll bet they will
be most comfortable if they have to make exactly the same kind of
continuation for SET!.

I'm currently working on a language where users really -must- control
sequencing by explicitly using thunks, so I'm very interested in linguistic
constructs that support this style.  Actually, in my case its worse than in
plain Scheme, because users must also exert control over when variables are
-read- as well as written.  Thus users have to write something like

  (LOOK! X
    (LAMBDA (VALUE)
      (SET! X (+ 1 VALUE)
	(LAMBDA ()
	  <whatever>
	  ))))

to increment the value of X, because if they wrote

    (SET! X (+ 1 X)
      (LAMBDA ()
	<whatever>
	))

the occurrence of X in (+ 1 X) might be taken to refer to the value of X
-after- the SET! happens (so that the value of X would become the fixed
point of (lambda (n) (+ 1 n))!).


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

End of Scheme Digest
********************

∂21-Jun-89  1450	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@zurich.ai.mit.edu 	Librarian    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 21 Jun 89  14:50:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00767;
          21 Jun 89 17:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jun 89 17:24:49 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11988;
          21 Jun 89 17:18 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00513; Wed, 21 Jun 89 17:01:12 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Wed, 21 Jun 89 13:25:19 edt
Date: Wed, 21 Jun 89 13:25:19 edt
From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
Message-Id: <8906211725.AA13445@ZURICH.AI.MIT.EDU>
To: rrrs-authors%mc.lcs.mit.edu@life.ai.mit.edu
Subject: Librarian
Reply-To: jinx@zurich.ai.mit.edu

Jonathan Rees has offered to be the next Scheme librarian.
The original term was supposed to be 6 months, but it has been two years
since I was appointed, it is probably high time for someone
(especially a more activist person) to replace me.

I don't know what the proper procedure to arrane for succession is but
I guess at the very least the following steps must be taken:

1) Ask for any other interested parties.  Is there anyone else?
2) Vote on a new librarian among the interested parties.  This is moot
if there are no other interested parties, or they are willing to defer
to JAR.

If I don't hear from anyone else in the next two weeks, I will assume
that no one will contest Jonathan's appointment, and will send a message
announcing this fact.

∂21-Jun-89  1457	@mc.lcs.mit.edu,@life.ai.mit.edu:Gateley@tilde.csc.ti.com 	Re: LIST-REF and LIST-TAIL
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 21 Jun 89  14:56:14 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05698;
          21 Jun 89 17:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jun 89 17:30:51 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18618;
          21 Jun 89 17:21 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00412; Wed, 21 Jun 89 16:58:06 EDT
Return-Path: <Gateley@tilde.csc.ti.com>
Received: from ti.com (ti.com) by ZURICH.AI.MIT.EDU; Wed, 21 Jun 89 16:52:40 edt
Received: by ti.com id AA05959; Wed, 21 Jun 89 10:33:55 CDT
Received: from Casablanca by tilde id AA13214; Wed, 21 Jun 89 10:24:24 CDT
Message-Id: <2823434649-13090092@Casablanca>
Sender: GATELEY@casablanca.csc.ti.com
Date: Wed, 21 Jun 89  10:24:09 CDT
From: John Gateley <Gateley@tilde.csc.ti.com>
To: clamen@cs.cmu.edu
Cc: rrrs-authors@zurich.ai.mit.edu, scheme-standard@zurich.ai.mit.edu
Subject: Re: LIST-REF and LIST-TAIL
In-Reply-To: Msg of Tue, 20 Jun 89 17:02:10 EDT  from Stewart.Clamen@cs.cmu.edu

>Does anyone who was at the last Standardization meeting remember the
>motivations which led to our desire to have LIST-REF and LIST-TAIL in
>the language (and thus resulting in a request of the R*RS Group to
>promote the two procedures from "optional" to "essential")?

As secretary for the last meeting, I have dug out my notes:

The arguments for:
  There is vector-ref and string-ref, so there should be list-ref.
  This conforms to Will C's law of least surprises.
  These can be implemented more efficiently than the naive way if
    the implementation uses cdr-coding. (And efficiency can be
    considered an important issue, consider substring).
  They provide continuity of error condition for reading past the end
    with vector- and string-ref.
The arguments against:
  They can be implemented trivially in terms of car and cdr.
  They belong in an appendix (the response to this was that an
    appendix is not binding).
  Lists and vectors are not the same, so we shouldn't be concerned with
    uniformity between them.

A final comment: At the point where it was clear that list-ref was going
to be kept, it was mentioned that list-tail should be kept too.

Hope this helps,

John
gateley@m2.csc.ti.com or gateley@csc.ti.com or gateley@zoo.csc.ti.com

∂21-Jun-89  2238	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #143 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 21 Jun 89  22:38:19 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09436;
          22 Jun 89 1:04 EDT
Date: 22 JUN 89  00:08:41 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #143 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8906220104.aa09436@mintaka.lcs.mit.edu>

Scheme Digest #143                             22 JUN 89  00:08:41 EDT

Today's Topics:

        Scheme Digest #125 
        "unspecified" and SET!
        "unspecified" and SET!

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

Date: Wed, 21 Jun 89 15:48 EDT
From: Andre van Meulebrouck <vanMeule@allegheny.scrc.symbolics.com>
Subject: Scheme Digest #125 
Message-ID: <19890621194848.5.VANMEULE@PERTA.SCRC.Symbolics.COM>

    Date: Thu, 25 May 89 02:27:13 -0700
    From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>

    Very well.  I hereby specify an object whose name is

	    #UNSPECIFIED

    Any association between this name and some meaning in your mind is
    coincidental.  I propose that all functions/forms that under some
    conditions currently return an unspecified value should now return a
    value which is EQ? to the value named by #UNSPECIFIED under those same
    conditions.

    Note that you are only in violation of R3RS if you *tell* me that that
    is what you do...

    Seriously: It's a non-damaging change, and there seems to be concensus
    that it is valuable to some part of the community and has no impact to
    speak of on anyone else.

    Let's do it.

    Jon

[Disclaimer:  my opinions are purely my own.]

An off-the-cuff comment after seeing the argument posed that way (↑↑) is:  "Why
not?  After all there is canonical truth!".

I see a lot of parallels between canonical unspecified and canonical truth.

I'm not taking sides however, because my jury's still out and/or I don't care
enough to get really religious one way or the other about it.

BTW:  I think the whole thing with nil vs. () vs. #f got a lot of mental energy
spent on it, and even after all that mind power being focused on that issue, I'm
still not convinced that things are now consistent or appreciably cleaner than
before:  the net outcome seems to have hypocrisies of its own such that I'm not
convinced Scheme is truly better off than Common Lisp (on the nil issue) for all
the hubbub and hoopla.

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

Date: Wed, 21 Jun 89 14:17:54 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906212117.AA20117@sesame.Stanford.EDU>
Subject: "unspecified" and SET!

At the R*RS meeting in Snowbird we discussed the possibility of adding some
form of multiple values to Scheme and allowing continuations to accept multiple
values.  I wonder if the solution to the problem of what should be returned by
side effecting procedures like SET! is to just have them return no values (i.e.
a zero arity multiple value).  As long as continuations can handle multiple
values appropriately, it seems to me that this solution would have many, if not
all, of the advantages of #!UNSPECIFIED without introducing many of the
undesirable side effects.

					Morry Katz
					katz@polya.stanford.edu

P.S.  After the meeting at Snowbird, Guy Steele and I came to an agreement as
      to the correct of the two conflicting semantics for multiple values to
      continuations that we proposed.  At that time, we believed that this
      solution would probably be acceptable to the great majority of the
      community.  Is there interest in having the proposal written up for
      future consideration?  I would be willing to strain my memory in an
      attempt to creat such a proposal if there is genuine interest.

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

Date: 21 Jun 89 22:47:44 GMT
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <CHAYNES.89Jun21174744@iuvax.cs.indiana.edu>


   From: mkatz@SESAME.STANFORD.EDU (Morris Katz)
   Newsgroups: comp.lang.scheme
   Date: 21 Jun 89 21:17:54 GMT
   ...
   P.S.  After the meeting at Snowbird, Guy Steele and I came to an agreement as
	 to the correct of the two conflicting semantics for multiple values to
	 continuations that we proposed.  At that time, we believed that this
	 solution would probably be acceptable to the great majority of the
	 community.  Is there interest in having the proposal written up for
	 future consideration?  I would be willing to strain my memory in an
	 attempt to creat such a proposal if there is genuine interest.

I'm interested.

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

End of Scheme Digest
********************

∂22-Jun-89  0706	@mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu 	Useful, but not essential
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89  07:06:13 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26763;
          22 Jun 89 9:50 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 09:46:09 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa26569;
          22 Jun 89 9:38 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA22682; Thu, 22 Jun 89 06:36:10 PDT
Message-Id: <8906221336.AA22682@mojave.Stanford.EDU>
Received: by sid; Thu, 22 Jun 89 06:38:39 pdt
Date: Thu, 22 Jun 89 06:38:39 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: shaff@sesame.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Mike Shaff's message of Tue, 20 Jun 89 07:09:44 PDT <8906201409.AA13286@sesame.Stanford.EDU>
Subject: Useful, but not essential

   From: Mike Shaff <shaff@sesame.stanford.edu>

   It is my opinion that non-essential procedures, were to be considered
   potentially useful for the user, hence implementors were given a possible
   binding for the specified functionality.  This was a method by which we
   could avoid having standard 'user environment' procedures with wildly
   divergent names/functionality.

Normally, I am inclined to agree with Mike's views.  From the
perspective of someone who is interested in writing portable Scheme
programs, however, I cannot overemphasize the desirability of
standardizing certain common functionality even though it is not
strictly necessary.

*If* there existed a standard Scheme library, then I would certainly
accept the view that LIST-REF and LIST-TAIL should be part of the
library and not part of the language.  In the absence of such a
library, preserving them seems warranted because of their utility.

Jon Shapiro

∂22-Jun-89  1210	@MC.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	LIST-REF and LIST-TAIL   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89  12:10:08 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01255;
          22 Jun 89 15:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 14:59:17 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01178;
          22 Jun 89 14:55 EDT
Received: from ZURICH.AI.MIT.EDU by life.ai.mit.edu (4.0/AI-4.10) id AA00684; Thu, 22 Jun 89 14:53:42 EDT
Return-Path: <mkatz@sesame.Stanford.EDU>
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by ZURICH.AI.MIT.EDU; Thu, 22 Jun 89 14:50:44 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA24530; Thu, 22 Jun 89 11:52:42 PDT
Date: Thu, 22 Jun 89 11:52:42 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906221852.AA24530@sesame.Stanford.EDU>
To: Gateley@tilde.csc.ti.com
Cc: clamen@cs.cmu.edu, rrrs-authors@zurich.ai.mit.edu, 
    scheme-standard@zurich.ai.mit.edu
In-Reply-To: John Gateley's message of Wed, 21 Jun 89  10:24:09 CDT <2823434649-13090092@Casablanca>
Subject: LIST-REF and LIST-TAIL

   Sender: GATELEY@casablanca.csc.ti.com
   Date: Wed, 21 Jun 89  10:24:09 CDT
   From: John Gateley <Gateley@tilde.csc.ti.com>

   >Does anyone who was at the last Standardization meeting remember the
   >motivations which led to our desire to have LIST-REF and LIST-TAIL in
   >the language (and thus resulting in a request of the R*RS Group to
   >promote the two procedures from "optional" to "essential")?

   As secretary for the last meeting, I have dug out my notes:

   The arguments for:
     There is vector-ref and string-ref, so there should be list-ref.
     This conforms to Will C's law of least surprises.
     These can be implemented more efficiently than the naive way if
       the implementation uses cdr-coding. (And efficiency can be
       considered an important issue, consider substring).
     They provide continuity of error condition for reading past the end
       with vector- and string-ref.
   The arguments against:
     They can be implemented trivially in terms of car and cdr.
     They belong in an appendix (the response to this was that an
       appendix is not binding).
     Lists and vectors are not the same, so we shouldn't be concerned with
       uniformity between them.

   A final comment: At the point where it was clear that list-ref was going
   to be kept, it was mentioned that list-tail should be kept too.

   Hope this helps,

   John
   gateley@m2.csc.ti.com or gateley@csc.ti.com or gateley@zoo.csc.ti.com


As part of an attempt to strive for uniformity, I was appointed to fill in the
gaps to make lists, vectors, and strings uniform for R4RS.  I sent out a
proposal on this many moons ago and got no responses or comments.  What ever
happened?  Did people give up on this idea?  It seems pertinent since
uniformity would require a vector-tail analogous to list-tail.  Somehow
vector-tail rubs me wrong.
					Morry Katz
					katz@polya.stanford.edu

∂22-Jun-89  1257	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	[chaynes@iuvax.cs.indiana.edu: [will@cs.uoregon.edu: LIST-REF, LIST-TAIL]]
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89  12:57:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01860;
          22 Jun 89 15:51 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 15:48:28 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01819;
          22 Jun 89 15:45 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.0/AI-4.10) id AA02172; Thu, 22 Jun 89 15:44:38 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Thu, 22 Jun 89 15:41:49 edt
Date: Thu, 22 Jun 89 15:41:49 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8906221941.AA27917@ZURICH.AI.MIT.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Subject: [chaynes@iuvax.cs.indiana.edu: [will@cs.uoregon.edu: LIST-REF, LIST-TAIL]]

Date: Wed, 21 Jun 89 17:38:18 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: cph@ZURICH.AI.MIT.EDU
Cc: will@fog.cs.uoregon.edu
In-Reply-To: Chris Hanson's message of Tue, 20 Jun 89 19:44:57 edt <8906202344.AA04669@ZURICH.AI.MIT.EDU>
Subject: [will@cs.uoregon.edu: LIST-REF, LIST-TAIL]

   Date: Tue, 20 Jun 89 19:44:57 edt
   From: cph@ZURICH.AI.MIT.EDU (Chris Hanson)

   Chris, can you provide this information?  I don't remember precisely
   what happened.  All I know is that the editors recommended dropping
   these procedures along with quite a few others, and at the meeting it
   was voted to keep these two.

   Date: Tue, 20 Jun 89 16:24:24 PDT
   From: will@cs.uoregon.edu
   To: cph@zurich.ai.mit.edu
   Subject: LIST-REF, LIST-TAIL
   Cc: rrrs-authors@zurich.ai.mit.edu

   Chris, I think it would help the authors if you could explain why the
   P1178 group feels that LIST-REF and LIST-TAIL need to be in the IEEE
   standard.  Right now the only thing we've got to go on is the fact that
   P1178 has requested that they be made essential.  As an editor of R4RS,
   I don't feel comfortable making that change (in the face of a contrary
   decision at Snowbird and an objection recently registered on rrrs-authors)
   without some kind of technical rationale.

   Peace, Will

You included all the info that I have, and all that I think is
relivant, in your recent note to the notesfile.  There were no
technical arguments and don't need to be.  The recommendation was
based on a feeling that LIST-REF and LIST-TAIL were sufficiently
important that they deserved to be standard, and they won't be as
efficient in some implementations if they aren't primitive.  I expect
most people share my ambivalence on this issue.  I think our
suggestion was a reasonable one, but if the rrrs-authors don't go for
it, then they win and we should move on to more important things.


∂22-Jun-89  1913	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Responses to a month of mail 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89  19:12:59 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12567;
          22 Jun 89 22:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Jun 89 22:02:06 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa28588; 22 Jun 89 21:56 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 22 JUN 89 18:56:21 PDT
Date: Thu, 22 Jun 89 18:58:58 PDT
From: Pavel.pa@xerox.com
Subject: Responses to a month of mail
In-reply-to: <8905260106.AA18779@fog.cs.uoregon.edu>
To: rrrs-authors@mc.lcs.mit.edu
Cc: Pavel.pa@xerox.com
Message-ID: <890622-185621-2108@Xerox>

Boy, I leave for a simple four-week vacation and no sooner do I get out of
the country but the various Scheme lists come to glorious life, full of
ideas and controversy.  I have some comments on several things that have
been said over the past month.

=======

    Date: Thu, 25 May 89 18:06:49 PDT
    From: William Clinger <will@fog.cs.uoregon.edu>
    Subject: planned changes to R3.95RS
    
    Sections 2.1 (Identifiers), 2.3 (Other notations), and 7.1.1 (Lexical
    structure).  Add ... as a new peculiar identifier.

I would like to request that some character (preferably either period or
colon) be set aside for use in those implementations experimenting with
module facilities.  In Scheme Xerox, we would like to have a notation for
``structured names'', in which the name of an ``interface'' is paired with
the name of an item in that interface.  Mesa and Modula use the notation
``Foo.Bar'', CLU uses ``foo$bar'', and Common Lisp uses ``foo:bar'' and
``foo::bar''.  Note that, for compatibility, the delimiter character canot
also be legal in identifiers.  With the current list of special alphabetic
characters (after the acceptance of ``@'' in the list), my options are the
following:

	#  \  |  [  ]  {  }  ,  '  `

The last three of these (and the first, to a lesser extent) are not
acceptable because the possibility of an unnoticed typo is too great (when
an stray space appears before the delimiter).  The brackets and braces
would look silly if they were unbalanced and are too cumbersome otherwise.
Backslash and vertical-bar look too much like escape characters (and are
such in Common Lisp).

The least unacceptable one is ``#''.  I suppose that I could live with it,
but I'd sure prefer either period or colon.  I'd therefore like to request
one of the following, listed in decreasing order of my preference:

1 - Remove period from the list of special subsequents (but leave ``...''
on the list of peculiar identifiers).  Period is already somewhat special
because of its use in the syntax of pairs and improper lists; this and its
use in other languages for structured names, makes it the best candidate,
in my opinion.

2 - Remove colon from the list of special initials.  The use of colon in
the Common Lisp (and Zetalisp) package systems is quite analagous to
structured names; there is thus significant precedence for the use of that
character in a Lisp-like language.

3 - Do nothing.  Sigh.

Whichever of these is accepted, though, I'd like the report to state a
commitment to keep either the period, colon, or hash character (as
appropriate) out of identifiers in the future, specifically to allow
compatible experimentation with structured names in module systems.

=======
    
    Date: Sun, 28 May 89 15:48:26 -0700
    From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
    Subject: Requested changes to R4RS
    
    If the LOAD routine is
    required to use READ, I could contemplate something like:

	(define (myload file)
	   (let ((standard-read read))
	     (set! read myread)
	     (load file)
	     (set! read standard-read)))

The possibility of changing the value of a variable in the initial
environment, such as READ here, has always bothered me a great deal.  In
long-lived, single address space systems, like the Lisp Machine or Cedar,
the normal mode of operation involves simultaneously running many
``programs'', usually written by different people.  Changing the meaning of
one of the language primitives is very likely to have a negative impact on
the robustness of the overall system.

In addition, aside from the (also distressing) idea above, that one should
customize the behaviour of a primitive by (presumably temporarily) changing
the meaning of some other primitive, there seems to be no good reason ever
to side-effect the initial environment.

I would therefore like to request that R4RS state that it is an error to
assign to (or redefine) any of the variables defined in the report.  In
particular, in Scheme Xerox, we intend to signal that error at compile-time
and would like this behaviour not to violate the specification.  Please
note that this doesn't rule out the possibility of certain debugging tools
making such assignments, they just can't appear in programs.

=======

    Date: Fri, 2 Jun 89 16:00:32 PDT
    From: William Clinger <will@fog.cs.uoregon.edu>
    Subject: Re:  [ramsdell: truth of (), etc...]
    
        <BODY> --> (define <I> <EXP>) ... <SEQUENCE> ==>
          ((lambda (<I> ...)
             (set! <I> <EXP>)
             ...
             <SEQUENCE>)
           <UNDEFINED> ...)
    
    (In other words, the proposal is to require that internal definitions
be
    evaluated from left to right, with each succeeding definition allowed
to
    use variables defined before it.)

I certainly don't want to exchange the LETREC semantics for this LET* one.
One of my most common uses for internal definitions is local recursive
procedures.

I'd like to request that the syntax and semantics of bodies and programs be
identical, but not quite like either one in R3RS.  Let the syntax be

	<program> ::= { <expression> | <definition> | (begin <program>) }*
	<definition> ::= (define <variable> <expression>)
	    | (define (<variable> <def formals>) <body>)
	<body> ::= <program>

so definitions and expressions can be freely mixed, both at ``top level''
and internally.  Also, BEGINs at top level need not consist entirely of
definitions or entirely of expressions, as in R3.95RS.  The semantics is as
follows:

-- (begin <program>)  is entirely equivalent to  <program> .
-- programs comprising only expressions and definitions have the same
meaning as given in the formal semantics in R3.95RS; that is, bindings are
established for all defined variables giving them unspecified values after
which the program is evaluated in sequence, treating definitions as if they
were assignments.

This is the most uniform, consistent, and useful way I can see to resolve
the difference in semantics between internal and external definitions.

Will says:

    For what it's worth, here are the two reasons that I prefer the
existing
    semantics:
    
      1.  I find that it is easier to understand code when I can assume
that
          the order of definitions doesn't matter.  That way I can read the
          definitions in any order.  This is a special case of the general
          principle that a more declarative semantics makes programs easier
          to understand.
      2.  (This reason is pretty weak.)  For the compiler writer, I think
the
          freedom to rearrange definitions makes closure analysis a little
          simpler when procedure definitions are mixed with definitions of
          variables containing non-procedure values.

Reason 1 would seem to apply equally well to the top level of Scheme
programs, but I suspect that Will would not be in favor of giving the
LETREC semantics to those definitions (it would make it very difficult to
get anything done).  I agree with Will on the strength of the second
reason.

=======

While I'm at it, I'd like to hear from others about why we allow

	(define (foo a) 17)
	==>  (define foo (lambda (a) 17))

but not the obvious extension of this (OK in C-Scheme, I think):

	(define ((foo a) b) (+ a b))
	==>  (define foo
	        (lambda (a)
	           (lambda (b)
	              (+ a b))))

I implemented this for Cedar Scheme and have found it quite useful.  I
can't see any reason to go halfway here, only allowing this abbreviation
one level deep.

=======

Just to summarize, I've made four proposals for R4RS in this message:

* Change the rules for the formation of identifiers,

* Outlaw assignments to built-in variables,

* Make the semantics of internal and external definitions identical, and

* Extend the syntax of procedure definitions.

	Pavel

∂22-Jun-89  2146	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #144 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 22 Jun 89  21:46:23 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20747;
          23 Jun 89 0:40 EDT
Date: 23 JUN 89  00:10:45 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #144 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8906230040.aa20747@mintaka.lcs.mit.edu>

Scheme Digest #144                             23 JUN 89  00:10:45 EDT

Today's Topics:

        "unspecified" and SET!

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

Date: 22 Jun 89 03:27:48 GMT
From: John Gateley <apple!sun-barr!texsun!pollux!ti-csl!m2!gateley@rutgers.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <81872@ti-csl.csc.ti.com>

In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes:
>Going to the trouble to develop a calculus of unspecified values
>strikes me as almost as silly as some of the things I did when I was
>involved in writing an Algol 68 compiler.
 ...
>____________  Vincent Manis                    | manis@cs.ubc.ca
 ...

Do you mean Matthias Felleisen's calculus for Scheme? It is neither a 
calculus of unspecified values nor silly. It is a better theoretical
basis for Scheme than the lambda value calculus: it includes both
set! style side effects and continuations in its equations.

John
gateley@m2.csc.ti.com

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

End of Scheme Digest
********************

∂23-Jun-89  0934	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	Responses to a month of mail    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 23 Jun 89  09:34:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13401;
          23 Jun 89 12:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Jun 89 12:22:56 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa23571;
          23 Jun 89 12:15 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA29108; Fri, 23 Jun 89 09:15:07 PDT
Date: Fri, 23 Jun 89 09:15:07 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906231615.AA29108@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu, Pavel.pa@xerox.com
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 22 Jun 89 18:58:58 PDT <890622-185621-2108@Xerox>
Subject: Responses to a month of mail

   Date: Thu, 22 Jun 89 18:58:58 PDT
   From: Pavel.pa@xerox.com


       Date: Sun, 28 May 89 15:48:26 -0700
       From: "Jonathan S. Shapiro" <shap@polya.stanford.edu>
       Subject: Requested changes to R4RS

       If the LOAD routine is
       required to use READ, I could contemplate something like:

	   (define (myload file)
	      (let ((standard-read read))
		(set! read myread)
		(load file)
		(set! read standard-read)))

   The possibility of changing the value of a variable in the initial
   environment, such as READ here, has always bothered me a great deal.  In
   long-lived, single address space systems, like the Lisp Machine or Cedar,
   the normal mode of operation involves simultaneously running many
   ``programs'', usually written by different people.  Changing the meaning of
   one of the language primitives is very likely to have a negative impact on
   the robustness of the overall system.

   In addition, aside from the (also distressing) idea above, that one should
   customize the behaviour of a primitive by (presumably temporarily) changing
   the meaning of some other primitive, there seems to be no good reason ever
   to side-effect the initial environment.

   I would therefore like to request that R4RS state that it is an error to
   assign to (or redefine) any of the variables defined in the report.  In
   particular, in Scheme Xerox, we intend to signal that error at compile-time
   and would like this behaviour not to violate the specification.  Please
   note that this doesn't rule out the possibility of certain debugging tools
   making such assignments, they just can't appear in programs.

The operative phrase when changing a built-in definition is obviously "caveat
emptor".  However, I do not believe in facist (-: languages.  I would aceed to
placing a warning about rebinding primitives in R*RS, but feel quite strongly
that prohibiting such is a bad idea. 
					Morry Katz
					katz@polya.stanford.edu

∂23-Jun-89  1328	@mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu 	Responses to a month of mail  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 23 Jun 89  13:27:59 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02892;
          23 Jun 89 16:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 23 Jun 89 16:21:07 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa02724;
          23 Jun 89 16:15 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA27573; Fri, 23 Jun 89 13:13:07 PDT
Message-Id: <8906232013.AA27573@mojave.Stanford.EDU>
Received: by sid; Fri, 23 Jun 89 13:15:34 pdt
Date: Fri, 23 Jun 89 13:15:34 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 22 Jun 89 18:58:58 PDT <890622-185621-2108@Xerox>
Subject: Responses to a month of mail

Regarding reserving a character for modules: I am torn.  On the one
hand, it is a good idea for experimental purposes.  On the other hand,
the fact that there is no general agreement on modules means that such
things won't port from one scheme to another, and I am reluctant to
see such a thing introduced into the language just when there is an
attempt to standardize - someone will subsequently decide to
standardize modules, which we don't yet have any concensus on.

Further, it strikes me that from the standpoint of the scheme system
I want

	foo:bar

to be a symbol in the same way that

	bar

is a symbol - the differentiation in interpretation, if any, should
happen in string-symbol (or its equivalent) in the reader.

The point is: I would buy that it would be valuable to state somewhere
in the symbol character stuff that some character [I like ':' - no
reason to be gratuitously different from existing LISP usage in the
absence of technical arguments favoring one character over another] is
intended to be used as a module separator in the future, and that
program authors are encouraged to write their programs accordingly,
but I do not think that it is necessary at this time to raise this to
the level of syntax, nor do I want to see the character removed from
the list of legal symbol name characters until their exists a compelling
rationale for doing so.

Proposal: add such a statement to R4RS.

on

∂26-Jun-89  0648	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #145 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 26 Jun 89  06:48:15 PDT
Received: by mintaka.lcs.mit.edu id ae25553; 26 Jun 89 9:20 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ab06579;
          26 Jun 89 0:39 EDT
Date: 26 JUN 89  00:07:06 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #145 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8906260039.ab06579@mintaka.lcs.mit.edu>

Scheme Digest #145                             26 JUN 89  00:07:06 EDT

Today's Topics:

        "unspecified" and SET!
        "unspecified" and SET!

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

Date: 23 Jun 89 02:01:05 GMT
From: Vincent Manis <att!alberta!ubc-cs!grads.cs.ubc.ca!manis@bloom-beacon.mit.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <2322@ubc-cs.UUCP>

In article <81872@ti-csl.csc.ti.com> gateley@m2.UUCP (John Gateley) writes:
>Do you mean Matthias Felleisen's calculus for Scheme? It is neither a 
>calculus of unspecified values nor silly. It is a better theoretical
>basis for Scheme than the lambda value calculus: it includes both
>set! style side effects and continuations in its equations.

To clarify, let me say emphatically that I *don't* mean Felleisen's
calculus. As John says, Felleisen's work is not at all silly. I was
instead referring to the proposals for #!unspecified, which, is either
the same as `bottom' in denotational semantics or it is not. In the
former case, #!unspecified should be returned, also, in both a
division by 0 and a non-terminating recursion. In the latter case,
#!unspecified is somewhat pointless (set! could just as easily return
`()), unless one has some reason for distinguishing the two.

While I do not care for William of Ockham's metaphysics, there is much
to say for his Razor. 

____________  Vincent Manis                    | manis@cs.ubc.ca
___ \  _____  The Invisible City of Kitezh     | manis@cs.ubc.cdn
____ \  ____  Department of Computer Science   | manis%cs.ubc@relay.cs.net
___  /\  ___  University of British Columbia   | uunet!ubc-cs!manis
__  /  \  __  Vancouver, BC, Canada V6T 1W5    | (604) 228-2394
_  / __ \  _  "Theoretical computer science helps me convince people that
____________  my indecisiveness is really Nondeterminism, which sounds like
              a much more positive characteristic." -- a student
              

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

Date: 25 Jun 89 22:17:45 GMT
From: Dorai Sitaram <titan!dorai@rice.edu>
Subject: Re: "unspecified" and SET!
Message-Id: <4011@kalliope.rice.edu>

In article <2281@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes:
>Going to the trouble to develop a calculus of unspecified values
>strikes me as almost as silly as some of the things I did when I was
>involved in writing an Algol 68 compiler.

If this is in response to my posting(s) entitled "unspecified and
set!"  (and I'm not sure it is -- Vincent doesn't say), I request
permission to shriek, "No! This is not what I meant!" ;-)

I was drawing attention to side-effecting constructs in the literature
(that they appeared in a calculus-definition is of secondary
importance) that give all the "power" of current Schemes WITHOUT
having to mess with (returning) unspecified values at all. I do, of
course, concur with Vincent that having an unspecified object like
#!unspecified is close to being the all-time great oxymoron of our
troubled times (though he might not use the selfsame words ;-]).

Second, the comparison that Vincent draws between "(#!)unspecified"
and "bottom" is not correct. "Bottom" stands for divergence
(non-termination) and occasionally, errors; "(#!)unspecified" is a
stopgap value concocted to stand for a meaningless value returned in a
TERMINATING computation.

--dorai
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------

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

End of Scheme Digest
********************

∂26-Jun-89  2154	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Responses to a month of mail  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 26 Jun 89  21:54:00 PDT
Received: by mintaka.lcs.mit.edu id ag14232; 27 Jun 89 0:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12978;
          26 Jun 89 22:17 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 26 Jun 89 22:11:59 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 228955; Mon 26-Jun-89 22:11:31 EDT
Date: Mon, 26 Jun 89 22:11 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Responses to a month of mail
To: Pavel.pa@xerox.com
cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <890622-185621-2108@Xerox>
Message-ID: <19890627021113.8.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Thu, 22 Jun 89 18:58:58 PDT
    From: Pavel.pa@xerox.com

	Date: Fri, 2 Jun 89 16:00:32 PDT
	From: William Clinger <will@fog.cs.uoregon.edu>
    
	    <BODY> --> (define <I> <EXP>) ... <SEQUENCE> ==>
	      ((lambda (<I> ...)
		 (set! <I> <EXP>)
		 ...
		 <SEQUENCE>)
	       <UNDEFINED> ...)
    
	(In other words, the proposal is to require that internal
	definitions be evaluated from left to right, with each succeeding
	definition allowed to use variables defined before it.)

    I certainly don't want to exchange the LETREC semantics for this LET*
    one.  One of my most common uses for internal definitions is local
    recursive procedures.

This remark confuses me.  I don't see anything LET* like about what Will
proposed here.  This looks to me to be exactly what you want if you want
internal definitions to behave like top level definitions.  It works just
fine to define local recursive procedures.  If it was LET*-like,
definitions wouldn't be able to refer to later definitions.

∂26-Jun-89  2155	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #146 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 26 Jun 89  21:55:12 PDT
Received: by mintaka.lcs.mit.edu id ai14240; 27 Jun 89 0:29 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13965;
          27 Jun 89 0:17 EDT
Date: 27 JUN 89  00:07:05 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #146 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8906270017.aa13965@mintaka.lcs.mit.edu>

Scheme Digest #146                             27 JUN 89  00:07:05 EDT

Today's Topics:

        Scheme Digest #145 

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

From: Chet Murthy <murthy@cs.cornell.edu>
Message-Id: <8906261457.AA02518@lakshmi.cs.cornell.edu>
Subject: Re: Scheme Digest #145 
Date: Mon, 26 Jun 89 10:57:57 -0400


Please remove me from the Scheme mailing list.

My addresses are:
murthy@cs.cornell.edu
murthy@svax.cs.cornell.edu

Thanks,
--chet--

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

End of Scheme Digest
********************

∂27-Jun-89  1311	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Responses to responses to responses    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 27 Jun 89  13:11:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22689;
          27 Jun 89 15:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jun 89 15:31:23 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa22336; 27 Jun 89 15:27 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 27 JUN 89 12:12:18 PDT
Date: Tue, 27 Jun 89 12:20:31 PDT
From: Pavel.pa@xerox.com
Subject: Responses to responses to responses
In-reply-to: <19890627021113.8.ALAN@PIGPEN.AI.MIT.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890627-121218-3423@Xerox>

Alan Bawden is quite right; a thinko made me misread David Bartley's
expansion of a body and think that it was a LET*-style expansion.  Sigh.

=====

Morry Katz says, ``I would aceed to placing a warning about rebinding
primitives in R*RS, but feel quite strongly that prohibiting such is a bad
idea.''

This is precisely what I'm asking for.  A warning would have to say
something like, ``If you redefine a primitive, you could lose horribly.''
I think we have a simple way of saying that, namely, ``It is an error to
redefine a primitive.''  The way you'll lose horribly in Scheme Xerox is
that your program won't compile.  I'm not asking R4RS to prohibit
redefinition, I'm simply asking it to let me do so in my own
implementation.

I forgot to mention in my previous message the other, fairly obvious
problem with allowing redefinition.  Just as a human program reader cannot
be sure of the semantics of any (even top-level) program fragment (since
the remainder of the program might redefine one or more of the primitives),
neither can the compiler.  Thus, without guaranteed knowledge of the
entirety of the program, the compiler cannot both preserve the semantics of
the program and code certain primitives inline.

Contrary to Morry's semi-facetious claim that prohibiting redefinition is
``fascist'', it is the only way that a compiler can answer the twin desires
of its customers for efficiency and correctness.

=====

Jonathan Shapiro says, ``I would buy that it would be valuable to state
somewhere in the symbol character stuff that some character ... is intended
to be used as a module separator in the future, and that
program authors are encouraged to write their programs accordingly, but I
do not think that it is necessary at this time to raise this to the level
of syntax ...''

Unfortunately, I don't believe that this is sufficient.  The only way
program authors can write their programs accordingly is to avoid using the
separator character at all.  Otherwise, their code will not run in
implementations that use structured names, since it will very likely refer
to undefined module/interface names.

Jonathans Shapiro and Rees (the latter in private mail) recommended that
the actual sequence of characters in an identifier's name have some
semantic significance, apart from giving the identity of the identifier.
Shapiro wanted names with colons in them to behave differently than names
without colons; Rees suggested a notion somewhat like ``conc-names'' in
Common Lisp's DEFSTRUCT facility, whereby the programmer could, in a
limited scope, give special semantics to all names with a particular
prefix.  These ideas feel very wrong to me, a violation of the
alpha-conversion rule.  The sequence of characters in a name shouldn't have
any semantics aside from their identity.

=======

My four proposals (see my previous message) still stand; does anyone else
have any comments on them?

	Pavel

∂27-Jun-89  1419	@MC.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Responses to responses to responses
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 27 Jun 89  14:19:22 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28271;
          27 Jun 89 17:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jun 89 17:09:07 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa08496;
          27 Jun 89 17:04 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Tue, 27 Jun 89 17:00:26 edt
Date: Tue, 27 Jun 89 17:00:26 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8906272100.AA09821@ZURICH.AI.MIT.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 27 Jun 89 12:20:31 PDT <890627-121218-3423@Xerox>
Subject: Responses to responses to responses

    Morry Katz says, ``I would aceed to placing a warning about rebinding
    primitives in R*RS, but feel quite strongly that prohibiting such is a bad
    idea.''

    This is precisely what I'm asking for.  A warning would have to say
    something like, ``If you redefine a primitive, you could lose horribly.''
    I think we have a simple way of saying that, namely, ``It is an error to
    redefine a primitive.''  The way you'll lose horribly in Scheme Xerox is
    that your program won't compile.  I'm not asking R4RS to prohibit
    redefinition, I'm simply asking it to let me do so in my own
    implementation.

I think you misunderstand Morry, but just in case, I'll state my
position, which I believe coincides with his and was the consensus of
most implementors a while ago.

An implementation that does not allow assignment of the initial
variables (including those bound to procedures) in an RnRs environment
is in ERROR.  Yes, I mean that.  I feel very strongly that the user
takes precedence over the system. 

It is acceptable, however, for an implementation to default to
"benchmark" mode, as long as the following two conditions are met:

1) There is a way to take it out of benchmark mode.
2) Appropriate warnings about redefinition/warning are given when the
implementation is in benchmark mode and an assignment/redefinition is
"attempted".

    Contrary to Morry's semi-facetious claim that prohibiting redefinition is
    ``fascist'', it is the only way that a compiler can answer the twin desires
    of its customers for efficiency and correctness.

I don't think you are right.  I think a compiler can answer both,
after providing declarations.  We are talking here about what
the behaviour should be in their absence.  You may be right that
utmost efficiency cannot be obtained without declarations, but that is
a small price to pay.

∂27-Jun-89  2001	@MC.lcs.mit.edu,@ZERMATT.lcs.mit.edu:SCHREQ@MC.lcs.mit.edu 	testing   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 27 Jun 89  20:01:23 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28060;
          27 Jun 89 22:55 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 27 Jun 89 22:52:34 EDT
Received: from MICKEY-MOUSE.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 269280; Tue 27-Jun-89 22:52:30 EDT
Date: Tue, 27 Jun 89 22:52 EDT
From: Scheme Requestee <SCHREQ@MC.lcs.mit.edu>
Subject: testing
To: rrrs-authors@MC.lcs.mit.edu
Message-ID: <"19890628025210.2.schreq@MC"@MICKEY-MOUSE.LCS.MIT.EDU>

Testing the list.

∂27-Jun-89  2147	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #147 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 27 Jun 89  21:47:18 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29209;
          28 Jun 89 0:37 EDT
Date: 28 JUN 89  00:07:08 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #147 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8906280037.aa29209@mintaka.lcs.mit.edu>

Scheme Digest #147                             28 JUN 89  00:07:08 EDT

Today's Topics:

        Looking for R*RS and XScheme source by ftp

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

Date: 27 Jun 89 17:16:32 GMT
From: John Lacey <lacey@tcgould.tn.cornell.edu>
Subject: Looking for R*RS and XScheme source by ftp
Message-Id: <8271@batcomputer.tn.cornell.edu>


	I'm looking for the Revised Report, as well as the
source to XScheme (by David Betz), preferably by ftp.  Actually,
if anyone knows of another free Scheme implementation, I would like
to hear about it.

	I'll take the report in any form I can get it, but I would
prefer a [La]TeX format.

-- 
John Lacey           |  Internet:  lacey@tcgould.tn.cornell.edu
running unattached   |  BITnet:    lacey@crnlthry
                     |  UUCP:      cornell!batcomputer!lacey

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

End of Scheme Digest
********************

∂28-Jun-89  0847	@mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Responses to a month of mail  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89  08:47:03 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24888;
          28 Jun 89 11:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 10:59:21 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa24526;
          28 Jun 89 10:58 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Wed, 28 Jun 89 10:55:21 edt
Date: Wed, 28 Jun 89 10:55:21 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8906281455.AA27360@ZURICH.AI.MIT.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 22 Jun 89 18:58:58 PDT <890622-185621-2108@Xerox>
Subject: Responses to a month of mail

Because of mailer problems on our file server (zurich), I did not read
your four point proposal until now.  Here are my thoughts:


    * Change the rules for the formation of identifiers,

I don't think this is warranted.  I think that lexical level
conventions for module references are a bad idea.

    * Outlaw assignments to built-in variables,

Definitely not.  Implementations should be built in such a way that
assignment/definition in an RnRs environment does not affect the
integrity of the implementation.  This should impose constraints on
the implementor, not the user.  Note that single address space does
not imply a flat namespace, which Lisp Machines effectively have.

I have "ideological" reasons against this proposal, and pragmatic ones
as well.

The main ideological reason is that the system/implementation is a
tool for the user, and as such it should accomodate the wishes of the
user, not viceversa.  Thus if a user wants to call CAR something he
writes/uses (in a Church pair implmentation, for example), he should
be allowed to do so.

The pragmatic reason may concern you more.  Presumably you would like
implementations to be able to add new primitives to the language
described in the report.  Given that the semantics of any programs
using them might be compromised in the same way that it would be when
using a "standard" primitive, you would disallow assignment and
redefinition of implementation-specific primitives as well.  This
implies that portability can only be achieved by using obscure names
(ie G00034), since any "reasonable" name is potentially reserved by
some implementation.

For example:  I may write my own structure facility (ignoring the
problem with portable macros, for the time being), and decide to use
my own even if the implementation provides a similar facility.  I
don't want to have to change all uses of defstruct or define-structure
whenever I port to a new implementation, but your proposal might force
me to.  An equivalent problem arises with the names of procedures.

    * Make the semantics of internal and external definitions identical, and

I agree that they should be the same in principle.  My personal
preference would be for making top level definitions behave like the
current letrec, ie. order independent.  This is, unfortunately, too
radical to be accepted by most people.  I prefer the current letrec
semantics to the proposed "sequential" semantics.

    * Extend the syntax of procedure definitions.

MIT Scheme has had this for a while, but we've decided to back out of
it.  The problem is that it does not combine well (in terms of
readability) with the following syntax for types, which we currently
believe to be a better use for parentheses in lambda lists:

(lambda ((x integer?) (y pair?))
  <some code>)


∂28-Jun-89  0940	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	Responses to responses to responses  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89  09:40:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25670;
          28 Jun 89 12:13 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 11:51:01 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa25200;
          28 Jun 89 11:48 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA21003; Wed, 28 Jun 89 08:47:46 PDT
Date: Wed, 28 Jun 89 08:47:46 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906281547.AA21003@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 27 Jun 89 12:20:31 PDT <890627-121218-3423@Xerox>
Subject: Responses to responses to responses

   Date: Tue, 27 Jun 89 12:20:31 PDT
   From: Pavel.pa@xerox.com

   Morry Katz says, ``I would aceed to placing a warning about rebinding
   primitives in R*RS, but feel quite strongly that prohibiting such is a bad
   idea.''

   This is precisely what I'm asking for.  A warning would have to say
   something like, ``If you redefine a primitive, you could lose horribly.''
   I think we have a simple way of saying that, namely, ``It is an error to
   redefine a primitive.''  The way you'll lose horribly in Scheme Xerox is
   that your program won't compile.  I'm not asking R4RS to prohibit
   redefinition, I'm simply asking it to let me do so in my own
   implementation.

You have very carefully perverted what I have said to suit your own fancy.  You
did not request that an implementation be allowed to prohibit redefinition of
the primitives, but stated that you wanted redefinition of a primitive to be an
error.  Your original request read as follows:

  "I would therefore like to request that R4RS state that it is an error to
  assign to (or redefine) any of the variables defined in the report.  In
  particular, in Scheme Xerox, we intend to signal that error at compile-time
  and would like this behavior not to violate the specification.  Please note
  that this doesn't rule out the possibility of certain debugging tools making
  such assignments, they just can't appear in programs."

If you would like to propose something that allows your system to consider
redefinition an error but does not require my system to do such, I might be
willing to consider it.

   I forgot to mention in my previous message the other, fairly obvious
   problem with allowing redefinition.  Just as a human program reader cannot
   be sure of the semantics of any (even top-level) program fragment (since
   the remainder of the program might redefine one or more of the primitives),
   neither can the compiler.  Thus, without guaranteed knowledge of the
   entirety of the program, the compiler cannot both preserve the semantics of
   the program and code certain primitives inline.

   Contrary to Morry's semi-facetious claim that prohibiting redefinition is
   ``fascist'', it is the only way that a compiler can answer the twin desires
   of its customers for efficiency and correctness.

Nearly everyones compiler currently allows a compiler directive to the effect
that primitives should be considered immutable and therefore inlineable.  This
has been done for the obvious efficiency reasons and does not require that the
language specification be altered to always prohibit modifying primitives.

					Morry Katz
					katz@polya.stanford.edu

∂28-Jun-89  1125	@mc.lcs.mit.edu,@ZURICH.ai.mit.edu:mkatz@sesame.stanford.edu 	Declare proposal  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89  11:25:49 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16802;
          28 Jun 89 13:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 12:22:43 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa25847;
          28 Jun 89 12:21 EDT
Return-Path: <mkatz@sesame.Stanford.EDU>
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by ZURICH.AI.MIT.EDU; Wed, 28 Jun 89 12:18:49 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA21063; Wed, 28 Jun 89 09:02:14 PDT
Date: Wed, 28 Jun 89 09:02:14 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8906281602.AA21063@sesame.Stanford.EDU>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: Declare proposal

I would like to propose that we make DECLARE a special form to be used for
compiler directives.  We do not have to standardize the complete format of
declare, at this time; but, I would like to set aside the name.  This would
allow greater portability of programs as friendly systems could merely ignore
declarations which they don't understand and give some type of warning.
					Morry Katz
					katz@polya.stanford.edu

∂28-Jun-89  1345	@mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com 	Re: A month of mail... 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89  13:45:30 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09897;
          28 Jun 89 16:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jun 89 15:21:07 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa15465;
          28 Jun 89 15:19 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa19941; 28 Jun 89 15:06 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
	id AA00388; Wed, 28 Jun 89 12:07:15 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA26696; Wed, 28 Jun 89 12:00:57 PDT
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
	id AA11945; Wed, 28 Jun 89 12:05:48 pdt
Message-Id: <8906281905.AA11945@bloom.LA.TEK.COM>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: Re: A month of mail...
Date: Wed, 28 Jun 89 12:05:43 PDT
From: kend@bloom.la.tek.com

$0.02


>> * Change the rules for the formation of identifiers,

I also feel that strange naming conventions are not warrented for module
experimentation.  Modules seen as compile-time early-binding, first-class
environments [(*value module-1 'foo)], etc. do not require this.


>> * Outlaw assignments to built-in variables,

[ASIDE: I prefer binding to side effects for specialization of routines.
John should be asking for more general tools:
 "(define myload (make-load my-reader))"
].

You probably do want an implementation environment in which you can depend
on names to mean certain things [(define-constant car %primitive-car)], but
a user environment should be provided in which the user can rebind car
[perhaps with a warning].  As environments are outside of the language
definition, *requiring* that the user environment have immutable names
violates both the spirit and the practice of the language.


>> * Make the semantics of internal and external definitions identical, and

I like the internal semantics and would like to change the name of the
special form used in interactive loops from "define" to something else (e.g.
"defun").  The top-level-environment is an artifact of an interactive
system.  We could make a naming distinction between uses/behaviors, rather
than changing uses because of a name alias.


>> * Extend the syntax of procedure definitions.

How is this going to affect other potential extensions [e.g. Dybvig & Heib's
variable-arity procedural interface]?  [I don't strongly oppose this].



{After all, how much is $.02 worth?}

-Ken		kend@mrloog.LA.TEK.COM

∂28-Jun-89  2147	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #148 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89  21:47:25 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17812;
          29 Jun 89 0:36 EDT
Date: 29 JUN 89  00:07:25 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #148 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8906290036.aa17812@mintaka.lcs.mit.edu>

Scheme Digest #148                             29 JUN 89  00:07:25 EDT

Today's Topics:

        Looking for R*RS and XScheme source by ftp

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

Date: 28 Jun 89 10:54:44 GMT
From: Oliver Laumann <mcvax!unido!tub!net@uunet.uu.net>
Subject: Re: Looking for R*RS and XScheme source by ftp
Message-Id: <867@tub.UUCP>

In article <8271@batcomputer.tn.cornell.edu> lacey@tcgould.tn.cornell.edu (John Lacey) writes:
> if anyone knows of another free Scheme implementation, I would like
> to hear about it.

I'm going to send the sources of a Scheme interpreter to comp.sources.unix
next week.  You can expect it to be posted by Rich Salz in about 4 weeks.

The interpreter is R↑3RS compatible, includes interfaces to the Xlib,
to Xt, and to the Athena and HP widget libraries of X11R3.  It was
written to be used as an general extension language interpreter (to be
linked into an application); it is also useful as a stand-alone
implementation of Scheme.

Regards,
--
Oliver Laumann              net@TUB.BITNET              net@tub.UUCP

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

End of Scheme Digest
********************

∂28-Jun-89  2257	@mc.lcs.mit.edu:shap@sid.stanford.edu 	A month of mail...   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 28 Jun 89  22:57:08 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28724;
          29 Jun 89 1:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 01:05:06 EDT
Received: from [36.22.0.120] by mintaka.lcs.mit.edu id aa16361;
          29 Jun 89 1:03 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA06777; Wed, 28 Jun 89 22:00:25 PDT
Message-Id: <8906290500.AA06777@mojave.Stanford.EDU>
Received: by sid; Wed, 28 Jun 89 22:03:02 pdt
Date: Wed, 28 Jun 89 22:03:02 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: kend@bloom.la.tek.com
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: kend@bloom.la.tek.com's message of Wed, 28 Jun 89 12:05:43 PDT <8906281905.AA11945@bloom.LA.TEK.COM>
Subject: A month of mail...

Ken's comment sort of blew past a point I think is interesting.  We
might be able to satisfy both desires - mutability and immutability -
by reserving some suitably small part of the namespace for system
primitives, e.g. identifiers with names whose leading substring is
"%primitive-"

Jon

∂29-Jun-89  0533	@mc.lcs.mit.edu,@mbunix.mitre.org:ramsdell@linus.mitre.org 	Make the semantics of internal and external definitions identical
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89  05:33:47 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20691;
          29 Jun 89 8:28 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 08:24:54 EDT
Received: from mbunix.mitre.org by mintaka.lcs.mit.edu id aa20553;
          29 Jun 89 8:19 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA01030; Thu, 29 Jun 89 08:16:41 EDT
Posted-Date: Thu, 29 Jun 89 08:16:35 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA01374; Thu, 29 Jun 89 08:16:35 EDT
Date: Thu, 29 Jun 89 08:16:35 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8906291216.AA01374@huxley.mitre.org>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 22 Jun 89 18:58:58 PDT <890622-185621-2108@Xerox>
Subject: Make the semantics of internal and external definitions identical
Reply-To: ramsdell@mitre.org


   From: Pavel.pa@xerox.com

   I'd like to request that the syntax and semantics of bodies and programs be
   identical, but not quite like either one in R3RS.  ....

I just would like to note this is a more radical proposal than my
original proposal, and I curtainly support it.

   This is the most uniform, consistent, and useful way I can see to resolve
   the difference in semantics between internal and external definitions.

This is a better technical proposal than mine.  However, if people
reject this idea, I hope they will still consider just changing the
semantics of internal definitions.

John

∂29-Jun-89  0956	@MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Responses to a month of mail  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89  09:56:23 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18138;
          29 Jun 89 12:51 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 29 Jun 89 12:48:29 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 230218; Thu 29-Jun-89 12:47:54 EDT
Date: Thu, 29 Jun 89 12:47 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Responses to a month of mail
To: jinx@ZURICH.ai.mit.edu, kend@bloom.la.tek.com
cc: Pavel.pa@xerox.com, rrrs-authors@MC.lcs.mit.edu
In-Reply-To: <8906281455.AA27360@ZURICH.AI.MIT.EDU>,
             <8906281905.AA11945@bloom.LA.TEK.COM>
Message-ID: <19890629164733.2.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Wed, 28 Jun 89 10:55:21 edt
    From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>

	* Change the rules for the formation of identifiers,

    I don't think this is warranted.  I think that lexical level
    conventions for module references are a bad idea.


    Date: Wed, 28 Jun 89 12:05:43 PDT
    From: kend@bloom.la.tek.com

    >> * Change the rules for the formation of identifiers,

    I also feel that strange naming conventions are not warrented for module
    experimentation.  Modules seen as compile-time early-binding, first-class
    environments [(*value module-1 'foo)], etc. do not require this.

I also think that using a special lexical syntax for module references is
probably a bad idea.  But I don't agree that we should prevent others from
experimentation.

The proposal, as I recall it (I don't have Pavel's original message
anymore), is -not- to declare that ":" is used for module references.  The
proposal is simply to remove ":" from the list of characters you can use in
a portable program.  This leaves implementations free to do whatever they
want with ":".  Some will experiment with using it for module references.
Others will treat it as an ordinary symbol constituent.  Some may signal
an error.  (Some may even use it to introduce a new kind of comment!)

No programmer would be forced to do anything except refrain from using ":"
in portable code.  You already can't use "[" portably, because there is
disagreement about what it means.  I could cause a lot of trouble by
insisting that we move "[" into the list of extended alphabetic characters,
but out of deference to people who have other opinions I am willing to
simply refrain from using "[".  This seems to me to be an acceptable
compromise -- I am not greatly inconvenienced by it and others are made
much happier.  

Of course I am aware that others may judge the tradeoff differently.
Indeed, if we always give in to people want to reserve characters for
special purposes, we will eventually have nothing left to name our symbols
with, so the line does have to be drawn somewhere.  But this colon issue
keeps coming up over and over -- it seems that we will never be free of the
pressure to demote ":" to reserved status -- so in this case I think we
should yield to that pressure.

∂29-Jun-89  1254	@mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com 	Re: A month of mail... 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89  12:54:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28183;
          29 Jun 89 15:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 15:38:36 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa08078;
          29 Jun 89 13:25 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa22273; 29 Jun 89 13:24 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
	id AA16418; Thu, 29 Jun 89 09:37:29 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA19249; Thu, 29 Jun 89 09:31:13 PDT
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
	id AA12503; Thu, 29 Jun 89 09:36:02 pdt
Message-Id: <8906291636.AA12503@bloom.LA.TEK.COM>
To: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
Subject: Re: A month of mail... 
In-Reply-To: Your message of Wed, 28 Jun 89 22:03:02 -0700.
             <8906290500.AA06777@mojave.Stanford.EDU> 
Date: Thu, 29 Jun 89 09:35:58 PDT
From: kend@bloom.la.tek.com



> Ken's comment sort of blew past a point I think is interesting.  We
> might be able to satisfy both desires - mutability and immutability -
> by reserving some suitably small part of the namespace for system
> primitives, e.g. identifiers with names whose leading substring is
> "%primitive-"
>
> Jon

Sorry to belabor the point, but...

If you use a *different* namespace for the implementation environment than
for the user environment, you do *not* have to make immutable any names in
the user environment.  If a user has a function to allow him access to the
implementation environment, he can be sure he is getting at a particular
primitive [barring syntactic transformations--see discussion in the
Syntactic Closures paper in the last L&FP Conf.].  By giving out an access
function without giving a mutation function, the implementation environment
is immutable *from the user's viewpoint* without doing anything special
[although you may want to do so for other reasons].

...All this without reserving any part of the user visable namespace.


-Ken		kend@mrloog.LA.TEK.COM

∂29-Jun-89  1434	@mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com 	Re: Responses to a month of mail 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89  14:34:23 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22909;
          29 Jun 89 17:30 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 17:27:00 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa22797;
          29 Jun 89 17:24 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa28749; 29 Jun 89 17:20 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
	id AA27434; Thu, 29 Jun 89 14:22:23 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA26610; Thu, 29 Jun 89 14:16:07 PDT
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
	id AA12833; Thu, 29 Jun 89 14:20:56 pdt
Message-Id: <8906292120.AA12833@bloom.LA.TEK.COM>
To: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Cc: jinx@ZURICH.ai.mit.edu, kend@bloom.la.tek.com, Pavel.pa@xerox.com, 
    rrrs-authors@mc.lcs.mit.edu
Subject: Re: Responses to a month of mail 
In-Reply-To: Your message of Thu, 29 Jun 89 12:47:00 -0400.
             <19890629164733.2.ALAN@PIGPEN.AI.MIT.EDU> 
Date: Thu, 29 Jun 89 14:20:52 PDT
From: kend@bloom.la.tek.com


>> From: Alan Bawden <Alan@reagan.ai.mit.edu>

> ... so the line does have to be drawn somewhere.  But this colon issue
> keeps coming up over and over -- it seems that we will never be free of the
> pressure to demote ":" to reserved status -- so in this case I think we
> should yield to that pressure.

I think that it is a bad idea to change the Scheme language when using an
alternate reader or syntax system which gives standard Scheme is a
fairly easy thing to do.  I see no restriction in experimentation.

The *problem* I see with making #\: reserved is in portability of the above
systems.  I may not have access to the implementation of Scheme which I am
using.  If I want to experiment with random-module-package and the
implementation of Scheme I am using treats #\: as a comment character, I
have to bash or rewrite the reader just to get the sources I want to try out
to lex properly.  If I can read symbols containing #\:, then I can
post-process the list structure which I can read using a standard reader.
I am in a much better position for experimentation if I can portably share
experiments without having to bash the implementation.  Making #\: reserved
works against this.


-Ken			kend@mrloog.AL.TEK.COM

(mod1:foo 3 x mod2:bar) --> ((*value mod1 'foo) 3 x (*value mod2 bar))

∂29-Jun-89  2112	@mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu 	A month of mail...  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89  21:11:51 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26611;
          29 Jun 89 23:57 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 23:35:04 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa26242;
          29 Jun 89 23:34 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA08964; Thu, 29 Jun 89 20:31:01 PDT
Message-Id: <8906300331.AA08964@mojave.Stanford.EDU>
Received: by sid; Thu, 29 Jun 89 20:33:39 pdt
Date: Thu, 29 Jun 89 20:33:39 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: kend@bloom.la.tek.com
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: A month of mail... 

   Date: Thu, 29 Jun 89 09:35:58 PDT
   From: kend@bloom.la.tek.com



   > Ken's comment sort of blew past a point I think is interesting.  We
   > might be able to satisfy both desires - mutability and immutability -
   > by reserving some suitably small part of the namespace for system
   > primitives, e.g. identifiers with names whose leading substring is
   > "%primitive-"
   >
   > Jon

   Sorry to belabor the point, but...

   If you use a *different* namespace for the implementation environment than
   for the user environment, you do *not* have to make immutable any names in
   the user environment.  If a user has a function to allow him access to the
   implementation environment, he can be sure he is getting at a particular
   primitive [barring syntactic transformations--see discussion in the
   Syntactic Closures paper in the last L&FP Conf.].  By giving out an access
   function without giving a mutation function, the implementation environment
   is immutable *from the user's viewpoint* without doing anything special
   [although you may want to do so for other reasons].

   ...All this without reserving any part of the user visable namespace.


   -Ken		kend@mrloog.LA.TEK.COM

This is all very true, unfortunately, my original message had a
thinko.  What I think would be useful is to have a set of standard
function names that are reserved and not mutable by the user.
Continuing the thinko, I should have said "%standard-" instead of
"%primitive-".

Why do I like this?

It is possible in the current scheme semantics to permanently lose all
of the user-visible bindings to a standard function.  While this is
from the perspective of non-fascism desirable, it also means that
low-level "system"-type code basically can't trust anything at all.
There are two reasons why we might want to think about introducing
immutable things like

	%standard-car
	%standard-cdr
	...

1. To be able to recover bindings to the standard functions
2. To be able to write low-level code that really does know what it is getting.

I observe as a side note that introducing environments would solve the
problem, but that idea seems to cause a lot of pain in these parts.
In the absence of such a mechanism, I am putting this forth as an
alternative to think about.

The fact that there is no way that my code can feel safe about its
standard environment is a serious weakness in scheme from the
standpoint of implementation.  I wouldn't want to give up the
mutability, but it would be awfully nice to be able to know what world
my code is living in.

As to mutability, you missed the issue of optimization, which is a
significant one in my view.

Ciao.

Jon

∂29-Jun-89  2129	@mc.lcs.mit.edu,@relay.cs.net,@mojave.stanford.edu:shap@sid.stanford.edu 	A month of mail...   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 29 Jun 89  21:29:49 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26830;
          30 Jun 89 0:05 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 29 Jun 89 23:40:16 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa26257;
          29 Jun 89 23:37 EDT
Received: from mojave.stanford.edu by RELAY.CS.NET id aa10029;
          29 Jun 89 23:36 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA08968; Thu, 29 Jun 89 20:32:48 PDT
Message-Id: <8906300332.AA08968@mojave.Stanford.EDU>
Received: by sid; Thu, 29 Jun 89 20:35:27 pdt
Date: Thu, 29 Jun 89 20:35:27 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: kend%bloom.la.tek.com@relay.cs.net
Cc: rrrs-authors%mc.lcs.mit.edu@relay.cs.net
In-Reply-To: kend%bloom.la.tek.com@relay.cs.net's message of Thu, 29 Jun 89 09:35:58 PDT <8906291636.AA12503@bloom.LA.TEK.COM>
Subject: A month of mail... 

HOLD THE FIRE!

I just reread Ken's note.  Yes, we need environments.

Jon

∂30-Jun-89  1052	@mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu 	Draft agenda for 3rd IEEE Scheme standard meeting
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jun 89  10:52:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04440;
          30 Jun 89 13:47 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 13:44:31 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa04385;
          30 Jun 89 13:43 EDT
Received: by iuvax.cs.indiana.edu 
Date: Fri, 30 Jun 89 12:43:32 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Draft agenda for 3rd IEEE Scheme standard meeting
Message-ID:  <8906301343.aa04385@mintaka.lcs.mit.edu>

A draft agenda follows for third meeting of the Scheme Working Group,
July 7th, 9:30am-5pm, Cambridge, MIT (room to be announced soon).
Suggestions for other agenda items are welcome.

1. Approve agenda.

2. Elect secretary.

3. Approve minutes of second meeting.
   
4. Discuss the numbers section of the standard draft.

5. Discuss proposals for differences between R4RS and the standard.

6. Discuss liaison with ISO WG-16.  The question is whether we want to
   formally submit a draft of our standard to the International
   Standards Organization Lisp Working Group so that they may consider
   the possibility of adopting our standard as an ISO standard.  If we
   decide to to submit, we must also draft an accompanying statement.

7. Establish time and place of next meeting.


∂30-Jun-89  1229	@mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Location for 3rd IEEE Scheme standard meeting
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jun 89  12:28:55 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05495;
          30 Jun 89 15:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 15:06:43 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa05271;
          30 Jun 89 15:01 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Fri, 30 Jun 89 14:58:26 edt
Date: Fri, 30 Jun 89 14:58:26 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8906301858.AA19407@ZURICH.AI.MIT.EDU>
To: scheme-standard@ZURICH.ai.mit.edu
Cc: rrrs-authors@ZURICH.ai.mit.edu
Subject: Location for 3rd IEEE Scheme standard meeting

The room for the meeting on July 7th will be MIT room 37-252.  
This room is called the Marlar Lounge, but few people know this, so
you should ask for 37-252 if lost.

Building 37's street address is 
70 Vassar st. in Cambridge.

∂30-Jun-89  1535	@mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@tekchips.labs.tek.com 	R↑3.95RS: open-input-file open-output-file 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jun 89  15:35:30 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07943;
          30 Jun 89 18:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jun 89 18:22:10 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa07857;
          30 Jun 89 18:18 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa11414; 30 Jun 89 18:18 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
	id AA17223; Fri, 30 Jun 89 15:19:54 PDT
Received: by tekirl.LABS.TEK.COM (5.51/7.0)
	id AA11465; Fri, 30 Jun 89 15:16:30 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
	id AA05379; Fri, 30 Jun 89 15:19:14 PDT
Message-Id: <8906302219.AA05379@tekchips.LABS.TEK.COM>
To: rrrs-authors@mc.lcs.mit.edu
Cc: kend@mrloog.la.tek.com
Subject: R↑3.95RS: open-input-file open-output-file 
Date: 30 Jun 89 15:19:12 PDT (Fri)
From: kend@tekchips.labs.tek.com


Both OPEN-INPUT-FILE and OPEN-OUTPUT-FILE are specified to `signal an
error' on failure.  I would either like these to return #f on failure
or have 2 similar functions with such a behavior.  The reason is for
programattic error recovery.  As we do not yet have a standard error
system, I don't have a portable way within a (non-interactive) program
to recover from failure to open a file.  On the other hand, it is
fairly easy for me to adapt to various error systems to signal an
error.

(define (OPEN-INPUT-FILE <filename>)
    (let ( (port (%primitive-open-input-file <filename>)) )
	(if port   ; #f on failure
	    port
	    (system-specific-error "Can't open file \"~A\" for input"
			  	   <filename>)
)   )   )

I can see the argument that returning #f or some such can be
interpreted as signalling an error, but I would prefer something I can
reliably use in a conditional and a behavior which is guarenteed not
terminate my [batch, system, etc] program.  Even "(not (input-port?
port))" is something I can test [although I would prefer #f].

Does anyone remember the rationale for this?


-Ken			kend@mrloog.LA.TEK.COM

∂30-Jun-89  2123	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #149 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 30 Jun 89  21:23:39 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00507;
          1 Jul 89 0:18 EDT
Date: 1 JUL 89  00:08:33 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #149 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907010018.aa00507@mintaka.lcs.mit.edu>

Scheme Digest #149                              1 JUL 89  00:08:33 EDT

Today's Topics:

        PC-Scheme
        Draft agenda for 3rd IEEE Scheme standard meeting
        Learning Scheme as a first language

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

Date:         Friday, 30 June 1989  08:55:44 TUR
From:         Oguz ALGAN <ETIFIZ02%TREARN.BITNET@mitvma.mit.edu>
Subject:      PC-Scheme
Message-ID:  <8906300940.aa01822@mintaka.lcs.mit.edu>

Hello,
I want to learn the current version of the Texas Instrument's PC-Scheme Lisp.
And Do you know how can obtain the PC-Scheme's REFERANCE MANUAL or a book
that tells me about PC-SCHEME's language features.
Thanks in advance.
Oguz ALGAN,
ETIFIZ02@TREARN

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

Date: Fri, 30 Jun 89 12:35:31 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Subject: Draft agenda for 3rd IEEE Scheme standard meeting
Message-ID:  <8906301335.aa04323@mintaka.lcs.mit.edu>

A draft agenda follows for third meeting of the Scheme Working Group,
July 7th, 9:30am-5pm, Cambridge, MIT (room to be announced soon).
Suggestions for other agenda items are welcome.

1. Approve agenda.

2. Elect secretary.

3. Approve minutes of second meeting.
   
4. Discuss the numbers section of the standard draft.

5. Discuss proposals for differences between R4RS and the standard.

6. Discuss liaison with ISO WG-16.  The question is whether we want to
   formally submit a draft of our standard to the International
   Standards Organization Lisp Working Group so that they may consider
   the possibility of adopting our standard as an ISO standard.  If we
   decide to to submit, we must also draft an accompanying statement.

7. Establish time and place of next meeting.

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

Date: 28 Jun 89 17:10:22 GMT
From: Dave McKellar <jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!intacc!mckellar@rutgers.edu>
Subject: Learning Scheme as a first language
Message-Id: <1989Jun28.131023.1031@intacc.uucp>


Does anyone know of an easy-reading book about scheme.
If there is one I hope to use it as a text for a course
teaching scheme as a first computer language.

Please e-mail any reply to me as I dont read the news
regularly.  I will post a summary if there is any
response.  Thanks alot.
-- 
----------
{uunet,watmath,utzoo}!mnetor!intacc!mckellar    "Taste is a matter of taste."
----------

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

End of Scheme Digest
********************

∂01-Jul-89  0447	@mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	R↑3.95RS: open-input-file open-output-file   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 1 Jul 89  04:47:14 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04689;
          1 Jul 89 7:41 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  1 Jul 89 07:38:38 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa04621;
          1 Jul 89 7:34 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Sat, 1 Jul 89 07:31:50 edt
Date: Sat, 1 Jul 89 07:31:50 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907011131.AA22190@ZURICH.AI.MIT.EDU>
To: kend@tekchips.labs.tek.com
Cc: rrrs-authors@mc.lcs.mit.edu, kend@mrloog.la.tek.com
In-Reply-To: kend@tekchips.labs.tek.com's message of 30 Jun 89 15:19:12 PDT (Fri) <8906302219.AA05379@tekchips.LABS.TEK.COM>
Subject: R↑3.95RS: open-input-file open-output-file 

   Date: 30 Jun 89 15:19:12 PDT (Fri)
   From: kend@tekchips.labs.tek.com


   Both OPEN-INPUT-FILE and OPEN-OUTPUT-FILE are specified to `signal an
   error' on failure.  I would either like these to return #f on failure
   or have 2 similar functions with such a behavior.  The reason is for
   programattic error recovery.  As we do not yet have a standard error
   system, I don't have a portable way within a (non-interactive) program
   to recover from failure to open a file.  On the other hand, it is
   fairly easy for me to adapt to various error systems to signal an
   error.

   (define (OPEN-INPUT-FILE <filename>)
       (let ( (port (%primitive-open-input-file <filename>)) )
	   (if port   ; #f on failure
	       port
	       (system-specific-error "Can't open file \"~A\" for input"
				      <filename>)
   )   )   )

   I can see the argument that returning #f or some such can be
   interpreted as signalling an error, but I would prefer something I can
   reliably use in a conditional and a behavior which is guarenteed not
   terminate my [batch, system, etc] program.  Even "(not (input-port?
   port))" is something I can test [although I would prefer #f].

   Does anyone remember the rationale for this?


   -Ken			kend@mrloog.LA.TEK.COM

I'd rather see new procedures which probe read/write accesibility of
files.  One of the things I detest about the C culture is the
convention that procedures return 0 (or -1 sometimes) when things
fail, and never generate errors.  Although a conscientious programmer
will write reasonable code given this convention, I think that it
strongly encouages carelessness and poor coding (errors propagate and
are not "detected" until much later, when the program "core dumps").
I would therefore oppose changing these procedures, or even
introducing virtually identical ones that return #f.

∂01-Jul-89  2126	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #150 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 1 Jul 89  21:26:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11262;
          2 Jul 89 0:17 EDT
Date: 2 JUL 89  00:08:30 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #150 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907020017.aa11262@mintaka.lcs.mit.edu>

Scheme Digest #150                              2 JUL 89  00:08:30 EDT

Today's Topics:

        Location for 3rd IEEE Scheme standard meeting

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

Date: Sat, 1 Jul 89 07:32:26 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907011132.AA22198@ZURICH.AI.MIT.EDU>
Subject: Location for 3rd IEEE Scheme standard meeting

The room for the meeting on July 7th will be MIT room 37-252.  
This room is called the Marlar Lounge, but few people know this, so
you should ask for 37-252 if lost.

Building 37's street address is 
70 Vassar st. in Cambridge.


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

End of Scheme Digest
********************

∂02-Jul-89  1434	@mc.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu 	R↑3.95RS: open-input-file open-output-file   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 2 Jul 89  14:33:57 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18131;
          2 Jul 89 17:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  2 Jul 89 17:23:57 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa18104;
          2 Jul 89 17:22 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA12753; Sun, 2 Jul 89 14:19:54 PDT
Message-Id: <8907022119.AA12753@mojave.Stanford.EDU>
Received: by sid; Sun, 2 Jul 89 14:22:27 pdt
Date: Sun, 2 Jul 89 14:22:27 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: jinx@ZURICH.ai.mit.edu
Cc: kend@tekchips.labs.tek.com, rrrs-authors@mc.lcs.mit.edu, 
    kend@mrloog.la.tek.com
In-Reply-To: "Guillermo J. Rozas"'s message of Sat, 1 Jul 89 07:31:50 edt <8907011131.AA22190@ZURICH.AI.MIT.EDU>
Subject: R↑3.95RS: open-input-file open-output-file 

I agree with jinx.  Having procedures return out-of-bound return
values to signal an error encourages all sorts of bad programming
habits, and has the further unfortunate property that it forces the
error detection/recovery code to be propagated to all of the calls if
I want to be well behaved.

In the absence of an error mechanism, though, it would be useful to
have an interim solution for people who need to write programs.
Writing a probing function doesn't get the job done - there is a race
condition between the time the file is probed and the time the open
happens.  Ultimately, what is needed is the ability to pass a recovery
continuation to the open procedure so that one has a chance to come
back on failure.

Unfortunately this opens several cans of worms:

	1. What should the error mechanism be [I like passing an error
	   continuation, but you may not.]
	2. How can we standardize the set of possible errors so that
	   the error continuation can do something useful?
	3. How do we decide which errors are recoverable.

I think that each of these issues takes considerable thought to get
right.

I would be interested to learn what mechanisms people have
experimented with and how well they work.

Jon

∂02-Jul-89  2200	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #151 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 2 Jul 89  22:00:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21144;
          3 Jul 89 0:46 EDT
Date: 3 JUL 89  00:09:16 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #151 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907030046.aa21144@mintaka.lcs.mit.edu>

Scheme Digest #151                              3 JUL 89  00:09:16 EDT

Today's Topics:

        OOP in Scheme

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

Date: 2 Jul 89 07:31:07 GMT
From: Brian of ASTD-CP <brian@jade.berkeley.edu>
Subject: OOP in Scheme
Message-Id: <1404@jato.Jpl.Nasa.Gov>

; methods2.scm
;
; ===============================================================
; Brian Beckman                  |    brian@topaz.jpl.nasa.gov
; Mail Stop 510-202              |    (818) 397-9207
; Jet Propulsion Laboratory      | 
; Pasadena, CA 91109             |    30 June 1989
; ===============================================================

; INTRODUCTION
;
; This is a tiny object-oriented programming system with multiple
; inheritance and error handling.  It is modeled after the message
; passing modules in Chapter 3 of Abelson & Sussman.  It is 
; implemented in ``pure'' Scheme, without macros or syntax
; extensions.
; 
; This programming system is implemented as a technique, or
; programming convention, with some helper routines.  The programming
; convention is not enforced, as we choose to avoid syntax-extensions
; for portability's sake.  The technique is illustrated in this file
; with a few examples.  In example one, a parent class, named
; ``parent,'' passes its attributes to a child named ``child.''  In
; example two, two parents, ``mother'' ``fater'', pass their attributes
; to a child class, ``daughter.''  The reader will perceive the technique
; by generalization from these examples and will be able to apply it
; to his or her own problems.
; 
; Every class is represented by its constructor procedure.  This
; procedure returns a message dispatching procedure.  The message
; dispatching procedure should be named ``self'' so that an object can
; conveniently send messages to itself.  However, ``self'' is an
; internal name not known outside the constructor.  
; 
; In summary, classes are represented by constructor procedures, and
; objects, or instances of classes, are represented by message
; dispatching procedures.  The present version of ``methods'' does not
; support code sharing, so every instance of a class has its own
; private copies of the method code.  We expect to implement code
; sharing in a later version of ``methods''.
; 
; The message dispatching procedure walks the multiple inheritance
; hierarchy upwards until it finds an object that can understand a
; message, starting with itself.  If no object that can understand the
; message is found, a global error procedure is called.
; 
; IMPLEMENTATION
;
; Error processing is challenging.  We should like to have two modes.
; In ``normal mode'', an error is reported only by the first receiver
; of a message.  In ``debug mode'', an inheritance traceback should be
; given whereby every object in an inheritance hierarchy will report
; when it fails to recognize a given message.  The following variable
; represents that mode.  (For simplicity, this object is hidden only
; by its name, which is unusual enough that it is unlikely to be
; trammeled by an application.  This is not the recommended technique
; for data hiding.  Data hiding ought to be implemented through the
; techniques shown in this file!  However, since this error handling
; part of the methods package is considered system programming,
; certain liberties in style are justifiable.  There are in fact, good
; technical reasons for the error handling code to be implemented with
; global variables, which the perceptive reader will be able to
; deduce.)

(define **method-mode** 'normal-method-mode)

; The user can set these modes as follows.

(define (set-debug-method-mode)
  (set! **method-mode** 'debug-method-mode))

(define (set-normal-method-mode)
  (set! **method-mode** 'normal-method-mode))

(define (reset-debug-method-mode)  ;;; synonym
  (set! **method-mode** 'normal-method-mode))

; and test them with the following routine:

(define (test-debug-method-mode)
  (eq? **method-mode** 'debug-method-mode))

; Before presenting the examples of classes and objects, some helper
; routines are needed.
;
; When an object cannot recognize a message, and none of its ancestor
; objects can recognize it, the object creates an error procedure and
; returns it as the result of the message dispatcher.  

(define **method-error-class-name** "No class name.")

(define **method-error-message** 'no-message)

(define (error-method . junk-args)
  (display **method-error-class-name**)
  (display ": uknown message: '")
  (display **method-error-message**)
  (newline)
  ())

(define (make-error-method class-name msg)
  (set! **method-error-class-name** class-name)
  (set! **method-error-message** msg)
  error-method)

; The procedure that walks the inheritance hierarchy must cooperate
; in the error handling.  

(define (search-supertypes supers msg)
  (define method ())
  (if (test-debug-method-mode)
      (begin
       (display "Searching...")
       (newline)))
  (cond
   (  (null? supers)  ()  )
   (  (begin
       (set! method ((car supers) msg))
       (eq? method error-method))
                      (if (test-debug-method-mode)
                          (error-method))
                      (search-supertypes (cdr supers) msg)  )
   (  else  method  )))

; This procedure implements the inheritance of methods.  It is greatly
; complicated by proper error handling.  Without error handling, the
; routine would resemble the following, which is much easier to
; understand (without error handling, the programming convention is
; that an object that does not understand a message returns the
; unexecutable method ``()'').
;
; (define (search-supertypes supers msg)
;   (cond
;     (  (null? supers)  ()  )
;     (  ((car supers) msg)  )
;     (  else  (search-supertypes (cdr supers) msg)  )))
;
; The actual routine, with proper error handling, works as follows.  A
; local variable, ``method'', is defined.  Its value is not important
; to begin with.  If debugging is on, we print a message telling the
; user that the inheritance hierarchy is being searched.  Then, the
; list of supertypes is investigated.  If the list is empty, we return
; nil, which signals the caller to create and return the error-method,
; as we shall see in the examples later.  If the list is not empty, we
; pass the message to the first supertype in the list.  The return
; value is assigned to the local variable ``method''.  If the returned
; method is the one and only global error-method, then the supertype,
; and, recursively, all its supertypes, did not know the message.  
; If debugging is on, we execute the returned error-method, contributing
; to the aforementioned inheritance traceback.  Finally, we return 
; the value of a recursive call of search-supertypes on the remainder 
; of the list of supertypes.  If the returned method is not the 
; error-method, then the supertype did understand the message after 
; all somewhere in the hierarchy, and the returned method is the
; return value of this procedure.
;
; Note that the list of supertypes is searched in order from front
; to back.  The first match of a message results in the successful
; finding of a method.  The order of supertypes in the list is 
; significant only when more than one supertype can understand
; a given message.  The earlier members of the list will shadow
; the later ones.  In some object-oriented programming systems, one
; refers to the ``overriding'' of methods.  The shadowing in 
; ``methods'' is our form of method overriding, and it is under
; explicit control of the programmer who sets the order of supertypes
; in the list of supertypes.  
; 
; In summary, search-supertypes passes the message to the ancestors,
; in pre-order, returning the first method found.  
;
; The next helper routine passes a message, and a variable number of
; arguments, to all the parents of an object.  For side effects, it
; executes any methods found.  Parents are defined as 
; first level ancestors.

(define (for-all-parents supers msg . args)
  (let (  (method-list
           (map (lambda (supertype) (supertype msg)) supers))
          (for-proc
           (lambda (method) (apply method args)))  )
    (for-each for-proc method-list)))

; With the current programming convention, it is not possible to pass
; a message to all ancestors and execute the methods for side-effect
; without explicit cooperation on the part of the objects involved. In
; other words, the procedure ``for-all-ancestors'', analogous to
; ``for-all-parents'', cannot be implemented in the current version of
; the methods package.  The reason is that the convention calls for
; every class to call ``search-supertypes'', which stops when it finds
; a method.  The convention would have to be augmented so that objects
; would call ``find-all-methods'' (defined below) on an appropriate
; message.  Since we expect the need for ``for-all-ancestors'' to be
; fairly rare, the necessary changes to the methods package will be
; reserved for a future version.

(define (find-all-methods supers msg)
  (cond
   (  (null? supers)  ()  )
   (  else  (cons ((car supers) msg)
                  (find-all-methods (cdr supers) msg))  )))

; EXAMPLES (cut here to end of file to throw examples away)
;
; Our first example class, or object type, is ``parent'', represented
; by the following constructor procedure.

(define (new-parent arg)
  (let ((state-var (* arg arg))
        (supers ()))
    
    (define (report-state-var)
      (display state-var)
      (newline)
      state-var)
    
    (define (update-state-var arg)
      (set! state-var (* arg arg)))
    
    (define (echo arg)
      (display arg) (newline))
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)  report-state-var  )
       (  (eq? msg 'update)  update-state-var  )
       (  (eq? msg 'echo)    echo  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Parent" msg)  )))
    
    self))

; This class, or constructor procedure, completely illustrates, by
; example, the programming convention of the ``methods'' technique.  
; The constructor takes a single argument, whose square it stores in a
; local state variable.  Another state variable, the list of
; supertypes, is set to nil, since this class is at the root of an
; inheritance hierarchy.  Three methods are defined, one that reports
; and returns the current value of the state variable, one that sets
; the state variable equal to a new square, and one that merely echoes
; its argument.  A method dispatching procedure, conventionally named
; ``self'', tests a given message against three symbols and returns
; the corresponding method if a match is found.  If no match is found,
; the list of supertypes is searched for a match.  In the case of this
; class, ``parent'', the search is purely formal, to illustrate how it
; should be done, since ``parent'' has no ancestors.  However, if a
; match were found among the list of supertypes, the method would be
; returned.  Note how the search relys on the fact that any non-nil
; result is treated as a successful ``cond'' clause, terminating the
; ``cond'' statement. Search-supertypes returns nil only when a match
; is not found.  Finally, if no match is found locally or among the
; supertypes, an appropriate error-method is pseudo-created and
; returned.
; 
; We now test this class by making an instance and passing it
; messages.

(define p (new-parent 42))

((p 'report))

((p 'update) 69)

((p 'report))

((p 'echo) (list 1 2 3))

; We test error handling:

((p 'bogus))

(set-debug-method-mode)

((p 'bogus))

(reset-debug-method-mode)

((p 'bogus) 'here 'are 'some 'junk 'arguments)

; Continuing this example, let us define a child class inheriting
; all attributes and methods of the parent.  Note the attributes of
; the parent are only accessible through the parent's method
; discipline.  This is a strict form of inheritance, and the default
; in C++, for example.  (C++ allows the programmer to override 
; ancestors' access discipline, at his own peril.)

(define (new-child arg1 arg2)
  
  (let* (  (leg1 (* arg1 arg1))
           (leg2 (* arg2 arg2))
           (hypotenuse (+ leg1 leg2))
           (supers (list
                    (new-parent hypotenuse)))  )
    
    (define (report)
      (for-all-parents supers 'report)
      (display "Leg1 = ") (display (sqrt leg1)) (newline)
      (display "Leg2 = ") (display (sqrt leg2)) (newline)
      (display "Hypo = ") (display (sqrt hypotenuse)) (newline))
    
    (define (update-leg1 val)
      (set! leg1 (* val val))
      (set! hypotenuse (+ leg1 leg2)))
    
    (define (update-leg2 val)
      (set! leg2 (* val val))
      (set! hypotenuse (+ leg1 leg2)))
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)       report       )
       (  (eq? msg 'update-leg1)  update-leg1  )
       (  (eq? msg 'update-leg2)  update-leg2  )
       (  (search-supertypes supers msg)       )
       (  else  (make-error-method "Child" msg)       )))
    
    self))

; We now test the child type.

(define c (new-child 3 4))

((c 'report))  ;;; passes message to all parents

((c 'update-leg1) 5)

((c 'update-leg2) 12)

((c 'report))

((c 'echo) '(foo bar))   ;;; msg known only in the parent

((c 'bogus) 'baz 'rat)

(set-debug-method-mode)

((c 'bogus) 'baz 'rat)

(reset-debug-method-mode)

((c 'bogus) 'baz 'rat)

; The last example, presented without detailed narrative, shows a 
; slightly deeper inheritance hierarchy.  The leaf is a type named
; ``daughter''.  Its two parent classes are ``mother'' and ``father''.  
; In turn, every mother has an ``estate'' and a ``religion'' (please
; excuse the somewhat strained metaphor of inheritance; this is just
; a little example).  

(define (new-estate value)
  (let ((value value)
        (supers ()))
    
    (define (report)
      (display "Estate = $") (display value) (newline))
    
    (define (what-value) value)
    
    (define (increase amount) (set! value (+ value amount)))
    
    (define (decrease amount) (set! value (- value amount)))
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)       report  )
       (  (eq? msg 'what-estate)  what-value  )
       (  (eq? msg 'increase)     increase  )
       (  (eq? msg 'decrease)     decrease  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Estate" msg)  )))
    
    self))

(define (new-religion theReligion)
  (let ((religion theReligion)
        (supers ()))
    
    (define (report) (display "Religion = ") (display religion) (newline))
    
    (define (what-religion) religion)
    
    (define (convert theNewReligion) (set! religion theNewReligion))
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)         report  )
       (  (eq? msg 'convert)        convert  )
       (  (eq? msg 'what-religion)  what-religion  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Religion" msg)  )))
    
    self))

(define (new-father eye-color)
  (let ((eye-color eye-color)
        (supers ()))
    
    (define (report) (display "Father's eye color = ")
      (display eye-color) (newline))
    
    (define (what-eye-color) eye-color)
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)          report  )
       (  (eq? msg 'what-eye-color)  what-eye-color  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Father" msg)  )))
    
    self))

(define (new-mother eye-color estate religion)
  (let ((eye-color eye-color)
        (supers (list
                 (new-estate estate)
                 (new-religion religion))))
    
    (define (report)
      (for-all-parents supers 'report)
      (display "Mother's eye color = ")
      (display eye-color) (newline))
    
    (define (what-eye-color) eye-color)
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)          report  )
       (  (eq? msg 'what-eye-color)  what-eye-color  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Mother" msg)  )))
    
    self))

(define (new-daughter eye-color)
  (let* ((eye-color eye-color)
         (parents-eye-color
          (if (eq? eye-color 'blue)  'blue  'brown))
         (supers (list
                  (new-father parents-eye-color)
                  (new-mother parents-eye-color 500000 'Jewish))))
    
    (define (report)
      (for-all-parents supers 'report)
      (display "Daughter's eye color = ")
      (display eye-color)
      (newline))
    
    (define (what-eye-color) eye-color)
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)          report  )
       (  (eq? msg 'what-eye-color)  what-eye-color  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Daughter" msg)  )))
    
    self))

(define dbl (new-daughter 'blue))

((dbl 'report))

((dbl 'convert) 'muslim)

((dbl 'report))

((dbl 'increase) 50000)

((dbl 'report))

(define dbr (new-daughter 'brown))

((dbr 'report))

((dbr 'decrease) 250000)

((dbr 'report))

((dbr 'bogus))

(set-debug-method-mode)

((dbr 'bogus))

(reset-debug-method-mode)

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

End of Scheme Digest
********************

∂03-Jul-89  2219	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #152 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 3 Jul 89  22:19:37 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03991;
          4 Jul 89 1:09 EDT
Date: 4 JUL 89  00:09:20 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #152 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907040109.aa03991@mintaka.lcs.mit.edu>

Scheme Digest #152                              4 JUL 89  00:09:20 EDT

Today's Topics:

        OOP in Scheme (addendum)
        AI NEWS FROM IEEE COMPUTER SOCIETY
        Calculuses (sp?) for Scheme, and R*RS (again)

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

Date: 3 Jul 89 08:16:05 GMT
From: Brian of ASTD-CP <brian@jade.berkeley.edu>
Subject: OOP in Scheme (addendum)
Message-Id: <1406@jato.Jpl.Nasa.Gov>

; methods.scm  (ADDENDUM)
;
; ===============================================================
; Brian Beckman                  |    brian@topaz.jpl.nasa.gov
; Mail Stop 510-202              |    (818) 397-9207
; Jet Propulsion Laboratory      | 
; Pasadena, CA 91109             |    30 June 1989
; ===============================================================

; There are two ways to invoke a method in an object.  The
; first is to send the object a message, getting back a procedure.
; This procedure can then be invoked at will on an appropriate
; set of arguments.  Such an idiom usually results in expressions
; like the following:
;
;   ((foo 'do-it) arg1 arg2)
;
; This is fairly readable and a fine idiom, but it has its 
; limitations.  Suppose that this expression were to result in
; another object, to which we should like to send the message
; 'baz with the arguments 'rat and 'ter.  Then we should write
; the following:
;
;   ((((foo 'do-it) arg1 arg2) 'baz) 'rat 'ter)
;
; The number of leading parentheses is a problem.  It is easy 
; to devise nested message passing expressions that are
; much more difficult to write than to devise, merely because of
; the number of leading parentheses that must be presaged.  Lisp 
; already has a problem with closing parentheses; we don't want
; to compound the felony in this package by introducing a 
; corresponding problem with opening parentheses.  
;
; We need a ``send'' routine that does little more than reduce
; the need for leading parenthese.  This is, admittedly, merely 
; a syntactic issue.  Consider the following, which is the second
; way to send a message to an object:

(define (send object msg . args)
  (apply (object msg) args))

; The earlier example message passing expressions can now be
; much more easly written much more nicely, as follows:
;
;    (send object 'msg arg1 arg2)
;
; and
;
;    (send (send object 'msg arg1 arg2) 'baz 'rat 'ter)

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

Date:    Mon, 03 Jul 89 07:49 EDT
From:    DYU%NCCIBM1.BITNET@mitvma.mit.edu
Subject: AI NEWS FROM IEEE COMPUTER SOCIETY
Message-ID:  <8907030752.aa24699@mintaka.lcs.mit.edu>

WHAT IS THE TASK FORCE ON EXPERT SYSTEMS?

         The IEEE Computer Society announces the formation of a
Task Force on Expert Systems Applications.  The purpose of the
Task Force is to support interest in the development and use of
expert systems applications.  The IEEE Computer Society, which
has over 100,000 members worldwide, authorized the creation of
the Task Force at a meeting of its Technical Activities Board
(TAB) held March 2nd in San Francisco, CA.

         The objectives of the Task Force are to improve the
abilities of organizations and individuals to work with expert
systems technologies.  The Task Force will sponsor activities at
the national and international levels, but also support local
events.  The Task Force will publish a newsletter, exchange
electronic mail, provide speakers for conferences, organize
tutorials, symposiums, and convene meetings on standards either
on its own initiative or jointly with other IEEE Computer Society
functions.

         The Importance of Expert Systems

         MIS and end users are experiencing an explosion of
interest and activity in expert systems applications in almost
all sectors of business, government, and education.  This is
taking place due to the wide distribution of expert system shells
on personal computers and workstations.  It is a remarkable
change in the field of artificial intelligence in which
developers usually rely on specialized computer platforms and
programming languages.

         Expert systems are the most mature and resilient products
to emerge from the AI community, and they are being adopted by
corporations and government departments to improve productivity.
They are doing this because the applications of expert systems to
specific knowledge intensive systems return high yields.  Success
stories for expert systems are more common now than two years
ago.  A current estimate is there are 2,000 operational expert
systems and 80% of them on running on personal computers.

         The Value of the Task Force

         The greatest value which will be derived from
participating in the Task Force will come from regular
discussions among Task Force participants.  In some ways, this
will resemble the informal interactions of a user group.  In
other ways it will compliment many of the professional activities
of the IEEE Computer Society.

       Within these broad themes, there are many diverse
interests, including business activities such as banking and
finance, manufacturing and service functions, medical practice,
government functions, including the military, and education.
These interests will be addressed through locally sponsored and
nationally significant activities including conferences,
workshops, lectures, a newsletter, and other appropriate
mechanisms.

         Membership

         All meetings of the Task Force are be open to the public
and will be announced ahead of time in the news media.  Anyone
who has an interest in the objectives of the Task Force is
invited to attend its functions and participate in its
activities.  Membership in the IEEE Computer Society is not
required to attend our meetings.  Since the Task Force is
oriented toward development and use of expert systems
applications, we expect and encourage the interest of vendors of
computer hardware, software, and services.  Future activities of
the Task Force will be developed consistent with the goals and
objectives of the IEEE Computer Society.

         For additional information, call Dan Yurman, Chairman, at
202-475-6754 9-5 EST. MCI Mail: 364-1277

Mailing address:
-----------------------------
Task Force on Expert Systems
c/o TAB Coordinator
IEEE Computer Society
1730 Massachusetts Ave., NW
Washington, DC 20036.

                             IEEE Computer Society
                         Task Force on Expert Systems

                            Roles & Responsibilities

         Chair: This role is responsible for leadership and
technical direction of the Task Force.  The Chair maintains the
vitality of the group by coordinating activities such as
speakers, seminars, conferences, workshops, tutorials, workgroups
on standards, and communications with members including
newsletters and electronic mail.  The Chair appoints the other
leadership figures of the Task Force.

Dan Yurman, Chairman

                   Information Management Staff
                   Office of Solid Waste & Emergency Response
                   U.S. Environmental Protection Agency
                   401 M St., SW; (OS-110)
                   Washington, DC 20460         202-475-6754

        Vice-Chairs: The Chair appoints Vice-Chairs for the
purpose of carrying out functions of the Task Force.  All Vice
Chairs receive logistical support from the IEEE Computer
Society's administration office which is located in Washington,
DC.  Vice-Chairs are responsible for recruiting volunteers to
carry out their responsibilities.  Vice-Chairs are delegated the
authority to appoint such committee chairs as may be needed, e.g.
newsletter editor, workshop convener, etc.

         Communications: Responsible for all communications with
members, the public, and other professional societies.  Develops
and publishes a newsletter, establishes electronic mail exchange,
and sustains publicity for Task Force Events.  Keeps a record of
all meetings.  Serves as a point of contact with IEEE Expert
magazine and IEEE Computer magazine.

Sandra Hoffman, Vice Chair for Communications

                   Systems Analyst
                   Congressional Budget Office
                   2nd & D, SW; Room 450
                   Washington, DC 20515         202-226-2886

         Meetings: Responsible for developing a program of
meetings featuring speakers on topics of interest to the
membership.  Works with other Vice- Chairs to handle local
arrangements.  Establishes working groups for tutorials and
seminars on significant topics.

Randy Manner, Vice Chair for Meetings

                   Manager - Expert Systems Group
                   American Management Systems
                   1777 N. Kent St.
                   Arlington, VA 22209          703-841-6849

         Conferences: This Vice-Chair has a liaison role for the
IEEE Computer Society "Expert Systems in Government" Conference,
and for other IEEE Computer Society conferences which emphasize
applications of artificial intelligence and expert systems.
Also, this Vice Chair is responsible for coordinating the working
relationship of the Task Force with conferences on expert systems
sponsored by other professional societies.

Jerry Feinstein, Vice Chair for Conferences

                   Vice President
                   Phase-Linear Systems/ICF
                   9300 Lee Highway
                   Fairfax, VA 22031            703-934-3280

         Standards: Develops working groups composed of users,
industry, and academia to address issues related to hardware or
software standards for expert systems applications.

Captain Dave Howell, Vice Chair for Standards

                   Artificial Intelligence
                   Program Management Office
                   U.S. Air Force Logistics Command
                   HQ AFLC/MM-AI
                   Wright Patterson AFB,
                   Ohio 45433                   513-257-2571

         Industry Relations: Establishes and maintains
communications with hardware and software vendors, developers,
and other commercial as well as not-for-profit providers of
expert systems applications.  Provides for demonstration or
poster sessions on the latest technological developments.

Joseph Schmuller, Vice Chair for Industry Relations

                   Senior Knowledge Engineer
                   CDM Federal Programs Corp.
                   13135 Lee Jackson Highway
                   Fairfax, VA 22033            703-968-0900

         Treasurer: Responsible for keeping track of Task Force
finances, for fund raising including setting up a means to cover
costs, and solicitations of "in kind" contributions.

Vacant

         Membership: Responsible for developing and implementing
a membership recruitment campaign for the Task Force working at
the national level.  Works with other Vice-Chairs to carry out
these functions.  Establishes and maintains liaison with IEEE
Computer Society Chapters and Area Activities Boards as well as
other Task Forces and Technical Committees.

Vacant

Task Force on Expert Systems
c/o TAB Coordinator
IEEE Computer Society
1730 Massachusetts Ave. NW
Washington, DC 20036
---------------------------
                Membership Mailing List and Activity Preference
                   NOTE: If you can't wait for the mail,
                   call a Vice Chair and volunteer today!

Please complete this form and return it to:

         Dan Yurman, Chair
         Task Force on Expert Systems
         c/o US EPA (OS-110)
         401 M St., SW
         Washington, DC 20460

         Ph: 202-475-6754

         Please provide any suggestions or comments in the margins of the
paper.  Thank you.

Name:________________________________________________________

Title:_______________________________________________________

Organization:________________________________________________

Address:_____________________________________________________

_____________________________________________________________

City:________________________________________________________

State: ______  ZIP:__________

Daytime Phone: ______ ______  ____________

Electronic mail:_____________________________________________

         Please indicate the activities you would like to
volunteer your time and talents.  You will be contacted soon.
You do not have to be a member of the IEEE Computer Society to
participate in the activities of the Task Force on Expert
Systems.  At this time there is no charge to be placed on our
mailing list.  Within the next six months there may be a nominal
dues charge to continue to receive these materials.

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

Date: 3 Jul 89 17:21:18 GMT
From: John Lacey <lacey@tcgould.tn.cornell.edu>
Subject: Calculuses (sp?) for Scheme, and R*RS (again)
Message-Id: <8313@batcomputer.tn.cornell.edu>

Does anyone have references to calculus bases for Scheme (such as
the lambda calculus, and the one by Matthias Felleisen)?  That is,
references that deal with these directly in terms of Scheme (of
course those for the latter will, as it was designed for Scheme).

Also, I am *still* looking for the text of the Revised * Report on 
Scheme.  Where can I find it?  Is there an E-mailable copy someplace?

Sorry about posting these types of questions, but the libraries here
are staffed with completely inadequate electronic searching systems,
and summer help. 


-- 
John Lacey           |  Internet:  lacey@tcgould.tn.cornell.edu
running unattached   |  BITnet:    lacey@crnlthry
                     |  UUCP:      cornell!batcomputer!lacey
"Whereof one cannot speak, thereof one must remain silent."  ---Wittgenstein

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

End of Scheme Digest
********************

∂04-Jul-89  1707	@mc.lcs.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com 	R↑3.95RS: open-input-file open-output-file 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 4 Jul 89  17:07:37 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11960;
          4 Jul 89 20:06 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  4 Jul 89 20:03:43 EDT
Received: from RELAY.CS.NET by mintaka.lcs.mit.edu id aa11937;
          4 Jul 89 20:02 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa06940; 4 Jul 89 20:02 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
	id AA29240; Tue, 4 Jul 89 17:04:33 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA14612; Tue, 4 Jul 89 16:58:16 PDT
Received: from localhost.ARPA by bloom.LA.TEK.COM (1.2/6.24)
	id AA16574; Tue, 4 Jul 89 17:03:03 pdt
Message-Id: <8907050003.AA16574@bloom.LA.TEK.COM>
To: jinx@ZURICH.ai.mit.edu, shap@sid.stanford.edu
Cc: rrrs-authors@mc.lcs.mit.edu
Subject: R↑3.95RS: open-input-file open-output-file
Date: Tue, 04 Jul 89 17:02:59 PDT
From: kend@bloom.la.tek.com

>> from Ken Dickey
>   Both OPEN-INPUT-FILE and OPEN-OUTPUT-FILE are specified to `signal an
>   error' on failure.  I would either like these to return #f on failure
>   or...

>> from JINX
> I'd rather see new procedures which probe read/write accesibility of
> files.  One of the things I detest about the C culture is the
> convention that procedures return 0 (or -1 sometimes) when things
> fail, and never generate errors.  Although a conscientious programmer
> will write reasonable code given this convention, I think that it
> strongly encouages carelessness and poor coding (errors propagate and
> are not "detected" until much later, when the program "core dumps").
> I would therefore oppose changing these procedures, or even
> introducing virtually identical ones that return #f.

I would very much like to see an error handling mechanism specified in
R↑5RS.  In the interrum, is the Scheme community going to have a standard in
which a non-interactive program dumps core because of a failed file open?
Although legal behavior, I find this most distressing.  


-Ken			kend@mrloog.LA.TEK.COM

∂05-Jul-89  1411	@mc.lcs.mit.edu,@decwrl.pa.dec.com:jmiller@crl.dec.com 	Responses to a month of mail 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89  14:11:29 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22410;
          5 Jul 89 17:10 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  5 Jul 89 17:01:34 EDT
Received: from decwrl.pa.dec.com by mintaka.lcs.mit.edu id aa22221;
          5 Jul 89 16:55 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	id AA03471; Wed, 5 Jul 89 13:55:01 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	for rrrs-authors@mc.lcs.mit.edu; id AA03471; Wed, 5 Jul 89 13:55:01 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
	id AA05480; Wed, 5 Jul 89 16:56:21 EDT
Date: Wed, 5 Jul 89 16:53:13 EDT
From: jmiller@crl.dec.com
Message-Id: <8907052053.AA00249@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden  29-Jun-89 1247 EDT's message of Thu, 29 Jun 89 12:59:40 EDT <8906291659.AA01277@crl.crl.dec.com>
Subject: Responses to a month of mail
Reply-To: JMiller%crl.dec@decwrl.pa.dec.com

I'd like to suggest that Pavel use "|" instead of ":" for his module
separator.  It's currently illegal, and I believe that his argument
against its use (other dialects use it for an escape character) is
very weak.  It also looks pretty good for just this purpose:

(module|submodule|procedure random-thing)

--Jim

∂05-Jul-89  1452	@mc.lcs.mit.edu,@decwrl.pa.dec.com:jmiller@crl.dec.com 	R↑3.95RS: open-input-file open-output-file  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89  14:52:43 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22838;
          5 Jul 89 17:40 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  5 Jul 89 17:12:00 EDT
Received: from decwrl.pa.dec.com by mintaka.lcs.mit.edu id aa22391;
          5 Jul 89 17:09 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	id AA05041; Wed, 5 Jul 89 14:08:52 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	for rrrs-authors@mc.lcs.mit.edu; id AA05041; Wed, 5 Jul 89 14:08:52 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
	id AA05509; Wed, 5 Jul 89 17:10:29 EDT
Date: Wed, 5 Jul 89 17:07:22 EDT
From: jmiller@crl.dec.com
Message-Id: <8907052107.AA00259@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Jonathan S. Shapiro  2-Jul-89 1422 PDT's message of Sun, 2 Jul 89 17:36:32 EDT <8907022136.AA03775@crl.crl.dec.com>
Subject: R↑3.95RS: open-input-file open-output-file
Reply-To: JMiller@crl.enet.dec.com

At the risk of opening an entire can of worms, what about passing an
optional flag in to OPEN-... specifying (if present and EQ? to #T)
that a return value of #F is valid.  Thus "ordinary" programming would
omit the flag and generate errors; users like Ken (?) would have the
control they would like.

--Jim


∂05-Jul-89  1835	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Re: R↑3.95RS: open-input-file open-output-file   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89  18:35:52 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25164;
          5 Jul 89 21:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  5 Jul 89 20:58:50 EDT
Received: from [13.0.12.232] by mintaka.lcs.mit.edu id aa24767;
          5 Jul 89 20:54 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 17:53:42 PDT
Date: Wed, 05 Jul 89 17:53:24 PDT
From: Pavel.pa@xerox.com
Subject: Re: R↑3.95RS: open-input-file open-output-file
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-175342-7490@Xerox>

I share the distaste of some others for returning special values to signal
errors or other exceptional conditions.  I would, also as others have
stated, prefer that we agree on enough of a condition facility that such
errors can be handled that way.  I have designed (if that's the right word
for something so simple) a condition facility that I believe contains
little enough policy that we might all agree on it in time for R4RS.
Unsurprisingly, however, it depends upon the existence of a mechanism for
fluid binding, so I will hold off on proposing the condition facility until
after we agree on fluid binding.  I think that we can probably come to an
easy agreement on that issue at this point, so I will send out a proposal
either today or tomorrow to get the ball rolling.

	Pavel

∂05-Jul-89  1856	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Curried definition syntax    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89  18:56:37 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25478;
          5 Jul 89 21:53 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  5 Jul 89 21:49:38 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa25369; 5 Jul 89 21:43 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 18:12:04 PDT
Date: Wed, 05 Jul 89 18:11:57 PDT
From: Pavel.pa@xerox.com
Subject: Curried definition syntax
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-181204-7527@Xerox>

I received only two responses to my proposal that we reinstate the
``curried'' syntax for definitions, dropped in the interval between RRRS
and R3RS.  Both mentioned other possible extensions (type predicates on
arguments and variable-arity procedures) that might formally or
aesthetically clash with the additional syntax.  Thus, at least until such
time as the fates of those possible extensions in the language are settled,
I'm willing to withdraw my proposal.

	Pavel

∂05-Jul-89  1919	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Uniform definition semantics 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89  19:19:29 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25656;
          5 Jul 89 22:06 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  5 Jul 89 21:49:47 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa25395; 5 Jul 89 21:46 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 18:44:39 PDT
Date: Wed, 05 Jul 89 18:44:30 PDT
From: Pavel.pa@xerox.com
Subject: Uniform definition semantics
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-184439-7576@Xerox>

I proposed that the syntax and semantics of programs and ``bodies'' be
identical, with the following syntax and the more-or-less obvious
semantics.

	<program> ::= { <expression> | <definition> | (begin <program>) }*

John Ramsdell supported this proposal while holding out his own more
conservative one as a possible fallback position.

Jinx agreed that internal and external definitions should have the same
semantics, but would rather that we instead adopt the current LETREC-style
semantics of internal definitions.  He points out that this is ``too
radical to be accepted by most people'' and prefers the status quo to my
proposal (and presumably to John's as well).

I don't know that it is the ``radical'' nature of Jinx's preference that
keeps me from supporting it.  Rather, it is the combination of great
incompatibility (I would bet that the vast majority of non-trivial existing
Scheme programs would become illegal) and great inconvenience.  For
example, I frequently define a set of procedures for manipulating values of
some type and then immediately define another variable, initializing it via
a call on one or more of those procedures.  Under Jinx's semantics, that
code would cease to be correct and would have to be rewritten, first
defining the variable to have some nonsense value and then assigning the
proper value to it in a separate expression.  This is obfuscatory and
useless.

As to the status quo, I cannot agree that two conflicting semantics are
better than a single compatible, useful, and intuitive one.

The only other response came from Ken Dickey (I think that's his last
name), who said the following:

    I like the internal semantics and would like to change the name of the
    special form used in interactive loops from "define" to something else
(e.g.
    "defun").  The top-level-environment is an artifact of an interactive
    system.  We could make a naming distinction between uses/behaviors,
rather
    than changing uses because of a name alias.

See above for my comments on the internal semantics.

I do not agree that the top-level environment has anything to do with the
interactive nature of some Scheme implementations.  It has more to do with
a notion of a global namespace, shared among many distinct program
fragments (often stored in files).  As such, definitions are simply
another, sometimes more convenient, syntax for the establishment of a
lexical contour, completely unrelated to interactivity.  Thus, I see no
difference in the uses of internal and external definitions and therefore
wish they had the same behavior.

I am surprised that there have been no other comments; is one to assume
that the remainder of the list has no opinion on the subject?

	Pavel

∂05-Jul-89  1941	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Reserving a character for experimentation   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89  19:41:43 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25830;
          5 Jul 89 22:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  5 Jul 89 22:05:43 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa25624; 5 Jul 89 22:04 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 19:04:11 PDT
Date: Wed, 05 Jul 89 19:04:03 PDT
From: Pavel.pa@xerox.com
Subject: Reserving a character for experimentation
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-190411-7603@Xerox>

I think that Alan Bawden stated my position (and, in particular, my
reaction to some of the other comments on my proposal) quite completely and
adequately, so I'll answer only the comments since his note.

Ken Dickey (?) says:

   The *problem* I see with making #\: reserved is in portability of the
above
   systems.  I may not have access to the implementation of Scheme which I
am
   using.  If I want to experiment with random-module-package and the
   implementation of Scheme I am using treats #\: as a comment character, I
   have to bash or rewrite the reader just to get the sources I want to try
out
   to lex properly.  If I can read symbols containing #\:, then I can
   post-process the list structure which I can read using a standard
reader.
   I am in a much better position for experimentation if I can portably
share
   experiments without having to bash the implementation.  Making #\:
reserved
   works against this.

First, if the character is not reserved, then I cannot use it for anything
special in my implementation and remain compatible with the outside world.

Secondly, suppose that I use some other character, not currently legal in
identifiers, such as ``#''.  Then you probably *still* can't read my code
into your implementation, since your reader will either barf at my uses of
the illegal character or, even worse, silently parse the code making some
entirely different implementation-specific interpretation of the character.
Thus, no matter how this issue goes, you probably can't trivially parse my
code in your implementation.  Your argument is therefore moot.

Ken's message ended with the following line:

   (mod1:foo 3 x mod2:bar) --> ((*value mod1 'foo) 3 x (*value mod2 bar))

This might be true in some T-like interpretation of structured names, but
since I reject first-class environments (on the basis of large program
robustness and the value of static checking), I cannot use such a
rewriting.  Besides, it's appallingly verbose and unreadable for a
construct to be so commonly used.  One might as well force us to say (quote
...) everywhere instead of the simpler ``lexical convention''.

Jim Miller suggests that I use ``|'' instead of colon.  I considered it,
but found it less readable and far less culturally compatible than colon.
It seems silly to diverge from Common Lisp and Zetalisp on this convention
for so little reason.  After all, how much code would have to change if we
reserved colon?  None, since most implementations could simply choose to
``experiment'' with colon by allowing in identifiers, just as they do now.

Remember Alan's best point: this only affects the definition of what
programs are portable and does not force any implementation to change at
all.

	Pavel

∂05-Jul-89  2048	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Assignment to standard variables  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89  20:48:09 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26499;
          5 Jul 89 23:45 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  5 Jul 89 23:38:15 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa26423; 5 Jul 89 23:36 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 20:04:43 PDT
Date: Wed, 05 Jul 89 20:04:36 PDT
From: Pavel.pa@xerox.com
Subject: Assignment to standard variables
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-200443-7674@Xerox>

The majority of responses recently have been to my proposal that it be an
error to assign to the standard variables, present in the so-called
``initial environment''.

Jinx's first message on this topic stated his opposition to the proposal on
the grounds that ``the user takes precedence over the system'', the meaning
of which he clarified in a subsequent message.  There, he says:

    ... the system/implementation is a
    tool for the user, and as such it should accomodate the wishes of the
    user, not viceversa.  Thus if a user wants to call CAR something he
    writes/uses (in a Church pair implmentation, for example), he should
    be allowed to do so.

I have two counterarguments to this.  First, since the user cannot portably
assign to (or even rebind) variables named ``if'', ``or'', ``delay'', or
even ``unquote'' (uses of which cannot conflict with its assigned meaning),
the user has already lost this battle.

Second, I question the whole notion of ``user''.  Your usage (and that of
most of the other respondents) implies that there is some human,
interactively manipulating the state of some Scheme implementation.  This
vision of Scheme implementations is not universal.  In particular, it is
easy for me to imagine Scheme systems with many ``users'' and none at all.
In a large system, simultaneously running the code of many programmers,
each of those hackers is a ``user'' in the sense that you mean.  For any
one of them to decide to change the value of a standard variable would very
likely be disastrous for all of the others.

This is the value of lexical scoping.  It is not necessary for that one
iconoclastic user to make an assignment to CAR; they can simply rebind that
name over the scope of their piece of code.  That way, they're happy
because they can use what they see as intuitive names, and the other users
are happy because the standard variables have the predicted standard
values.

With things as they are, you cannot afford to load any code I might send
you into your running system; I might very well make every other
``user-level'' piece of code bomb completely.

The model of a single Scheme programmer sitting at his read-eval-print loop
running only his own small program cannot be the sole customer of this
language design, or else Scheme deserves the occasional claim that it is
but a ``toy'' language.  If this is the goal of the bulk of the RRRS
authors, then please let me know; I'll go quietly.  I sincerely hope it is
not.

Jinx also mentioned the use of declarations to allow compilers to process
uses of standard variables more efficiently.  One should not have to work
in a modified language semantics in order to get reasonable efficiency.  In
particular, it seems odd to resort to such semantically inconsistent
constructs just to retain the dubious right to assign to CAR.

In his second message, Jinx offered a ``pragmatic'' reason for opposing my
proposal:

    Presumably you would like
    implementations to be able to add new primitives to the language
    described in the report.  Given that the semantics of any programs
    using them might be compromised in the same way that it would be when
    using a "standard" primitive, you would disallow assignment and
    redefinition of implementation-specific primitives as well.  This
    implies that portability can only be achieved by using obscure names
    (ie G00034), since any "reasonable" name is potentially reserved by
    some implementation.

R4RS already requires, in section 1.3.1, that every implementation provide
a ``syntactic mode that preempts no lexical conventions of this report and
reserves no identifiers'' other than those listed in the report.  Such a
mode is explicitly included to ``support portable code''.

Morry Katz, in contrast, appears to be closer to supporting my proposal.
In his June 28 message on the subject, he says:

    You did not request that an implementation be allowed to prohibit
    redefinition of the primitives, but stated that you wanted redefinition
    of a primitive to be an error.

He also says:

    If you would like to propose something that allows your system to
    consider redefinition an error but does not require my system
    to do such, I might be willing to consider it.

When we state that a certain situation ``is an error'', we state that the
effect of achieving that situation is unspecified.  In particular, if we
state that assigning to standard variables is an error, the effect in one
implementation might be that the assignment takes place without difficulty.
In another, an error might be signalled.  In another, the compiler might
reject the program, noticing that the assignment expression cannot be
performed without signalling an error.  The phrase ``is an error''
encompasses all of these possibilities.  Thus, when I ask that we make
assignment to standard variables an error, I am, indeed, proposing
``something that allows [my] system to consider redefinition an error but
does not require [your] system to do such.''  This is the point I was
trying to make in my previous message on this topic.  I was not attempting
to pervert Morry's meaning at all.

Morry also mentions declarations:

    Nearly everyones compiler currently allows a compiler directive to the
effect
    that primitives should be considered immutable and therefore
inlineable.  This
    has been done for the obvious efficiency reasons and does not require
that the
    language specification be altered to always prohibit modifying
primitives.

It is to me a sign of the weakness of the current specification that
``nearly everyone'' feels the need to restrict the semantics in order to
generate reasonable code.

	Pavel

∂05-Jul-89  2227	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #153 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89  22:27:50 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27565;
          6 Jul 89 1:09 EDT
Date: 6 JUL 89  00:09:35 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #153 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907060109.aa27565@mintaka.lcs.mit.edu>

Scheme Digest #153                              6 JUL 89  00:09:35 EDT

Today's Topics:

        OOP in Scheme (serious example)

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

Date: 5 Jul 89 21:47:32 GMT
From: Brian of ASTD-CP <brian@topaz.rutgers.edu>
Subject: OOP in Scheme (serious example)
Message-Id: <1412@jato.Jpl.Nasa.Gov>

; This'll be my last submission on this topic, so I promise I won't
; be burning up the wires with any more.  I thought a serious 
; example would be of some interest, however, so here is a FIFO
; queue data type.  I'll be building classes for priority queues,
; heaps, splay trees, and assorted others, as well as a data flow
; executive.  Anyone interested further in this topic may feel
; free to e-mail me.  Again, sorry for the length of these sub-
; missions.  BCB.

;================================================================
;| Brian Beckman                  | brian@topaz.jpl.nasa.gov    |
;| Mail Stop 510-202              | (818) 397-9207              |
;| Jet Propulsion Laboratory      |                             |
;| Pasadena, CA 91109             | 3 July 1989                 |
;================================================================

;;; Adapted from Abelson & Sussman, Ch. 3, Pg 208 ff.
;;; Uses the ``methods'' OOP package.  This is an expanded,
;;; industrial-strength solution to Exercise 3.22 of A & S.

(define (new-queue . initial-list)
  
  (let (  (q (cons () ()))
          (dummy (if (not (null? initial-list))
                     (set! initial-list (car initial-list))))
          (supers ())  )
    
    (define (head) (car q))
    (define (tail) (cdr q))
    (define (set-head! item) (set-car! q item))
    (define (set-tail! item) (set-cdr! q item))
    
    (define (empty-queue?) (null? (head)))
    
    (define (front)
      (if (send self 'empty?)
          (error "FRONT called on empty queue")
          (car (head))))
    
    (define (insert-queue! item)
      (let ((elt (cons item ())))  ; could be (list item)
        (cond
         (  (send self 'empty?)
            (set-head! elt)
            (set-tail! elt)  
            self  )
         (  else
            (set-cdr! (tail) elt)
            (set-tail! elt)  
            self  ))))
    
    (define (insert-list! lyst)
      (cond
       (  (null? lyst)  self  )
       (  else
          (send self 'insert! (car lyst))
          (insert-list! (cdr lyst))  )))
    
    (define (remove-queue!)
      (cond
       (  (send self 'empty?)
          (error "REMOVE called on empty queue")  )
       (  else
          (set-head! (cdr (head)))  self)))
    
    (define (clear-queue!)
      (set! q (cons () ()))
      self)
    
    (define (print) (display (head)) (newline))
    
    (define (self msg)
      (cond
       (  (eq? msg 'insert!)       insert-queue!  )
       (  (eq? msg 'empty?)        empty-queue?   )
       (  (eq? msg 'remove!)       remove-queue!  )
       (  (eq? msg 'clear!)        clear-queue!   )
       (  (eq? msg 'front)         front  )
       (  (eq? msg 'print)         print  )
       (  (eq? msg 'list)          (lambda () (head))  )
       (  (eq? msg 'insert-list!)  insert-list!  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Queue" msg)  )))
    
    (insert-list! initial-list)  ;;; returns ``self''
    
    ))
    ;;; end of new-queue

; Test suite for queues.

(define q (new-queue '(a b c d e)))

(send q 'print)

(send q 'list)

(send (send q 'remove!) 'print)

(send q 'empty?)

(send (send q 'clear!) 'empty?)

(send q 'print)

(define q (new-queue))

(send q 'empty?)

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

End of Scheme Digest
********************

∂05-Jul-89  2230	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Fluid binding 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89  22:30:19 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27623;
          6 Jul 89 1:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  6 Jul 89 00:46:48 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa27183; 6 Jul 89 0:44 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUL 89 21:05:34 PDT
Date: Wed, 05 Jul 89 21:05:31 PDT
From: Pavel.pa@xerox.com
Subject: Fluid binding
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890705-210534-7725@Xerox>

In conversations with several other members of this group, it has been
mentioned that there really isn't very much disagreement any longer on the
issue of fluid binding; it is usually noted that we simply need a concrete
proposal on which to agree.  On this optimistic assumption, therefore, I
offer the following.

I hope that we can agree on the following points concerning fluid binding:

-- We want some kind of facility in the language that supports a form of
dynamic binding.

-- We do not want a Common Lisp-style two-namespace solution.

-- The binding construct has a syntax something like LET, in which a set of
expressions are evaluated in an unspecified order and their values used in
establishing new fluid bindings.

-- The extent of those bindings is dynamic, in the sense that they are in
effect exactly during the evaluation of the body of the binding form.

-- As a consequence, continuations created in that body should capture the
fluid environment and re-establish it upon invocation.  Such
re-establishment should not involve re-evaluating the non-body expressions
in the binding form.

-- Upon exit from the body of the binding form, the bindings in effect
before entry to the form should be restored.

One of the most commonly-cited proposals for such a facility is described,
for example, in Kent Dybvig's book.  In that facility, the so-called
``binding form'' in fact creates no bindings at all.  Instead, it saves the
current values of the named lexically-visible variables, assigns new values
during the evaluation of the body, and restores the old ones after the body
is finished.  This could be described implementationally as ``shallow
binding lexical variables''.

There are some problems with this idea for some implementations.

In a time-shared multiprocessing implementation, on each context switch the
set of bindings for each of the old and new running process must be
re-traversed, in order to properly save the old context and re-establish
the new.

Further, if two processes share a continuation, then one would expect that
when they share the captured fluid environment they also share the
``state'' of those bindings.  For example, if a process fluid-binds a
particular variable, captures the continuation, modifies the variable, and
then forks a process invoking the newly-created continuation, I would hope
that the new process would ``see'' the new value of the shared fluid
binding.  Of course, the two processes should also be able to communicate
by repeated assignments to the shared binding.  I do not see how to
implement this.

Matters are even worse for a multiprocessor implementation (that is,
multiple instruction single data, such as on a Sequent or other
shared-memory multiprocessor).  In this case, I can see no way to avoid the
use of deep binding to get the desired semantics.  In a shallow bound
implementation, multiple processes will ``race'' for ``rebinding'' a shared
variable and ultimately lose horribly.

Given that some implementations will be forced to use deep binding, we
could simply consider using the same syntax and semantics as before, but
with a deep binding implementation.  In such a situation, if a particular
variable might at some point be fluid-bound, then all references (both read
and write) would have to invoke the deep binding lookup mechanism.  Since
this would, of necessity, include all global variables (since a compiler
can never claim to have seen all uses of a global variable, it must assume
the worst), I conclude that the performance degradation would be
unacceptable.  (There are ways to make this a little better, such as adding
a bit to each such variable to say whether or not it has ever been
fluid-bound.  If not, then the value must be in the global cell and the
expensive lookup can be avoided.  It still sounds too slow to me.)

The problem here is that references to fluid-bound variables cannot, in
general, be lexically distinguished from references to non-fluid-bound
variables.  My proposal, therefore, makes such a distinction, in a sense.

Having motivated the design, I now present it.

=========

(MAKE-FLUID obj)	[Procedure]

Create and return a new ``fluid variable'' whose global value is obj.

(FLUID-REF fluid-variable)	[Procedure]

Return the value of the given fluid-variable in the current fluid
environment.

(FLUID-SET! fluid-variable obj)	[Procedure]

Change the value of the given fluid-variable in the current fluid
environment.  The returned value is unspecified.

(FLUID-LET ((var-expr val-expr) ...) body)	[Syntax]

Evaluate the var-exprs and val-exprs in an unspecified order; the var-exprs
should yield fluid variables.  Return the value of the body in a new,
nested fluid environment in which the given fluid variables have new
bindings, initialized to the given values.  This fluid environment has
precisely the same extent as the evaluation of the body and is thus
captured by continuations created within the body and re-established by
those continuations on invocation.

=========

The implementation is free to adopt either shallow or deep binding.  In
either case, a ``fluid variable'' is simply a one-cell allocated datum
containing the value of the fluid variable either in the current fluid
environment (shallow binding) or in the global, top-level fluid environment
(deep binding).  In either case, the address of the cell can be used as the
``identifier'' for the variable in the environment.  This proposal, in
comparison to the one discussed before, increases the cost per reference in
a shallow-bound implementation by one memory reference, indirecting through
the cell-address.  This seems a small price to pay.

The proposal is unusual in that the variable position in FLUID-LET is
evaluated, but I anticipate that  in almost all uses the expression will be
a simple lexical variable reference:

		(define *foo* (make-fluid 7))
	
		(fluid-let ((*foo* 8))
		    (+ (fluid-ref *foo*) 1))

		=> 9

Comments?

	Pavel

∂05-Jul-89  2240	@mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Assignment to standard variables   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 5 Jul 89  22:40:01 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27843;
          6 Jul 89 1:21 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  6 Jul 89 01:17:50 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa27680;
          6 Jul 89 1:14 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Thu, 6 Jul 89 01:11:35 edt
Date: Thu, 6 Jul 89 01:11:35 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907060511.AA28668@ZURICH.AI.MIT.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 20:04:36 PDT <890705-200443-7674@Xerox>
Subject: Assignment to standard variables


    I have two counterarguments to this.  First, since the user cannot portably
    assign to (or even rebind) variables named ``if'', ``or'', ``delay'', or
    even ``unquote'' (uses of which cannot conflict with its assigned meaning),
    the user has already lost this battle.

We've been trying to fix this for quite a while.  It has not been
fixed in R4RS because of political and technical problems having to do
with the actual solutions suggested, not because we don't agree that
this should be fixed.

    Second, I question the whole notion of ``user''.  Your usage (and that of
    most of the other respondents) implies that there is some human,
    interactively manipulating the state of some Scheme implementation.  This
    vision of Scheme implementations is not universal.  In particular, it is
    easy for me to imagine Scheme systems with many ``users'' and none at all.
    In a large system, simultaneously running the code of many programmers,
    each of those hackers is a ``user'' in the sense that you mean.  For any
    one of them to decide to change the value of a standard variable would very
    likely be disastrous for all of the others.

You misunderstand my argument in many ways:

1) By user I mean any programmer, not necessarily human.  I would like
my program generating programs not to have to probe the underlying
implementation for the list of all unusable names, which is likely to
evolve as the implementation and the language evolve.  Furthermore, I
would like not to have to rewrite my programs when/if R5RS comes out
just because a new procedure has been added to the report.

2) Redefinition does not imply assignment.  In a scheme system with
first class environments, each user can get his own (initially
identical) first class environment in which he can redefine as he
pleases, without affecting anyone else.  [This is what I consider
essential.  I would not be terribly upset if we disallowed 
(set! car ...) but would not tolerate disallowing (define car ...).]  
Note that my position does not require first class environments, it
simply requires that each user's interactive environment be isolated
from what the system uses, and from what other users use if there are
multiple users.  As I mentioned in another message, security of the
implementation is an implementation problem, not a language problem.

3) Even assignment of shared variables should be legal.  Assignment of
shared variables is a double edged sword:  It is potentially dangerous
(like anything powerful), but if used judiciously it provides a
wonderful way of debugging and patching running systems.

Think of the following analogy:

The environment tree is like a hierarchical file system (with path
inheritance).  Each user has his own "home directory" where he can
name any file anything he wants, although shadowing the name where a
system provided utility resides may be inconvenient.  On the other
hand, s/he can fix a bug in the C compiler (for example) by replacing
(assigning) the current file containing it.  Operating systems need
the ability to replace system utilities because they are intended to
run for long periods of time and allow incremental patches.  Please
don't remove such an ability from my favorite operating system!  Your
suggestion would make Scheme too inflexible for long running evolving
applications.

    This is the value of lexical scoping.  It is not necessary for that one
    iconoclastic user to make an assignment to CAR; they can simply rebind that
    name over the scope of their piece of code.  That way, they're happy
    because they can use what they see as intuitive names, and the other users
    are happy because the standard variables have the predicted standard
    values.

Lexical scoping as it appears in the report does not solve the
problem.  The top level environment allows me some debugging ability
(through interaction) which I don't have when I use any other
mechanism.  If your implementation provides interaction (with
definition) in arbitrary environments, your implementation can solve
the isolation problem trivially.

    Jinx also mentioned the use of declarations to allow compilers to process
    uses of standard variables more efficiently.  One should not have to work
    in a modified language semantics in order to get reasonable efficiency.  In
    particular, it seems odd to resort to such semantically inconsistent
    constructs just to retain the dubious right to assign to CAR.

Reasonable is a subjective term.  I think it is perfectly possible to
obtain reasonable efficiency without declarations.  Efficiency beyond
this may require concessions, and declarations are a small price to
pay.  I would like to see a compiler that provides complete security,
complete debugability, and utmost efficiency without any form of
declaration, but I have not yet seen such a beast (nor do I think it
is possible to have one on stock hardware).

Again, although I think that the right to assign to CAR is important,
the one that I'm more concerned with is the right to DEFINE CAR.  You
are viewing definition and assignment as the same thing, but in my
mind (and in the implementation that I use) they are not.  If your
implementation and development environment are confused about this,
that's your implementor's problem, but please don't impose these
limitations on the language or my implementation.

You also seem to have shifted your argument from semantic
predictability to efficiency, and efficiency has never been important
when designing Scheme.  The problem with efficiency as an argument in
language design is that it is a time dependent parameter, since it
depends on compilation technology and hardware, both of which change
quickly.  Would you make the same efficiency argument about MAP that
you are making about CAR?  What about LIST-TAIL or
CALL-WITH-CURRENT-CONTINUATION?  Yet if I'm playing with streams I
would like to define MAP, and if I'm playing with interpreters I may
want to redefine CALL-WITH-CURRENT-CONTINUATION.  In all but contrived
situations the efficiency lost from not open coding MAP or
CALL-WITH-CURRENT-CONTINUATION is minimal, so your efficiency argument
does not really stand up.

    R4RS already requires, in section 1.3.1, that every implementation provide
    a ``syntactic mode that preempts no lexical conventions of this report and
    reserves no identifiers'' other than those listed in the report.  Such a
    mode is explicitly included to ``support portable code''.

I think most people would agree that R4RS as it currently stands is a
toy language.  Besides macros, fluid binding and other well known
conveniences, it lacks any practical way of separating large programs
into semi-independent subprograms without exporting zillions of names
into the top level environment.

I think most implementations provide some way of solving or bypassing
these problems.  Thus, until we solve these issues, R4RS is unusable
for large programs, and your argument doesn't help me at all.

Some day in the future, when we solve (if we can ever agree on
anything else) these problems, this may be an option, but almost any
facility that I can envision for separating and combining subprograms
will allow me to have my own definitions of anything I want.

I'm afraid we are going to disagree very strongly on this issue, and
therefore we are at an impasse.  Unfortunately that seems to be
happening with everything else that anyone proposes, so I'm afraid
that R3.95RS is the end of the line.  What a pity.

∂06-Jul-89  0713	@MC.lcs.mit.edu:jmiller@crl.dec.com 	Reserving a character for experimentation  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89  07:13:39 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03520;
          6 Jul 89 10:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  6 Jul 89 10:04:27 EDT
Received: from [128.45.9.1] by mintaka.lcs.mit.edu id aa03471;
          6 Jul 89 10:02 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	id AA09772; Thu, 6 Jul 89 07:01:41 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	for rrrs-authors@mc.lcs.mit.edu; id AA09772; Thu, 6 Jul 89 07:01:41 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
	id AA06722; Thu, 6 Jul 89 10:02:56 EDT
Date: Thu, 6 Jul 89 09:59:48 EDT
From: jmiller@crl.dec.com
Message-Id: <8907061359.AA00613@peanut.DEC.COM>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: 5-Jul-89 1904 PDT's message of Wed, 5 Jul 89 22:49:11 EDT <8907060249.AA06354@crl.crl.dec.com>
Subject: Reserving a character for experimentation
Reply-To: JMiller@crl.enet.dec.com

Sorry, but I can't really see a valid argument for taking a character
already in use (not just presumably, but actually) in existing Scheme
code and reserving it because you prefer it over other choices already
available.  I'm not a fan of lexical syntax, and I think the damage
caused to existing (possibly portable) code outweighs the possible
gains.

I don't understand the following comment:

     After all, how much code would have to change if we reserved
     colon?  None, since most implementations could simply choose to
     ``experiment'' with colon by allowing in identifiers, just as
     they do now.

It appears to me that this simply isn't true.  Portable code would not
be permitted to use names with embedded colons, and such code already
exists.  Perhaps what you meant is that no individual's code running
in an existing implementation would be affected -- but I'm more
worried about the portable code I've written over the years.  I'd like
it to remain portable, and your suggesting one more headache to worry
about.

--Jim

P.S.: Another pair of suggestions, valid within the existing
framework.  Other ideas along this line that would be more extensible
would be very interesting.

(module#:submodule#:procedure ...)

(procedure #!part-of submodule #!part-of module ...)

∂06-Jul-89  0730	@MC.lcs.mit.edu:sfk@hplb.hpl.hp.com 	Re: Fluid binding 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89  07:30:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03706;
          6 Jul 89 10:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  6 Jul 89 10:20:31 EDT
Received: from hplb.hpl.hp.com by mintaka.lcs.mit.edu id aa03567;
          6 Jul 89 10:14 EDT
Received: from sknight.hpl.hp.com by hplb; Thu, 6 Jul 89 15:04:42 bst
Message-Id: <8907061404.AA28845@otter.hpl.hp.com>
Received: by sknight; Thu, 6 Jul 89 15:01:12 bst
From: Steve Knight <sfk@hplb.hpl.hp.com>
Subject: Re: Fluid binding
To: Pavel.pa@xerox.com
Date: Thu, 6 Jul 89 15:01:09 BST
Cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: <890705-210534-7725@Xerox>; from "Pavel.pa@xerox.com" at Jul 05, 89 9:05 pm
X-Mailer: Elm [version 2.0 beta]

Re: Fluid Binding

An effective approach to fluid binding is dynamic localisation of arbitrary
expressions, exemplified by the "dlocal" construct of Pop11.  The idea is to
permit the localisation of any expression & fluid binding drops out as a
special case.

The general construct might be [I'm not suggesting this syntax]..
    (dlocal
        (
            ( save-expression entry-action exit-action )
            ( save-expression entry-action exit-action )
            ...                   
        )
        body
    )
and the code generated for
    (let-fluid
        ((x E))
        body
    )
would expand into
    (dlocal
        (   (   x                   ; save
                (set! x E)          ; entry
                (set! x (saved))    ; exit, with the "saved" form
            )
        )
        body                    ; sequence of expressions
    )

It would then be possible to do things like localise the "car" of a pair.
eg.
    (dlocal
        (   (   (car x)             ; save
                (set-car! x E)      ; entry-action
                (set-car! x (saved)); exit-action
            )
        )                     
        ...
    )

In Pop11 there is an association between access procedures such as "car" and
the update procedure "set-car!" ; namely an operation called "updater" which
maps "car" into "set-car!".  Because of that, it is possible to write dlocal
expressions more elegantly as
    (dlocal
        (   (save-expression update-value)
            ...
        )                     
        body
    )
So the dynamic localisation of the "car" of a list would be
    (dlocal
        (   ((car x) E)
            ...
        )                     
    )
The common case of localising a variable could be done by simply allowing a
third form for that.
    (dlocal
        (   (variable E)
            ...
        )
        ...                   
    )

Putting these cases together, here is a piece of code that localises the
variable "x", the car of the list "y", and closes the output-port "z" on exit.
    (dlocal
        (   (x Ex)
            ((car y) Ey)
            (nil nil (close-output-port z))

        )...
    )


An interesting issue is deciding how dynamic localisation interacts with
continuations.  In Pop11, the default solution is to run local-actions on
continuation activation.  However it is possible to determine whether the
local-action is being run because of a continuation swap or a procedure exit.
Determining the right solution for Scheme would require careful thought.

Steve Knight

∂06-Jul-89  0843	@mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Fluid binding  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89  08:43:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04606;
          6 Jul 89 11:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  6 Jul 89 11:37:54 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa04479;
          6 Jul 89 11:31 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Thu, 6 Jul 89 11:28:47 edt
Date: Thu, 6 Jul 89 11:28:47 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907061528.AA01541@ZURICH.AI.MIT.EDU>
To: sfk@hplb.hpl.hp.com
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Steve Knight's message of Thu, 6 Jul 89 15:01:09 BST <8907061404.AA28845@otter.hpl.hp.com>
Subject: Fluid binding

Pop11s dlocal is the analogous of dynamic-wind, a utility available in
some Scheme implementations.

A "shallow bound" implementation of fluid-let can easily be built on
top of dynamic-wind by expanding

(fluid-let ((foo <value>))
  <code>)

into

(let ((dummy <value>))
  (dynamic-wind
   (lambda ()
     (let ((outside foo))
       (set! foo dummy)
       (set! dummy outside)))
   (lambda ()
     <code>)
   (lambda ()
     (let ((inside foo))
       (set! foo dummy)
       (set! dummy inside)))))

Unfortunately this does not work well on shared memory multiprocessors,
as Pavel pointed out.


∂06-Jul-89  1012	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	Assignment to standard variables
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89  10:12:40 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05654;
          6 Jul 89 13:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  6 Jul 89 12:38:24 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa05358;
          6 Jul 89 12:32 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA25682; Thu, 6 Jul 89 09:31:39 PDT
Date: Thu, 6 Jul 89 09:31:39 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907061631.AA25682@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 20:04:36 PDT <890705-200443-7674@Xerox>
Subject: Assignment to standard variables

   Date: Wed, 05 Jul 89 20:04:36 PDT
   From: Pavel.pa@xerox.com

   The majority of responses recently have been to my proposal that it be an
   error to assign to the standard variables, present in the so-called
   ``initial environment''.

   Jinx's first message on this topic stated his opposition to the proposal on
   the grounds that ``the user takes precedence over the system'', the meaning
   of which he clarified in a subsequent message.  There, he says:

       ... the system/implementation is a
       tool for the user, and as such it should accomodate the wishes of the
       user, not viceversa.  Thus if a user wants to call CAR something he
       writes/uses (in a Church pair implmentation, for example), he should
       be allowed to do so.

   I have two counterarguments to this.  First, since the user cannot portably
   assign to (or even rebind) variables named ``if'', ``or'', ``delay'', or
   even ``unquote'' (uses of which cannot conflict with its assigned meaning),
   the user has already lost this battle.

This is one of the reasons we need macros.  As soon as we have them, I will be
able to override the default definitions for special forms as well.

   Second, I question the whole notion of ``user''.  Your usage (and that of
   most of the other respondents) implies that there is some human,
   interactively manipulating the state of some Scheme implementation.  This
   vision of Scheme implementations is not universal.  In particular, it is
   easy for me to imagine Scheme systems with many ``users'' and none at all.
   In a large system, simultaneously running the code of many programmers,
   each of those hackers is a ``user'' in the sense that you mean.  For any
   one of them to decide to change the value of a standard variable would very
   likely be disastrous for all of the others.

I would suggest that in such an environment each of the users should have their
REP loop executing in a separate binding environment in which all of the Scheme
primitives are bound.  When a user rebinds a primitive in this type of
environment structure, they only effect themselves.  If you have a module
package (as I believe you want), a user who has rebound a primitive could get
back the original definition by looking it up in some (possibly immutable in
your implementation) system environment/module.

   This is the value of lexical scoping.  It is not necessary for that one
   iconoclastic user to make an assignment to CAR; they can simply rebind that
   name over the scope of their piece of code.  That way, they're happy
   because they can use what they see as intuitive names, and the other users
   are happy because the standard variables have the predicted standard
   values.

   With things as they are, you cannot afford to load any code I might send
   you into your running system; I might very well make every other
   ``user-level'' piece of code bomb completely.

(See above, not true)

   The model of a single Scheme programmer sitting at his read-eval-print loop
   running only his own small program cannot be the sole customer of this
   language design, or else Scheme deserves the occasional claim that it is
   but a ``toy'' language.  If this is the goal of the bulk of the RRRS
   authors, then please let me know; I'll go quietly.  I sincerely hope it is
   not.

   Jinx also mentioned the use of declarations to allow compilers to process
   uses of standard variables more efficiently.  One should not have to work
   in a modified language semantics in order to get reasonable efficiency.  In
   particular, it seems odd to resort to such semantically inconsistent
   constructs just to retain the dubious right to assign to CAR.

You cloud this issue by placing your value judgements on the rebinding of
primitves by refering to our desire to do such as of "dubious" value.  What we
are really discussing is what should be the default semantics.  If your
semantics were the default then I would require a declaration to enable
rebinding of primitives.  I happen to feel that this second polarity ios less
elegant; but, you would obviously disagree.  At the risk of offending the faint
of heart, I would point out that many systems also have type declarations to
improve compilation efficiency; however, I doubt many people would state that
Scheme should always require type information be supplied in all constructs in
order to avoid anyone ever having to use such declarations.

   In his second message, Jinx offered a ``pragmatic'' reason for opposing my
   proposal:

       Presumably you would like
       implementations to be able to add new primitives to the language
       described in the report.  Given that the semantics of any programs
       using them might be compromised in the same way that it would be when
       using a "standard" primitive, you would disallow assignment and
       redefinition of implementation-specific primitives as well.  This
       implies that portability can only be achieved by using obscure names
       (ie G00034), since any "reasonable" name is potentially reserved by
       some implementation.

   R4RS already requires, in section 1.3.1, that every implementation provide
   a ``syntactic mode that preempts no lexical conventions of this report and
   reserves no identifiers'' other than those listed in the report.  Such a
   mode is explicitly included to ``support portable code''.

   Morry Katz, in contrast, appears to be closer to supporting my proposal.
   In his June 28 message on the subject, he says:

       You did not request that an implementation be allowed to prohibit
       redefinition of the primitives, but stated that you wanted redefinition
       of a primitive to be an error.

   He also says:

       If you would like to propose something that allows your system to
       consider redefinition an error but does not require my system
       to do such, I might be willing to consider it.

   When we state that a certain situation ``is an error'', we state that the
   effect of achieving that situation is unspecified.  In particular, if we
   state that assigning to standard variables is an error, the effect in one
   implementation might be that the assignment takes place without difficulty.
   In another, an error might be signalled.  In another, the compiler might
   reject the program, noticing that the assignment expression cannot be
   performed without signalling an error.  The phrase ``is an error''
   encompasses all of these possibilities.  Thus, when I ask that we make
   assignment to standard variables an error, I am, indeed, proposing
   ``something that allows [my] system to consider redefinition an error but
   does not require [your] system to do such.''  This is the point I was
   trying to make in my previous message on this topic.  I was not attempting
   to pervert Morry's meaning at all.

You have grossly misrepresented my position (albeit probably by accident).  I
believe that anything which is described by "is an error" in the report to be a
violation of Scheme.  To have the semantics which I believe are correct be
described as "is an error" is COMPLETELY unsatisfactory to me.  I suggest that
we, as a community, work harder on agreeing on some module system.  This would
allow us to agree on the name a module in which all of the primitives would be
bound to implementations of the semantics specified in RNRS.  Users who wanted
to guarantee that the values of the primitves never changed could reference
them in this module.

   Morry also mentions declarations:

       Nearly everyones compiler currently allows a compiler directive to the
   effect
       that primitives should be considered immutable and therefore
   inlineable.  This
       has been done for the obvious efficiency reasons and does not require
   that the
       language specification be altered to always prohibit modifying
   primitives.

   It is to me a sign of the weakness of the current specification that
   ``nearly everyone'' feels the need to restrict the semantics in order to
   generate reasonable code.

	   Pavel


(see above)
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂06-Jul-89  1035	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	Fluid binding    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89  10:34:39 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05813;
          6 Jul 89 13:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  6 Jul 89 12:44:59 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa05480;
          6 Jul 89 12:41 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA25714; Thu, 6 Jul 89 09:41:08 PDT
Date: Thu, 6 Jul 89 09:41:08 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907061641.AA25714@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 21:05:31 PDT <890705-210534-7725@Xerox>
Subject: Fluid binding

   Date: Wed, 05 Jul 89 21:05:31 PDT
   From: Pavel.pa@xerox.com

   In conversations with several other members of this group, it has been
   mentioned that there really isn't very much disagreement any longer on the
   issue of fluid binding; it is usually noted that we simply need a concrete
   proposal on which to agree.  On this optimistic assumption, therefore, I
   offer the following.

   I hope that we can agree on the following points concerning fluid binding:

   -- We want some kind of facility in the language that supports a form of
   dynamic binding.

   -- We do not want a Common Lisp-style two-namespace solution.

   -- The binding construct has a syntax something like LET, in which a set of
   expressions are evaluated in an unspecified order and their values used in
   establishing new fluid bindings.

   -- The extent of those bindings is dynamic, in the sense that they are in
   effect exactly during the evaluation of the body of the binding form.

   -- As a consequence, continuations created in that body should capture the
   fluid environment and re-establish it upon invocation.  Such
   re-establishment should not involve re-evaluating the non-body expressions
   in the binding form.

   -- Upon exit from the body of the binding form, the bindings in effect
   before entry to the form should be restored.

   One of the most commonly-cited proposals for such a facility is described,
   for example, in Kent Dybvig's book.  In that facility, the so-called
   ``binding form'' in fact creates no bindings at all.  Instead, it saves the
   current values of the named lexically-visible variables, assigns new values
   during the evaluation of the body, and restores the old ones after the body
   is finished.  This could be described implementationally as ``shallow
   binding lexical variables''.

   There are some problems with this idea for some implementations.

   In a time-shared multiprocessing implementation, on each context switch the
   set of bindings for each of the old and new running process must be
   re-traversed, in order to properly save the old context and re-establish
   the new.

   Further, if two processes share a continuation, then one would expect that
   when they share the captured fluid environment they also share the
   ``state'' of those bindings.  For example, if a process fluid-binds a
   particular variable, captures the continuation, modifies the variable, and
   then forks a process invoking the newly-created continuation, I would hope
   that the new process would ``see'' the new value of the shared fluid
   binding.  Of course, the two processes should also be able to communicate
   by repeated assignments to the shared binding.  I do not see how to
   implement this.

   Matters are even worse for a multiprocessor implementation (that is,
   multiple instruction single data, such as on a Sequent or other
   shared-memory multiprocessor).  In this case, I can see no way to avoid the
   use of deep binding to get the desired semantics.  In a shallow bound
   implementation, multiple processes will ``race'' for ``rebinding'' a shared
   variable and ultimately lose horribly.

   Given that some implementations will be forced to use deep binding, we
   could simply consider using the same syntax and semantics as before, but
   with a deep binding implementation.  In such a situation, if a particular
   variable might at some point be fluid-bound, then all references (both read
   and write) would have to invoke the deep binding lookup mechanism.  Since
   this would, of necessity, include all global variables (since a compiler
   can never claim to have seen all uses of a global variable, it must assume
   the worst), I conclude that the performance degradation would be
   unacceptable.  (There are ways to make this a little better, such as adding
   a bit to each such variable to say whether or not it has ever been
   fluid-bound.  If not, then the value must be in the global cell and the
   expensive lookup can be avoided.  It still sounds too slow to me.)

   The problem here is that references to fluid-bound variables cannot, in
   general, be lexically distinguished from references to non-fluid-bound
   variables.  My proposal, therefore, makes such a distinction, in a sense.

To the best of my recolection, all of these problems were adequately addressed
in a solution to this problem of fluid-let for multiprocessors deveoloped at a
meeting between the MIT CScheme community and the BBN Butterfly Scheme group
about 3 years ago.  Again straining my memory, I seem to recall that most of
the good ideas came from Chris Hansen, so we should probably ask him to refresh
our collective memories as to his solution.

   Having motivated the design, I now present it.

   =========

   (MAKE-FLUID obj)	[Procedure]

   Create and return a new ``fluid variable'' whose global value is obj.

   (FLUID-REF fluid-variable)	[Procedure]

   Return the value of the given fluid-variable in the current fluid
   environment.

   (FLUID-SET! fluid-variable obj)	[Procedure]

   Change the value of the given fluid-variable in the current fluid
   environment.  The returned value is unspecified.

   (FLUID-LET ((var-expr val-expr) ...) body)	[Syntax]

   Evaluate the var-exprs and val-exprs in an unspecified order; the var-exprs
   should yield fluid variables.  Return the value of the body in a new,
   nested fluid environment in which the given fluid variables have new
   bindings, initialized to the given values.  This fluid environment has
   precisely the same extent as the evaluation of the body and is thus
   captured by continuations created within the body and re-established by
   those continuations on invocation.

   =========

   The implementation is free to adopt either shallow or deep binding.  In
   either case, a ``fluid variable'' is simply a one-cell allocated datum
   containing the value of the fluid variable either in the current fluid
   environment (shallow binding) or in the global, top-level fluid environment
   (deep binding).  In either case, the address of the cell can be used as the
   ``identifier'' for the variable in the environment.  This proposal, in
   comparison to the one discussed before, increases the cost per reference in
   a shallow-bound implementation by one memory reference, indirecting through
   the cell-address.  This seems a small price to pay.

   The proposal is unusual in that the variable position in FLUID-LET is
   evaluated, but I anticipate that  in almost all uses the expression will be
   a simple lexical variable reference:

		   (define *foo* (make-fluid 7))

		   (fluid-let ((*foo* 8))
		       (+ (fluid-ref *foo*) 1))

		   => 9

   Comments?

	   Pavel


I find this special designation of fluid variables to be quite distasteful.  It
would require a much better argument as to the impossibility of doing shallow
binding reasonably on multiprocessors before I would be willing to accept a
proposal of this form.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂06-Jul-89  1043	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	Fluid binding    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89  10:43:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06108;
          6 Jul 89 13:36 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  6 Jul 89 13:27:30 EDT
Received: from Sesame.Stanford.EDU by mintaka.lcs.mit.edu id aa05953;
          6 Jul 89 13:21 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA25816; Thu, 6 Jul 89 10:07:31 PDT
Date: Thu, 6 Jul 89 10:07:31 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907061707.AA25816@sesame.Stanford.EDU>
To: sfk@hplb.hpl.hp.com
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Steve Knight's message of Thu, 6 Jul 89 15:01:09 BST <8907061404.AA28845@otter.hpl.hp.com>
Subject: Fluid binding

   From: Steve Knight <sfk@hplb.hpl.hp.com>
   Date: Thu, 6 Jul 89 15:01:09 BST
   X-Mailer: Elm [version 2.0 beta]

   Re: Fluid Binding

   An effective approach to fluid binding is dynamic localisation of arbitrary
   expressions, exemplified by the "dlocal" construct of Pop11.  The idea is to
   permit the localisation of any expression & fluid binding drops out as a
   special case.

   The general construct might be [I'm not suggesting this syntax]..
       (dlocal
	   (
	       ( save-expression entry-action exit-action )
	       ( save-expression entry-action exit-action )
	       ...                   
	   )
	   body
       )
   and the code generated for
       (let-fluid
	   ((x E))
	   body
       )
   would expand into
       (dlocal
	   (   (   x                   ; save
		   (set! x E)          ; entry
		   (set! x (saved))    ; exit, with the "saved" form
	       )
	   )
	   body                    ; sequence of expressions
       )

   It would then be possible to do things like localise the "car" of a pair.
   eg.
       (dlocal
	   (   (   (car x)             ; save
		   (set-car! x E)      ; entry-action
		   (set-car! x (saved)); exit-action
	       )
	   )                     
	   ...
       )

   In Pop11 there is an association between access procedures such as "car" and
   the update procedure "set-car!" ; namely an operation called "updater" which
   maps "car" into "set-car!".  Because of that, it is possible to write dlocal
   expressions more elegantly as
       (dlocal
	   (   (save-expression update-value)
	       ...
	   )                     
	   body
       )
   So the dynamic localisation of the "car" of a list would be
       (dlocal
	   (   ((car x) E)
	       ...
	   )                     
       )
   The common case of localising a variable could be done by simply allowing a
   third form for that.
       (dlocal
	   (   (variable E)
	       ...
	   )
	   ...                   
       )

   Putting these cases together, here is a piece of code that localises the
   variable "x", the car of the list "y", and closes the output-port "z" on exit.
       (dlocal
	   (   (x Ex)
	       ((car y) Ey)
	       (nil nil (close-output-port z))

	   )...
       )


   An interesting issue is deciding how dynamic localisation interacts with
   continuations.  In Pop11, the default solution is to run local-actions on
   continuation activation.  However it is possible to determine whether the
   local-action is being run because of a continuation swap or a procedure exit.
   Determining the right solution for Scheme would require careful thought.

   Steve Knight

MIT Cscheme already has a form which is in many ways similar to DLOCAL.  Its
syntax is (dynamic-wind <entry-form> <body> <exit-form>).  (I hope I have those
in the correct order!)  In the absence of continuations, the entry form is
executed first, followed by the body, followeed by the exit form.  The value
returned by dynamic-wind is the value of BODY.  If a throw to a continuation
which was captured outside the dynamic scope of a dynamic-wind form takes place
from inside the body of that form, then the exit-form of that dynamic-wind is
executed prior to invoking the continuation.  Similarly, if a throw from
outside the dynamic scope of a dynamic-wind form to a continuation captured
while executing body takes place then the entry-form of the given dynamic wind
is reexecuted before the continuation is invoked.  As with dlocal, fluid-let
can be built as a macro on top of this verrsion of dynamic-wind.  

I do not remember if the semantics of throing into or out of the entry and exit
forms is specified for dynamic-wind.  At the moment it is not obvious to me
what the correct semantics are; but, I am interested in anyones suggestions.

-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂06-Jul-89  1058	@MC.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Fluid binding  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89  10:58:10 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06245;
          6 Jul 89 13:47 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  6 Jul 89 13:38:14 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa06027;
          6 Jul 89 13:32 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Thu, 6 Jul 89 13:29:39 edt
Date: Thu, 6 Jul 89 13:29:39 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907061729.AA02296@ZURICH.AI.MIT.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 21:05:31 PDT <890705-210534-7725@Xerox>
Subject: Fluid binding

I like your proposal, but I have a some suggestions:

1) MAKE-FLUID, FLUID-REF and FLUID-SET! don't have much to do with
fluids, they have to do with cells (or boxes, as some other people
call them).  As such, I would like them to be renamed to
MAKE-CELL, CELL-REF, and CELL-SET!.

Alternatively we could have both MAKE-CELL, CELL-REF, CELL-SET! to
manipulate cells (the selector and mutator always provide the global
value), and FLUID-CELL-REF, FLUID-CELL-SET! to access the current
dynamic value.  Which of the accessors is written on top of which
depends on whether the implementation is deep or shallow.

2) Although I admit that FLUID-LET would be the most common way of
obtaining dynamic behavior, I'd rather have it be a simple macro that
expands into a standard procedure.  In particular, I would like to
have

(FLUID-LET ((<var-expr1> <val-expr1>) (<var-expr2> <val-expr2>) ... ) <body>)

expand into something like

(with-cell-contents
  (list var-expr1 var-expr2 ...)
  (list val-expr1 val-expr2 ...)
  (lambda ()
   <body>))

3) There are many incompatible versions of FLUID-LET out there, so I
think we should use a different name for it so that existing
implementations can continue using their code without having to
rewrite it and can provide two different mechanisms, the standard, and
the old one.  I would suggest WITH-FLUID-CONTENTS or something like
that, but I'm not good at choosing names.

4)
    Given that some implementations will be forced to use deep binding, we
    could simply consider using the same syntax and semantics as before, but
    with a deep binding implementation.  In such a situation, if a particular
    variable might at some point be fluid-bound, then all references (both read
    and write) would have to invoke the deep binding lookup mechanism.  Since
    this would, of necessity, include all global variables (since a compiler
    can never claim to have seen all uses of a global variable, it must assume
    the worst), I conclude that the performance degradation would be
    unacceptable.  (There are ways to make this a little better, such as adding
    a bit to each such variable to say whether or not it has ever been
    fluid-bound.  If not, then the value must be in the global cell and the
    expensive lookup can be avoided.  It still sounds too slow to me.)

It is not necessarily as expensive as you think.  Assuming that
implementations have a reasonably cheap way of detecting unbound
variables at run time (perhaps the bit that you mention), you can make
all variables which have fluid values appear to be unbound, and make
the unbound trap handler "discover" that the variable was in fact
bound and fluid.  Under these conditions, the cost of accessing a
global variable that has NOT been fluidized does not change, while
accessing one that has becomes a little more expensive, but not too
much if the trap mechanism is reasonably efficient.

I'm not advocating going to this method (it is what Jim Miller's
MultiScheme does), but I think that your objections on the grounds of
performance are not really justified.

∂06-Jul-89  1637	@mc.lcs.mit.edu,@ZURICH.ai.mit.edu:ramsdell@linus.mitre.org 	An International Character Set for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89  16:37:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10625;
          6 Jul 89 19:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  6 Jul 89 19:25:20 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa10560;
          6 Jul 89 19:23 EDT
Received: from mbunix.mitre.org ([129.83.20.100]) by ZURICH.AI.MIT.EDU; Thu, 6 Jul 89 19:20:17 edt
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA21801; Thu, 6 Jul 89 13:54:17 EDT
Posted-Date: Thu, 6 Jul 89 13:54:23 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA08610; Thu, 6 Jul 89 13:54:23 EDT
Date: Thu, 6 Jul 89 13:54:23 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907061754.AA08610@huxley.mitre.org>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: An International Character Set for R4RS
Reply-To: ramsdell@mitre.org

One way of making Scheme more inviting to Europeans, is to allow the
use of indentifiers which include letters from their alphabet.  I
would like a sentences added to R4RS which encourages the support of
the ISO Latin-1 character set.  Of course, no implementation would be
required to support all of the ISO Latin-1 character set.
John

∂06-Jul-89  1902	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Re: Assignment to standard variables   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89  19:02:19 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12449;
          6 Jul 89 21:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  6 Jul 89 21:52:57 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa12246; 6 Jul 89 21:42 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 06 JUL 89 18:41:51 PDT
Date: Thu, 06 Jul 89 18:42:56 PDT
From: Pavel.pa@xerox.com
Subject: Re: Assignment to standard variables
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890706-184151-9881@Xerox>

I'm too tired to keep fighting about (I mean, discussing) this issue.  I
withdraw the proposal.

	Pavel

∂06-Jul-89  2228	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #154 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 6 Jul 89  22:28:36 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17259;
          7 Jul 89 1:12 EDT
Date: 7 JUL 89  00:09:39 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #154 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907070112.aa17259@mintaka.lcs.mit.edu>

Scheme Digest #154                              7 JUL 89  00:09:39 EDT

Today's Topics:

        Scheme Digest #151 
        Looking for MIT C-scheme manual

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

Date: 3 JUL 89  00:09:16 EDT
From: Automatic Scheme Digestifier <daitc!mc.lcs.mit.edu!Scheme-Request@dsac.dla.mil>
Subject: Scheme Digest #151 
Reply-To: daitc!mc.lcs.mit.edu!Scheme@dsac.dla.mil
Message-Id:  <8907030101.aa21379@mintaka.lcs.mit.edu>

Scheme Digest #151                              3 JUL 89  00:09:16 EDT

Today's Topics:

        OOP in Scheme

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

Date: 2 Jul 89 07:31:07 GMT
From: Brian of ASTD-CP <brian@jade.berkeley.edu>
Subject: OOP in Scheme
Message-Id: <1404@jato.Jpl.Nasa.Gov>

; methods2.scm
;
; ===============================================================
; Brian Beckman                  |    brian@topaz.jpl.nasa.gov
; Mail Stop 510-202              |    (818) 397-9207
; Jet Propulsion Laboratory      | 
; Pasadena, CA 91109             |    30 June 1989
; ===============================================================

; INTRODUCTION
;
; This is a tiny object-oriented programming system with multiple
; inheritance and error handling.  It is modeled after the message
; passing modules in Chapter 3 of Abelson & Sussman.  It is 
; implemented in ``pure'' Scheme, without macros or syntax
; extensions.
; 
; This programming system is implemented as a technique, or
; programming convention, with some helper routines.  The programming
; convention is not enforced, as we choose to avoid syntax-extensions
; for portability's sake.  The technique is illustrated in this file
; with a few examples.  In example one, a parent class, named
; ``parent,'' passes its attributes to a child named ``child.''  In
; example two, two parents, ``mother'' ``fater'', pass their attributes
; to a child class, ``daughter.''  The reader will perceive the technique
; by generalization from these examples and will be able to apply it
; to his or her own problems.
; 
; Every class is represented by its constructor procedure.  This
; procedure returns a message dispatching procedure.  The message
; dispatching procedure should be named ``self'' so that an object can
; conveniently send messages to itself.  However, ``self'' is an
; internal name not known outside the constructor.  
; 
; In summary, classes are represented by constructor procedures, and
; objects, or instances of classes, are represented by message
; dispatching procedures.  The present version of ``methods'' does not
; support code sharing, so every instance of a class has its own
; private copies of the method code.  We expect to implement code
; sharing in a later version of ``methods''.
; 
; The message dispatching procedure walks the multiple inheritance
; hierarchy upwards until it finds an object that can understand a
; message, starting with itself.  If no object that can understand the
; message is found, a global error procedure is called.
; 
; IMPLEMENTATION
;
; Error processing is challenging.  We should like to have two modes.
; In ``normal mode'', an error is reported only by the first receiver
; of a message.  In ``debug mode'', an inheritance traceback should be
; given whereby every object in an inheritance hierarchy will report
; when it fails to recognize a given message.  The following variable
; represents that mode.  (For simplicity, this object is hidden only
; by its name, which is unusual enough that it is unlikely to be
; trammeled by an application.  This is not the recommended technique
; for data hiding.  Data hiding ought to be implemented through the
; techniques shown in this file!  However, since this error handling
; part of the methods package is considered system programming,
; certain liberties in style are justifiable.  There are in fact, good
; technical reasons for the error handling code to be implemented with
; global variables, which the perceptive reader will be able to
; deduce.)

(define **method-mode** 'normal-method-mode)

; The user can set these modes as follows.

(define (set-debug-method-mode)
  (set! **method-mode** 'debug-method-mode))

(define (set-normal-method-mode)
  (set! **method-mode** 'normal-method-mode))

(define (reset-debug-method-mode)  ;;; synonym
  (set! **method-mode** 'normal-method-mode))

; and test them with the following routine:

(define (test-debug-method-mode)
  (eq? **method-mode** 'debug-method-mode))

; Before presenting the examples of classes and objects, some helper
; routines are needed.
;
; When an object cannot recognize a message, and none of its ancestor
; objects can recognize it, the object creates an error procedure and
; returns it as the result of the message dispatcher.  

(define **method-error-class-name** "No class name.")

(define **method-error-message** 'no-message)

(define (error-method . junk-args)
  (display **method-error-class-name**)
  (display ": uknown message: '")
  (display **method-error-message**)
  (newline)
  ())

(define (make-error-method class-name msg)
  (set! **method-error-class-name** class-name)
  (set! **method-error-message** msg)
  error-method)

; The procedure that walks the inheritance hierarchy must cooperate
; in the error handling.  

(define (search-supertypes supers msg)
  (define method ())
  (if (test-debug-method-mode)
      (begin
       (display "Searching...")
       (newline)))
  (cond
   (  (null? supers)  ()  )
   (  (begin
       (set! method ((car supers) msg))
       (eq? method error-method))
                      (if (test-debug-method-mode)
                          (error-method))
                      (search-supertypes (cdr supers) msg)  )
   (  else  method  )))

; This procedure implements the inheritance of methods.  It is greatly
; complicated by proper error handling.  Without error handling, the
; routine would resemble the following, which is much easier to
; understand (without error handling, the programming convention is
; that an object that does not understand a message returns the
; unexecutable method ``()'').
;
; (define (search-supertypes supers msg)
;   (cond
;     (  (null? supers)  ()  )
;     (  ((car supers) msg)  )
;     (  else  (search-supertypes (cdr supers) msg)  )))
;
; The actual routine, with proper error handling, works as follows.  A
; local variable, ``method'', is defined.  Its value is not important
; to begin with.  If debugging is on, we print a message telling the
; user that the inheritance hierarchy is being searched.  Then, the
; list of supertypes is investigated.  If the list is empty, we return
; nil, which signals the caller to create and return the error-method,
; as we shall see in the examples later.  If the list is not empty, we
; pass the message to the first supertype in the list.  The return
; value is assigned to the local variable ``method''.  If the returned
; method is the one and only global error-method, then the supertype,
; and, recursively, all its supertypes, did not know the message.  
; If debugging is on, we execute the returned error-method, contributing
; to the aforementioned inheritance traceback.  Finally, we return 
; the value of a recursive call of search-supertypes on the remainder 
; of the list of supertypes.  If the returned method is not the 
; error-method, then the supertype did understand the message after 
; all somewhere in the hierarchy, and the returned method is the
; return value of this procedure.
;
; Note that the list of supertypes is searched in order from front
; to back.  The first match of a message results in the successful
; finding of a method.  The order of supertypes in the list is 
; significant only when more than one supertype can understand
; a given message.  The earlier members of the list will shadow
; the later ones.  In some object-oriented programming systems, one
; refers to the ``overriding'' of methods.  The shadowing in 
; ``methods'' is our form of method overriding, and it is under
; explicit control of the programmer who sets the order of supertypes
; in the list of supertypes.  
; 
; In summary, search-supertypes passes the message to the ancestors,
; in pre-order, returning the first method found.  
;
; The next helper routine passes a message, and a variable number of
; arguments, to all the parents of an object.  For side effects, it
; executes any methods found.  Parents are defined as 
; first level ancestors.

(define (for-all-parents supers msg . args)
  (let (  (method-list
           (map (lambda (supertype) (supertype msg)) supers))
          (for-proc
           (lambda (method) (apply method args)))  )
    (for-each for-proc method-list)))

; With the current programming convention, it is not possible to pass
; a message to all ancestors and execute the methods for side-effect
; without explicit cooperation on the part of the objects involved. In
; other words, the procedure ``for-all-ancestors'', analogous to
; ``for-all-parents'', cannot be implemented in the current version of
; the methods package.  The reason is that the convention calls for
; every class to call ``search-supertypes'', which stops when it finds
; a method.  The convention would have to be augmented so that objects
; would call ``find-all-methods'' (defined below) on an appropriate
; message.  Since we expect the need for ``for-all-ancestors'' to be
; fairly rare, the necessary changes to the methods package will be
; reserved for a future version.

(define (find-all-methods supers msg)
  (cond
   (  (null? supers)  ()  )
   (  else  (cons ((car supers) msg)
                  (find-all-methods (cdr supers) msg))  )))

; EXAMPLES (cut here to end of file to throw examples away)
;
; Our first example class, or object type, is ``parent'', represented
; by the following constructor procedure.

(define (new-parent arg)
  (let ((state-var (* arg arg))
        (supers ()))
    
    (define (report-state-var)
      (display state-var)
      (newline)
      state-var)
    
    (define (update-state-var arg)
      (set! state-var (* arg arg)))
    
    (define (echo arg)
      (display arg) (newline))
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)  report-state-var  )
       (  (eq? msg 'update)  update-state-var  )
       (  (eq? msg 'echo)    echo  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Parent" msg)  )))
    
    self))

; This class, or constructor procedure, completely illustrates, by
; example, the programming convention of the ``methods'' technique.  
; The constructor takes a single argument, whose square it stores in a
; local state variable.  Another state variable, the list of
; supertypes, is set to nil, since this class is at the root of an
; inheritance hierarchy.  Three methods are defined, one that reports
; and returns the current value of the state variable, one that sets
; the state variable equal to a new square, and one that merely echoes
; its argument.  A method dispatching procedure, conventionally named
; ``self'', tests a given message against three symbols and returns
; the corresponding method if a match is found.  If no match is found,
; the list of supertypes is searched for a match.  In the case of this
; class, ``parent'', the search is purely formal, to illustrate how it
; should be done, since ``parent'' has no ancestors.  However, if a
; match were found among the list of supertypes, the method would be
; returned.  Note how the search relys on the fact that any non-nil
; result is treated as a successful ``cond'' clause, terminating the
; ``cond'' statement. Search-supertypes returns nil only when a match
; is not found.  Finally, if no match is found locally or among the
; supertypes, an appropriate error-method is pseudo-created and
; returned.
; 
; We now test this class by making an instance and passing it
; messages.

(define p (new-parent 42))

((p 'report))

((p 'update) 69)

((p 'report))

((p 'echo) (list 1 2 3))

; We test error handling:

((p 'bogus))

(set-debug-method-mode)

((p 'bogus))

(reset-debug-method-mode)

((p 'bogus) 'here 'are 'some 'junk 'arguments)

; Continuing this example, let us define a child class inheriting
; all attributes and methods of the parent.  Note the attributes of
; the parent are only accessible through the parent's method
; discipline.  This is a strict form of inheritance, and the default
; in C++, for example.  (C++ allows the programmer to override 
; ancestors' access discipline, at his own peril.)

(define (new-child arg1 arg2)
  
  (let* (  (leg1 (* arg1 arg1))
           (leg2 (* arg2 arg2))
           (hypotenuse (+ leg1 leg2))
           (supers (list
                    (new-parent hypotenuse)))  )
    
    (define (report)
      (for-all-parents supers 'report)
      (display "Leg1 = ") (display (sqrt leg1)) (newline)
      (display "Leg2 = ") (display (sqrt leg2)) (newline)
      (display "Hypo = ") (display (sqrt hypotenuse)) (newline))
    
    (define (update-leg1 val)
      (set! leg1 (* val val))
      (set! hypotenuse (+ leg1 leg2)))
    
    (define (update-leg2 val)
      (set! leg2 (* val val))
      (set! hypotenuse (+ leg1 leg2)))
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)       report       )
       (  (eq? msg 'update-leg1)  update-leg1  )
       (  (eq? msg 'update-leg2)  update-leg2  )
       (  (search-supertypes supers msg)       )
       (  else  (make-error-method "Child" msg)       )))
    
    self))

; We now test the child type.

(define c (new-child 3 4))

((c 'report))  ;;; passes message to all parents

((c 'update-leg1) 5)

((c 'update-leg2) 12)

((c 'report))

((c 'echo) '(foo bar))   ;;; msg known only in the parent

((c 'bogus) 'baz 'rat)

(set-debug-method-mode)

((c 'bogus) 'baz 'rat)

(reset-debug-method-mode)

((c 'bogus) 'baz 'rat)

; The last example, presented without detailed narrative, shows a 
; slightly deeper inheritance hierarchy.  The leaf is a type named
; ``daughter''.  Its two parent classes are ``mother'' and ``father''.  
; In turn, every mother has an ``estate'' and a ``religion'' (please
; excuse the somewhat strained metaphor of inheritance; this is just
; a little example).  

(define (new-estate value)
  (let ((value value)
        (supers ()))
    
    (define (report)
      (display "Estate = $") (display value) (newline))
    
    (define (what-value) value)
    
    (define (increase amount) (set! value (+ value amount)))
    
    (define (decrease amount) (set! value (- value amount)))
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)       report  )
       (  (eq? msg 'what-estate)  what-value  )
       (  (eq? msg 'increase)     increase  )
       (  (eq? msg 'decrease)     decrease  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Estate" msg)  )))
    
    self))

(define (new-religion theReligion)
  (let ((religion theReligion)
        (supers ()))
    
    (define (report) (display "Religion = ") (display religion) (newline))
    
    (define (what-religion) religion)
    
    (define (convert theNewReligion) (set! religion theNewReligion))
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)         report  )
       (  (eq? msg 'convert)        convert  )
       (  (eq? msg 'what-religion)  what-religion  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Religion" msg)  )))
    
    self))

(define (new-father eye-color)
  (let ((eye-color eye-color)
        (supers ()))
    
    (define (report) (display "Father's eye color = ")
      (display eye-color) (newline))
    
    (define (what-eye-color) eye-color)
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)          report  )
       (  (eq? msg 'what-eye-color)  what-eye-color  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Father" msg)  )))
    
    self))

(define (new-mother eye-color estate religion)
  (let ((eye-color eye-color)
        (supers (list
                 (new-estate estate)
                 (new-religion religion))))
    
    (define (report)
      (for-all-parents supers 'report)
      (display "Mother's eye color = ")
      (display eye-color) (newline))
    
    (define (what-eye-color) eye-color)
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)          report  )
       (  (eq? msg 'what-eye-color)  what-eye-color  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Mother" msg)  )))
    
    self))

(define (new-daughter eye-color)
  (let* ((eye-color eye-color)
         (parents-eye-color
          (if (eq? eye-color 'blue)  'blue  'brown))
         (supers (list
                  (new-father parents-eye-color)
                  (new-mother parents-eye-color 500000 'Jewish))))
    
    (define (report)
      (for-all-parents supers 'report)
      (display "Daughter's eye color = ")
      (display eye-color)
      (newline))
    
    (define (what-eye-color) eye-color)
    
    (define (self msg)
      (cond
       (  (eq? msg 'report)          report  )
       (  (eq? msg 'what-eye-color)  what-eye-color  )
       (  (search-supertypes supers msg)  )
       (  else  (make-error-method "Daughter" msg)  )))
    
    self))

(define dbl (new-daughter 'blue))

((dbl 'report))

((dbl 'convert) 'muslim)

((dbl 'report))

((dbl 'increase) 50000)

((dbl 'report))

(define dbr (new-daughter 'brown))

((dbr 'report))

((dbr 'decrease) 250000)

((dbr 'report))

((dbr 'bogus))

(set-debug-method-mode)

((dbr 'bogus))

(reset-debug-method-mode)

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

End of Scheme Digest
********************

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

Date: 6 Jul 89 21:33:25 GMT
From: Brian of ASTD-CP <brian@topaz.rutgers.edu>
Subject: Looking for MIT C-scheme manual
Message-Id: <1415@jato.Jpl.Nasa.Gov>


    We here in the Computer Graphics Lab have MIT cscheme running
    and we have the R3RS to look at.  But cscheme has a tremendous
    number of features, extensions, and goodies that we haven't
    figured out.  Is there a reference manual?  A user's manual? 

    If someone has it, would s/he be so kind as to e-mail (or even
    US snail) it to us?  We're limping along with MacScheme and
    various installations of Betz's Xscheme, which, while very nice
    indeed, doesn't seem to have the power, backing, (nor size) of
    cscheme by an order of magnitude or so.

;================================================================
;| Brian Beckman                  | brian@topaz.jpl.nasa.gov    |
;| Computer Graphics Laboratory   | (818) 397-9207              |
;| Mail Stop 510-202              | (818) 397-9344              |
;| Jet Propulsion Laboratory      |                             |
;| Pasadena, CA 91109             | 6 July 1989                 |
;================================================================

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

End of Scheme Digest
********************

∂07-Jul-89  1700	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Re: Reserving a character for experimentation    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 7 Jul 89  17:00:31 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08503;
          7 Jul 89 19:54 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  7 Jul 89 19:51:08 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa08273; 7 Jul 89 19:36 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 07 JUL 89 16:29:22 PDT
Date: Fri, 07 Jul 89 16:31:25 PDT
From: Pavel.pa@xerox.com
Subject: Re: Reserving a character for experimentation
In-reply-to: <8907061359.AA00613@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
Reply-To: Pavel.pa@xerox.com
Message-ID: <890707-162922-12108@Xerox>

It is indeed the case that, were we to agree to remove colon from the list
of allowed characters in identifiers, some now portable code would become
unportable.  This is not a new concept.  For example, we recently agreed to
de-specify the truth value of the empty list; a far, far more subtle way to
break previously portable code.

The argument must be that there is no consensus for making this particular
incompatible change to the language; that is, as a group, we must not
believe that the benefits of making colon available for experiementation
outweigh the costs of rendering some code unportable.

I do not agree with this view, obviously, but I value the consensus model
of decision.  Thus, absent any signs of support other than from Alan
(thanks), I will withdraw yet another proposal.  In so doing, though, I
would like to make two requests to the authors as a group:

1 -- Please don't change the language to allow ``#'' in identifiers; it has
been hard enough to find an acceptable character this once and I'd rather
not have to go through it again.

2 -- Over the past few weeks, I have watched no fewer than seven ideas
proposed to this mailing list.  By my count, that number exceeds the number
of people stating opinions on those ideas.  It is very difficult to attempt
to achieve a consensus among a large group if the vast majority are silent.
What are we to assume about those who say nothing?  That they approve of
what is being said?  By whom?  That, perhaps, they care nothing about the
ideas being discussed and thus have no interest in how they are resolved?
I hope not.

In a recent message, Jinx noted the following:

``I'm afraid we are going to disagree very strongly on this issue, and
therefore we are at an impasse.  Unfortunately that seems to be happening
with everything else that anyone proposes, so I'm afraid that R3.95RS is
the end of the line.  What a pity.''

A pity indeed, if it means that Scheme will not evolve into a usable
standard language.  If we ever hope for wider use of this language, we must
work harder to resolve differences and, critically, MOVE FORWARD.  That
requires work, attention, and above all, participation.

End of sermon/supplication.

	Pavel

∂07-Jul-89  1740	@mc.lcs.mit.edu,@ti.com:bartley@m2.csc.ti.com 	Responses to a month of mail
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 7 Jul 89  17:40:28 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09099;
          7 Jul 89 20:36 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  7 Jul 89 20:33:16 EDT
Received: from TI.COM by mintaka.lcs.mit.edu id aa09044; 7 Jul 89 20:30 EDT
Received: by ti.com id AA28102; Fri, 7 Jul 89 19:30:51 CDT
Received: from m2.csc.ti.com.UUCP by tilde id AA29680; Fri, 7 Jul 89 14:45:28 CDT
Received: by m2.csc.ti.com.UUCP (5.52/4.7)
	id AA11314; Fri, 7 Jul 89 14:45:25 CDT
Date: Fri, 7 Jul 89 14:45:25 CDT
From: David Bartley <bartley@m2.csc.ti.com>
Message-Id: <8907071945.AA11314@m2.csc.ti.com.UUCP>
To: JMiller%crl.dec@decwrl.dec.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Wed, 5 Jul 89 16:53:13 EDT <8907052053.AA00249@peanut.DEC.COM>
Subject: Responses to a month of mail
Reply-To: Bartley@ti-csl.csc.ti.com

>From: jmiller@crl.dec.com
>
>I'd like to suggest that Pavel use "|" instead of ":" for his module
>separator.  It's currently illegal, and I believe that his argument
>against its use (other dialects use it for an escape character) is
>very weak.  It also looks pretty good for just this purpose:
>
>(module|submodule|procedure random-thing)
>
>--Jim

At least four of our implementations of Scheme use "|" the same way
Common Lisp uses it: to make funny characters seem alphabetic in
symbol names.  I would also expect this to be true of other Scheme's
out there that are piggy-backed on top of other Lisps.  This could
work against Pavel's module mechanism spreading to those systems.

On the other hand, I kind of like the looks of your example.  Suppose
we used paired "||" instead?  It seems to me that there would be no
conflict between the two uses of "|" (except perhaps readability).

(module||submodule||procedure random-thing)

--db--


∂08-Jul-89  1717	@mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu 	Fluid binding   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Jul 89  17:17:28 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03309;
          8 Jul 89 20:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Jul 89 19:11:24 EDT
Received: from sonoma.Stanford.EDU by mintaka.lcs.mit.edu id aa02588;
          8 Jul 89 19:09 EDT
Received: by sonoma.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA00432; Sat, 8 Jul 89 16:09:33 PDT
Message-Id: <8907082309.AA00432@sonoma.Stanford.EDU>
Received: from annabel.STANFORD.EDU by dolores; Sat, 8 Jul 89 16:10:19 pdt
Received: by sid; Sat, 8 Jul 89 14:03:02 pdt
Date: Sat, 8 Jul 89 14:03:02 pdt
From: "Jonathan S. Shapiro" <shap@annabel.stanford.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 21:05:31 PDT <890705-210534-7725@Xerox>
Subject: Fluid binding

Several comments:

This is syntactically gross. The presence of FLUID-REF in effect
separates things into two namespaces, which is awful.  I also don't
like the fact that FLUID-LET evaluates its variables.

People may not like it, but I think this wouldbe better handled as
follows:

	(DEFINE FRED)
	(DECLARE FRED 'fluid)

LET continues to work as you expect, but when applied to a fluid
variable does a fluid-let.  Within the context of such a fluid-let, as
set! behaves in the way one expects.

I fail to see why we need any additional syntax to accomplish this.
Perhaps someone can enlighten me.

∂08-Jul-89  1732	@mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu 	Assignment to standard variables    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Jul 89  17:32:14 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03421;
          8 Jul 89 20:20 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Jul 89 19:11:32 EDT
Received: from sonoma.Stanford.EDU by mintaka.lcs.mit.edu id aa02590;
          8 Jul 89 19:09 EDT
Received: by sonoma.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA00436; Sat, 8 Jul 89 16:09:35 PDT
Message-Id: <8907082309.AA00436@sonoma.Stanford.EDU>
Received: from annabel.STANFORD.EDU by dolores; Sat, 8 Jul 89 16:10:23 pdt
Received: by sid; Sat, 8 Jul 89 13:56:43 pdt
Date: Sat, 8 Jul 89 13:56:43 pdt
From: "Jonathan S. Shapiro" <shap@annabel.stanford.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 05 Jul 89 20:04:36 PDT <890705-200443-7674@Xerox>
Subject: Assignment to standard variables

I think pavel has missed several points.

Regarding being unable to rebind `if', `or', `delay', etc. There is a
distinction to be made between symbols that are syntax and symbols
that are functions.  One of the beauties of scheme is that the set of
identifiers that is reserved is very small.  It is also unlikely to
change very much.  This makes the syntactic keywords rather different
from the standard functions that are part of the environment.  There
is less risk of incompatible extension, and there are strong
experiential arguments (e.g. Algol) for not having syntactic keywords
be assignable.  Indeed, making things like IF assignable would
introduce a fundamental ambiguity into the language.

Lexical scoping is insufficient to get around this problem, partly
because of the define semantics issue.  It is not the case that I can
take a randomchunk of code and stick it inside a LETREC somewhere and
have things remain consistent.  In particular, the following two code
fragments are not identical.  One is an error:

	(DEFINE foo 3)		(let ()
	(SET! foo 4)		  (DEFINE foo 3)
	(DEFINE bar 5)		  (SET! foo 4)
				  (DEFINE bar 5))

What is needed here is environments, and the only thing that we all
seem to be able to agree on with regard to environments is that we
disagree strongly on what they should be like.

The requirement of a clean syntactic mode doesn't get you out of the
incompatibility problem, unless I have misunderstood the intent of
R3.95RS in this regard.  The clean environment prohibits extensions to
the standard-described language, yes.  It doesn't, however, prohibit
changes to the standad.  In R5RS the standard might change in a way
that breaks existing programs if we adopt your proposal.  This should
be avoided if possible.

I also believe that your interpretation of "it is an error" is wrong.
When we state that behavior is unspecified, we mean that it is is
unspecified.  When we state that something is an error, we mean that
it is a wrong thing to do, not that it is unspecified.  The fact that
implementations are permitted to be lazy is not a good rationale for
destroying the meaning of "it is an error."

Frankly, I think that the idea of creating a DECLARE form makes the
most sense of all.  It would let the decision of immutability be left
with the programmer without compromising any of Pavel's objectives.

In one regard, however, I agree with Pavel.  The transformation that
was proposed for environments is sufficiently verbose that it is a
pain in the ass to use, and I agree with him that it is undesirable.
I also agree that the right character to use, if any, is `:', for the
reasons he stated.

Jon

∂08-Jul-89  1751	@mc.lcs.mit.edu,@sonoma.stanford.edu:shap@annabel.stanford.edu 	Reserving a character for experimentation
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Jul 89  17:51:16 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03548;
          8 Jul 89 20:30 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Jul 89 19:22:31 EDT
Received: from sonoma.Stanford.EDU by mintaka.lcs.mit.edu id aa02611;
          8 Jul 89 19:11 EDT
Received: by sonoma.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA00428; Sat, 8 Jul 89 16:09:28 PDT
Message-Id: <8907082309.AA00428@sonoma.Stanford.EDU>
Received: from annabel.STANFORD.EDU by dolores; Sat, 8 Jul 89 16:10:16 pdt
Received: by sid; Sat, 8 Jul 89 14:07:15 pdt
Date: Sat, 8 Jul 89 14:07:15 pdt
From: "Jonathan S. Shapiro" <shap@annabel.stanford.edu>
To: JMiller@crl.enet.dec.com
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Thu, 6 Jul 89 09:59:48 EDT <8907061359.AA00613@peanut.DEC.COM>
Subject: Reserving a character for experimentation

> Perhaps what you meant is that no individual's code running
> in an existing implementation would be affected -- but I'm more
> worried about the portable code I've written over the years.  I'd like
> it to remain portable, and your suggesting one more headache to worry
> about.

I don't find this argument particularly compelling, given that the
program to transform colon-using code to non-colon-using-code is so
short.

Jon

∂08-Jul-89  2224	@mc.lcs.mit.edu:jinx@ZURICH.ai.mit.edu 	Fluid binding  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 8 Jul 89  22:24:08 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06119;
          9 Jul 89 1:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  9 Jul 89 00:55:14 EDT
Received: from [18.43.0.171] by mintaka.lcs.mit.edu id aa05972;
          9 Jul 89 0:53 EDT
Return-Path: <jinx@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Sun, 9 Jul 89 00:50:33 edt
Date: Sun, 9 Jul 89 00:50:33 edt
From: "Guillermo J. Rozas" <jinx@ZURICH.ai.mit.edu>
Message-Id: <8907090450.AA01092@ZURICH.AI.MIT.EDU>
To: shap@annabel.stanford.edu
Cc: Pavel.pa@xerox.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: "Jonathan S. Shapiro"'s message of Sat, 8 Jul 89 14:03:02 pdt <8907082309.AA00432@sonoma.Stanford.EDU>
Subject: Fluid binding


    This is syntactically gross. The presence of FLUID-REF in effect
    separates things into two namespaces, which is awful.  I also don't
    like the fact that FLUID-LET evaluates its variables.

The only syntax in Pavel's proposal is FLUID-LET, the others are
procedures.  His proposal does not introduce another namespace.
Instead of adding a new kind of environment or variable, he makes
fluids first class objects whose contents are context sensitive.
The name fluid is loaded, think of them as cells (pairs with only one
component).

    People may not like it, but I think this wouldbe better handled as
    follows:

	    (DEFINE FRED)
	    (DECLARE FRED 'fluid)

    LET continues to work as you expect, but when applied to a fluid
    variable does a fluid-let.  Within the context of such a fluid-let, as
    set! behaves in the way one expects.

This is virtually impossible to implement correctly in the presence of
separate compilation.  The only way to get this to work would be to
make the assumption that all free variables are special (I mean fluid,
sorry), which is what Common Lisp does.

    I fail to see why we need any additional syntax to accomplish this.
    Perhaps someone can enlighten me.

Pavel's proposal does not require syntax, since FLUID-LET can be
replaced by a procedure as I suggested in a previous message.  On the
other hand, FLUID-LET would be the most common way of using fluids,
and the procedures would hardly ever be used directly.

∂09-Jul-89  2121	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #155 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 9 Jul 89  21:21:42 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01550;
          10 Jul 89 0:19 EDT
Date: 10 JUL 89  00:09:37 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #155 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907100019.aa01550@mintaka.lcs.mit.edu>

Scheme Digest #155                             10 JUL 89  00:09:37 EDT

Today's Topics:

        Learning/teaching Scheme as a first language - Summary

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

Date: 7 Jul 89 15:59:06 GMT
From: Dave McKellar <mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!intacc!mckellar@ohio-state.arpa>
Subject: Learning/teaching Scheme as a first language - Summary
Message-Id: <1989Jul7.115906.7544@intacc.uucp>



Many thanks to the 16 kind people who replied to my query about
an easy reading book on Scheme.  Here is what they said...


Easy Reading Books on Scheme
============================

The Little Lisper  by Daniel P. Friedman and Matthias Felleisan
-----------------  of Indiana University

Programming in Scheme  by Mike Eisenberg
---------------------  published by Scientific Press

The Scheme Programming Language  by Kent Dybvig
-------------------------------  published by Prentice Hall

Introduction to Scheme  by Jerry Smith
----------------------   published by Prentice Hall


The 'World's biggest bookstore', here in Toronto, has a shelf of Lisp
books but none of these.... shocking!
-- 
----------
{uunet,watmath,utzoo}!mnetor!intacc!mckellar    "Taste is a matter of taste."
----------

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

End of Scheme Digest
********************

∂10-Jul-89  1447	@MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	R↑3.95RS: open-input-file open-output-file   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 10 Jul 89  14:47:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25367;
          10 Jul 89 17:13 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 10 Jul 89 17:10:36 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 233698; Mon 10-Jul-89 17:09:51 EDT
Date: Mon, 10 Jul 89 17:09 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: R↑3.95RS: open-input-file open-output-file
To: JMiller@crl.enet.dec.com, rrrs-authors@MC.lcs.mit.edu
In-Reply-To: <8907052107.AA00259@peanut.DEC.COM>
Message-ID: <19890710210947.5.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Wed, 5 Jul 89 17:07:22 EDT
    From: jmiller@crl.dec.com
    At the risk of opening an entire can of worms, what about passing an
    optional flag in to OPEN-... specifying (if present and EQ? to #T)
    that a return value of #F is valid....

The Lisp Machine system's OPEN used to do something like this.  If you gave
it the right flag as an optional argument, OPEN would either return a open
stream, or an "error object" that described why the file couldn't be
opened.  This style of programming turned out to be very clumsy and error
prone.  Once you start returning streams and error objects from the same
function, the next step is to store them both in the same variables.  Then
you've got them in the same slots in data structures.  Passing an error
object to an I/O primitive as a stream becomes a common path into the
debugger.  Also other functions that return streams might want to return
error objects as well, so then they need to support the same optional flag
argument.

The condition system that replaced this style of OPEN was an immeasurable
improvement.

∂10-Jul-89  2055	@mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com 	LIST-REF, revisited   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 10 Jul 89  20:55:50 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28793;
          10 Jul 89 20:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Jul 89 16:35:22 EDT
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa23490;
          10 Jul 89 16:30 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	id AA02002; Mon, 10 Jul 89 13:29:53 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	for rrrs-authors@mc.lcs.mit.edu; id AA02002; Mon, 10 Jul 89 13:29:53 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
	id AA12173; Mon, 10 Jul 89 13:44:02 EDT
Date: Mon, 10 Jul 89 13:40:41 EDT
From: jmiller@crl.dec.com
Message-Id: <8907101740.AA02171@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: LIST-REF, revisited
Reply-To: JMiller@crl.enet.dec.com

At the recent IEEE Working Group meeting it was proposed that we again
respectfully request the Authors to consider the inclusion of the
procedure LIST-REF.  The argument is fundamentally to provide parallel
constructs for strings, lists, and vectors.  The Authors have already
adopted the addition of STRING to aid in this effort.  It was the
consensus of the meeting that the omission of LIST-REF from the IEEE
Draft Standard was undesirable, while the omission of LIST-TAIL was
acceptable since no similar procedure exists for the other data types.

Can we reach consensus on this one procedure?

--Jim Miller

P.S. -- I (personally, as opposed to the IEEE WG meeting) urge the
Authors to carefully re-read Morry Katz's initial proposal for
regularizing the data types.  Perhaps Morry can find a copy of his
earlier message, reconsider it, and resubmit it for comments.  I don't
believe that it can be acted on in time for the IEEE Draft, but
certainly R5RS is an appropriate vehicle for these considerations.

∂11-Jul-89  0857	@mc.lcs.mit.edu,@ZURICH.ai.mit.edu:ramsdell@linus.mitre.org 	International character sets.
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89  08:57:11 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07559;
          11 Jul 89 9:33 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 09:28:39 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa07464;
          11 Jul 89 9:23 EDT
Received: from mbunix.mitre.org ([129.83.20.100]) by ZURICH.AI.MIT.EDU; Tue, 11 Jul 89 09:20:24 edt
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA07932; Tue, 11 Jul 89 09:19:43 EDT
Posted-Date: Tue, 11 Jul 89 09:19:37 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA00208; Tue, 11 Jul 89 09:19:37 EDT
Date: Tue, 11 Jul 89 09:19:37 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907111319.AA00208@huxley.mitre.org>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: International character sets.
Reply-To: ramsdell@mitre.org

Here is a more specific proposal on international character sets.

Add the following sentence to the begining of paragraph -2, column 2,
page 4, which descibes when upper and lower case letters are
destinguished.  

	Implementations are encouraged to support at least
	the ISO Latin 1 (ISO8859-1) character set.

John

PS. On the internationalization of Eiffel

From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.eiffel
Date: 8 Jul 89 20:40:27 GMT
Organization: Enea Data AB, Sweden

In one of his many interesting articles Bertrand Meyer said if one 
wants changes in Eiffel the next six months is the time to ask for 
them. Since I think Eiffel has to be improved with regards to supporting 
human langauges other English, I will try to summarize the potential 
problem areas I'm aware of. I'm not an expert in neither Eiffel nor 
character-set standards, so I will not try to provide complete solutions, 
but merely point out the requirements.
  Before I go any further, let me add that these problems are in no
way unique to Eiffel. Since some time ISO requires support of multi- 
national character sets when they are approving or revising a
language standard. The problems connected with this vary from langauge
to langauge, as do the solutions. 
  I first give an overview of existing character sets. I then discuss
the various problem areas: Operator and delimiter characters, literals, 
identifiers and finally operations as comparisons.
!
Standardized character sets
---------------------------
There are several character-set standards, which I briefly describe
since not everyone may be well acquinted with them.
ASCII     - The standard on which about everything else is based. 
EBCDIC    - Appears in some worlds, but none I have experience of.
ISO 646   - A seven-bit standard, where some characters in the ASCII
	    are replaced by national characters. Which are the replace-
	    ments depends on the country you're in. For instance in 
	    Sweden left brace is replaced with dotted "a", in France  
	    it's an "e" with accent aigue.
ISO 2022  - A standard that describe how to change between different
	    character sets.
ISO 6937  - A eight-bit set, which doesn't seem to have been adopted 
	    very much. Slots 0-127 are ASCII. From 161 and up are mute 
	    modifiers and national letters. With 6937 dotted "a" is 
	    produced by first given a diaresis and then the "a". 
	    Virtually all langauges with a Latin alphabet, except 
	    Vietnamese, could be written with this set.     
ISO 8859  - Nine standards which all have ASCII in 0-127 and control 
	    characters in 128-159. Then the contents varies depends on 
	    the geographical are addressed. Five of the sets has Latin 
	    characters, then there's one each for Cyrillic, Hebrew, Arabic 
	    and Greek. I don't know whether all nine has finally been 
	    settled. Some may still be drafts.
	      One could expect that the absolutely most commonly supported
	    will be 8859/1, also known as Latin-1. Latin-1 covers most 
	    of the languages in Western Europe. (Exlcuded are Welsh and 
	    Catalan.)
	      8859 has no mute characters.
ISO 10646 - A multi-octet character set, which is under development. 
	    I know very little of it, but I doubt there is even a 
	    draft of it. There was a posting about it in comp.std.internat 
	    some time ago.
In the following I will conentrate on ISO 646 and 8859. Although I
personally am appealed by the ideas in 6937, its use in real life
is small, so I'm disregarding the problems that supporting this standard
would cause.                                                     
!            
Operator and delimiter characters
---------------------------------
With an eight-bit set based on ASCII there are rarely any problem. 
However, in a seven-bit world there are. Any programming language using 
any of the characters @[\]↑`{|}~ as an operator or a delimiter is 
committing a crime in my eyes. Most of the national sets that ISO 646 
defines replaces these characters with national characters, and in many 
cases these characters are letters. So in my eyes a notation like 
   class BIN_TREE [T]
is just as bad as:
   class BIN_TREE ZTQ
(Read Z and Q as opening and closing delimiters!) 
  Many languages that use these characters alleviates the problem
by providing alternative tokens. For instance, Ada allows you use "!"
for "|". Many Pascal compilers allow "(." and ".)" for [], and (* and
*) are more common than {}.
  Eiffel is a sinner in this field. With Dr. Meyer's origin in mind, 
I assume he is not unaware of the problems, but has chosen to ignore 
them. Still I hope he will re-think and change his mind on this issue. 
Letters as special characters is simply not a good idea. 
  One could argue that since we're moving into a eight-bit world,
this is a disappearing problem, but remember that that transition
is slow. We will live with seven-bits terminals and printers quite
a long time still.

Now, what actual problems do we have in Eiffel? The occurance of brackets 
and braces in Eiffel is restricted to the class declaration and the export 
clause which gives less pain than if they could occur anywhere. Anyway, 
finding replacement characters should be easy. (To be honest I don't 
really see why they had been chosen in the first place. Is there some 
lexical problem that prevents simple parenthesis?)
  Worse is the backslash. Could you think of having to double all "W"s 
in your string literals? Probably not, so you wouldn't pick "W" as 
the escape character. Eiffel has chosen the bad habit from C of using          
dotted "O" (which is how the backslash appears on my screen). Here 
I not only want an alternate character, but also I want to get rid 
of the original. (As a whole, I am not fond of the C style of writing 
character and string literals, why use octal codes?)
!                  
Literals
--------
Which characters can I use in string and character literals? If        
we forget the fatal backslash, Eiffel doesn't give me any problem 
if I'm using any of the 8859 standards. It is just to go ahead and 
use them. (At least that is what its description alludes. For what 
happens in real life, see an adjacent article of mine.)
  Other people will get problems, though, mainly Japanse and Chinese  
programmers. I.e., there is no support for multi-byte sets.
  As a side note, a language which really is evil here is Ada. Ada
explictly forbids non-printing charcaters in literals, and "non-
printing" is defined from ASCII, so using the upper half of Latin-1 
in Ada is a real pain. Ada-9X will resolve this, but that's another 
three or four years from now. Sigh. 
!
Identifiers
-----------
Eiffel, as most other langauges, allows the letters in the English
alphabet in identifiers. However, if you're writing code in your native 
langauge, you may need to use other letters as well. To be able to  
use the replacement characters in ISO 646 would be nice, but it would
be pointless to require that.
  But with eight-bit sets in 8859, it is a fair requirement that all 
letters in these sets also are permitted in identifier names. 
  The problem lies in the difference between the sets. In Latin-1 
161-191 are punctuation characters which you normally wouldn't think of 
in identifier names. 192-255 are letters, with 32 as difference between 
lower and upper case. (A few exceptions which I disregard here for 
brevity.)
  In the other Latin sets, some characters in the range 161-191 are 
also letters, with 16 as the case difference. 
  How the non-Latin sets look like I don't know.
  One could make this a very simple issue and just take Latin-1, with 
the motivation that is what will be used in the known world of computing.
However, I think this would be fatal mistake. Should our friends in
Hungary, Russia and Greece be handicapped in the selection of
identifier characters? Do we know that "the known world of computing"
will forever restrict itself to to places were Western European 
langauges are spoken?
  Now then, how to support mulitple sets? An idea would be to have a 
directive that said which character set the source code was written with. 
We must of course immediately discard the idea, since this is impossible 
in a modular langauge like Eiffel. (What if we want to inherit that 
Latin-2 class in our Latin-1 class?)                            
  As far as I can see the only way to go is to allow all characters
>= 161 and then use the 32 and 16 differences for case folding. (A
case significant language like C or Modula-2 has some advantage here.) 
!
Operations         
----------
When comparing two strings the collating sequence often has little
relevance with the alphabet. The only languages I know it works for 
using ISO 646 are English, Danish, Norwegian and maybe Dutch. As a 
whole one should remember that the character type in this sense is 
not a simple enumerate. In many languages you only take regard to
accents and umlauts when no other character is different. And some
langauges have pairs of letters that sorts as one. (E.g. "ch" in
Spanish, "rz" in Polish.)   
  What you need is a set of extended comparison routines, a set of
predefined langauges and a set of routines for loading your very
own sorting order. Eiffel is extremely well prepared in this area,
particulary with the additions of infix operators in 2.2. So all
that is needed is some additions to the class library. Of course
I could write them myself, but I think they should be in the 
standard library, since this is the way strings should be compared.
Using the collating sequence is a very artificial way to do it.
  Or, is library additions really all we need? If we define a class 
TRANSCRIPTED_STRING which codes a string to some internal format
for comparisons we would like to write:
    t_str : TRANSCRIPTED_STRING;
    ...
    t_str := "Some string";
But even if our new class is an heir of STRING, the assignment is
not permitted. And defining a TRANSCRIPTED_CHARACTER for single
elements as an heir to CHARACTER is out the question, since the
latter class is an expanded one and may not be inherited from.   
  One solution to these problems would of course be to inlcude
the required operations within STRING and CHARACTER. There are
probably some performance penalty for Americans who don't want
more than simple ASCII comparison, but it's certainly a solution
that looks very appealing.
  It should be added here, that there are various operating systems,
not the least in the Unix sphere, that supports handling of more
than one human language which includes run-time support for
comparisons. But they are often intended for C and Eiffel gives
room for much cleaner interfaces.

In this article I have discussed very little of multi-byte characters, 
since I have no experience of using them. However, they should not be 
forgotten when addressing these problems. They write programs in Japan 
too.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Bowlers on strike!


∂11-Jul-89  0951	@mc.lcs.mit.edu,@ZURICH.ai.mit.edu:mkatz@sesame.stanford.edu 	Regularization of list, vector, and string procedures
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89  09:51:34 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11726;
          11 Jul 89 12:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 12:21:14 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa11475;
          11 Jul 89 12:16 EDT
Return-Path: <mkatz@sesame.Stanford.EDU>
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by ZURICH.AI.MIT.EDU; Tue, 11 Jul 89 12:12:17 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA17846; Tue, 11 Jul 89 09:14:32 PDT
Date: Tue, 11 Jul 89 09:14:32 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907111614.AA17846@sesame.Stanford.EDU>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: Regularization of list, vector, and string procedures

At Jim Miller's request I am reposting a slightly cleaned up version of my
original proposal for regularization of the list, vector, and string procedures
in Scheme.

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

For those of you who don't remember, I was assigned the task at L&FP to
regularize the procedures involving lists, strings, and vectors for R4RS.
Initially, this looked like a trivial, noncontroversial task; but, it turns out
that there are actually some important semantic issues to be discussed.  I have
therefore decided to pass my ideas before the entire community, rather than
just sending them straight to the editors.  

I will begin this discussion with what I believe are the noncontroversial
changes and then proceed to the Controversial ones.  In order to better
understand the issues I have included the chart below which enumerates the
relevant procedures currently in R3RS.

LIST                STRING              VECTOR
----                ------              ------
list                                    vector
                    make-string         make-vector
                    string-fill         vector-fill
list-ref            string-ref          vector-ref
                    string-set!         vector-set!
                    string-copy
length              string-length       vector-length
append              string-append
append!
list->string        string->list        vector->list
list->vector
reverse
                    substring
                    string=?
                    string?             vector?
apply
map, foreach
memq, memv, member
assq, assv, assoc

Noncontroversial:
1)  Add string, make-list, list-fill, list-set!, list-copy, vector-copy,
    vector-append, string->vector, and vector->string with the obvious
    semantics. 
2)  Create aliases list-length and list-append for length and append,
    respectively. 
3)  Append! should NOT be generalized since most implementations (for good
    reasons) represent strings and vectors in a manner that is incompatible
    with append! semantics.
4)  Reverse should NOT be generalized since the extensions would be pretty much
    useless.  
5)  Sublist and subvector should be added because they are potentially useful
    and the implementations in scheme are much less efficient than ones which
    could be supplied by an implementor.
6)  String=? is only present for symetry with string-ci=? and should NOT be
    generalized to list=? and vector=? since we already have =?.

Controversial:
1)  Create list? which checks for a null terminated list.  This CAN be written
    by a user and is only marginally useful, but I believe it is important that
    it exist for symetry reasons.
2)  Generalize apply:
       (apply proc args)
       (apply proc arg1 arg2 ...  args)
    ARGS could be any of a list, string, or vector whose elements would be
    spread before the actual application was performed.

3)  There are several possibilities for map and foreach:
    a)  Status quo
    b)  Introduce list-map, string-map, vector-map, list-foreach,
        string-foreach, and vector-foreach.  List-map and list-foreach would be
        identical to the current map and foreach, respectively. The others
        would have the following syntaxes and semantics
    	    (string-map proc string1 string2 ...)
	    (vector-map proc vector1 vector2 ...)
   	    (string-foreach proc string1 string2 ...)
	    (vector-foreach proc vector1 vector2 ...)
	The string version would take strings as arguments and in the case of
        string-map would return a string.  The vector versions would do
        similarly.  It would be a type error to pass a string to list-map, a
        list to vector-map, etc.
    c)  The same 6 procedures would be introduced as in b).  In this case the
        name would specify the type of the return value.  The procedures would
        be polymorphic over arguments of type list, string, and vector.  All
        that would be required would be that the arguments all have the same
        length. 
    I am personally in favor of either b) or c).  I like the semantics of c),
    but realize that some members of the community may find this semantics
    objectionable.   
4)  Memq, memv, and member are quite problematic.  They could be extended to
    allow the second argument to be a vector in the obvious way, but then what
    should they return on a match.  Returning a subvector is unsatisfactory
    because the aliasing one gets with a sublist would undoubtedly not be
    present for a subvector, and thus the original structure could not be
    modified based on the result.  In my experience, this is one of the most
    common uses for these procedures and it would be negated.  Another
    alternative is just to return #t and #f.  However, this seems to be
    unintuitively incompatible with the original versions.  Extensions for
    strings are even worse, because the equivalence distinctions between eq,
    eqv, and equal are not present and have instead been replaced by case
    sensativity and insensitivity.  MY RECOMMENDATION IS TO MAKE NO EXTENSION.
5)  Any extensions to assq, assv, and assoc have similar problems to those of
    memq, etc. and I therefore again RECOMMEND NO EXTENSION.
6)  As a result of 5) and 6), I suggest adding two new families of procedures
    which for the sake of exposition I will call member? and match.  (I know
    these are horrible names, but if people like the idea, we'll worry about
    what to call them later.)  Their syntaxes would be as follows:
       (list-member? val pred list)
       (string-member? val pred string)
       (vector-member? val pred vector)
       (list-match val pred list)
       (string-match val pred string)
       (vector-match val pred string)
    The member procedures would return #f if (pred val (foo-ref foo i))
    returned #f for all i, where foo is either list, string, or vector.
    Otherwise, they would return #t.  The match procedures would perform
    similarly except that they would return the first element for which pred
    returned #t, #f otherwise.  A decision would have to be made for match as
    to whether each element of a vector would have to itself be a vector.
    Obviously, for strings each element would have to be a character and so
    this version would be somewhat useless.  As A RESULT, I propose that
    instead we introduce just the procedures member? and match which are
    polymorphic over all the reasonable types (i.e., strings, vectors, and
    lists).  For match, this polymorphism would extend 2 levels into the
    data structure.

-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂11-Jul-89  1100	@MC.lcs.mit.edu,@mojave.stanford.edu:shap@sid.stanford.edu 	Fluid binding  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89  11:00:01 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12852;
          11 Jul 89 13:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 13:36:59 EDT
Received: from Mojave.Stanford.EDU by mintaka.lcs.mit.edu id aa12788;
          11 Jul 89 13:32 EDT
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA04778; Tue, 11 Jul 89 10:29:52 PDT
Message-Id: <8907111729.AA04778@mojave.Stanford.EDU>
Received: by sid; Tue, 11 Jul 89 10:32:27 pdt
Date: Tue, 11 Jul 89 10:32:27 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: jinx@ZURICH.ai.mit.edu
Cc: Pavel.pa@xerox.com, rrrs-authors@MC.lcs.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Sun, 9 Jul 89 00:50:33 edt <8907090450.AA01092@ZURICH.AI.MIT.EDU>
Subject: Fluid binding

Points well taken.  Thanks jinx.

My qualm about the proposal sent out boils down to the fact that it
seems like it would be cumbersome to use, but since I don't have a
better idea, I withdraw my objections.

Jon

∂11-Jul-89  1105	@MC.lcs.mit.edu,@ZURICH.ai.mit.edu:shap@sid.stanford.edu 	International character sets.   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89  11:05:39 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12943;
          11 Jul 89 13:49 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 13:24:27 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa12619;
          11 Jul 89 13:21 EDT
Return-Path: <shap@sid.STANFORD.EDU>
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by ZURICH.AI.MIT.EDU; Tue, 11 Jul 89 13:18:36 edt
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA04739; Tue, 11 Jul 89 10:18:38 PDT
Message-Id: <8907111718.AA04739@mojave.Stanford.EDU>
Received: by sid; Tue, 11 Jul 89 10:21:13 pdt
Date: Tue, 11 Jul 89 10:21:13 pdt
From: "Jonathan S. Shapiro" <shap@sid.stanford.edu>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: International character sets.

If anyone thinks it would help the discussion, I would be more than
happy to send out a description of the solution that was adopted for
ANSI-C, and put forth a proposal whose purpose is only to act as a
basis for discussion describing how we might adapt it to Scheme.

Jon

∂11-Jul-89  1136	@mc.lcs.mit.edu,@ZURICH.ai.mit.edu:jar@annabel.stanford.edu 	Regularization of list, vector, and string procedures 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89  11:36:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13758;
          11 Jul 89 14:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Jul 89 14:21:04 EDT
Received: from ZURICH.AI.MIT.EDU by mintaka.lcs.mit.edu id aa13695;
          11 Jul 89 14:15 EDT
Return-Path: <jar@annabel.stanford.edu>
Received: from sonoma.Stanford.EDU ([36.22.0.158]) by ZURICH.AI.MIT.EDU; Tue, 11 Jul 89 14:12:48 edt
Received: by sonoma.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA02184; Tue, 11 Jul 89 10:13:37 PDT
Message-Id: <8907111713.AA02184@sonoma.Stanford.EDU>
Received: from annabel.STANFORD.EDU by dolores; Tue, 11 Jul 89 10:14:22 pdt
Received: by annabel; Tue, 11 Jul 89 10:12:25 pdt
Date: Tue, 11 Jul 89 10:12:25 pdt
To: mkatz@sesame.stanford.edu
Cc: rrrs-authors@ZURICH.ai.mit.edu
In-Reply-To: Morris Katz's message of Tue, 11 Jul 89 09:14:32 PDT <8907111614.AA17846@sesame.Stanford.EDU>
Subject: Regularization of list, vector, and string procedures
From: Jonathan Rees <jar%sid.stanford.edu@polya.stanford.edu>
Sender: jar@annabel.stanford.edu

(It looks like you might not have the final version of the Revised↑3
Report.  append! and =? were both flushed at the last minute.  The
version that was given out at the '86 LFP conference was unfortunately
not the final version, so anyone who has one should discard it.)

I have no real problem with the "noncontroversial" changes you
enumerate, although I can't imagine any use for string->vector or
vector->string.

Generalizing apply to be generic over the type of the last argument
would constitute a strong precendent for the introduction of other
generic sequence functions, a la Common Lisp.  I would prefer not to
see that happen, thus I'd rather that apply be left alone.  Similarly,
I'd rather not see generic member or match.

I would rather not see any extensions to the map/for-each line that
don't do the real job, which is to improve the ways in which we can
write iterations.

∂11-Jul-89  2148	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #156 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 11 Jul 89  21:48:05 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01797;
          12 Jul 89 0:38 EDT
Date: 12 JUL 89  00:10:54 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #156 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907120038.aa01797@mintaka.lcs.mit.edu>

Scheme Digest #156                             12 JUL 89  00:10:54 EDT

Today's Topics:

        Scheme Digest #147

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

Date: Tue, 11 Jul 89 10:21:15 EST
From: "John T. Nelson" <jtn@potomac.ads.com>
Message-Id: <8907111521.AA25882@potomac.ads.com>
Subject: Re: Scheme Digest #147



If you have a pointer to the FTP'able Scheme report and/or public
domain Scheme I'd appreciate hearing about it.





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

End of Scheme Digest
********************

∂12-Jul-89  1325	@mc.lcs.mit.edu:Pavel.pa@xerox.com 	Fluid binding 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89  13:25:09 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21337;
          12 Jul 89 16:19 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 16:16:00 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa21211; 12 Jul 89 16:12 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUL 89 11:00:17 PDT
Date: Wed, 12 Jul 89 11:00:52 PDT
From: Pavel.pa@xerox.com
Subject: Fluid binding
In-reply-to: <8907061641.AA25714@sesame.Stanford.EDU>
To: rrrs-authors@mc.lcs.mit.edu
Message-ID: <890712-110017-1659@Xerox>

Morry asks for a better argument as to why shallow binding cannot be used
on shared-memory multiprocessors.  It seems fairly clear to me.  Consider
two threads, running on separate processors, both within the scope of a
particular lexical variable, X.  When either thread assigns to X, obviously
the other thread should get the new value when it reads X.  When one thread
fluid-binds X, though, it has, in effect, a new variable with the same name
over some dynamic extent; changes to the new variable should NOT be visible
to the other thread.  In shallow binding, however, the new variable uses
the same storage as the old one and its ``temporary assignment'' cannot be
distinguished from any other assignment.  Thus, the new value WILL be
visible to the other thread, in contradiction to the desired behavior.  I
thus conclude that shallow binding is not a viable approach for fluid
variables on a shared-memory multiprocessor.

Jinx had some interesting comments:

    1) MAKE-FLUID, FLUID-REF and FLUID-SET! don't have much to do with
    fluids, they have to do with cells (or boxes, as some other people
    call them).  As such, I would like them to be renamed to
    MAKE-CELL, CELL-REF, and CELL-SET!.

    Alternatively we could have both MAKE-CELL, CELL-REF, CELL-SET! to
    manipulate cells (the selector and mutator always provide the global
    value), and FLUID-CELL-REF, FLUID-CELL-SET! to access the current
    dynamic value.  Which of the accessors is written on top of which
    depends on whether the implementation is deep or shallow.

When I first read this, it seemed very reasonable.  On later thought,
however, I concluded otherwise.  For the first paragraph, I think that,
conceptually, MAKE-FLUID, FLUID-REF and FLUID-SET! have nothing to do with
cells at all.  Rather, they traffic in ``fluid variables'', opaque values
that are the domain of the ``fluid environment'' (the range is locations,
just as in the lexical environment).  Certainly one implementation of these
procedures (and the one I would use) has MAKE-FLUID return a cell, as you
suggest, but I think renaming them in terms of cells is a convolution of
their abstract semantics with one particular concrete realization.

I have additional problems with idea in the second paragraph.  In a
shallow-binding implementation, CELL-REF is identical to FLUID-CELL-REF
while in a deep-binding implementation, their semantics is quite different.
I think it unwise for the language semantics to change depending upon a
property of the implementation that should be completely invisible.

I think that, if we want to add cells as a standard data type in the
language, we should do so separately.

    2) Although I admit that FLUID-LET would be the most common way of
    obtaining dynamic behavior, I'd rather have it be a simple macro that
    expands into a standard procedure.  In particular, I would like to
    have

        (FLUID-LET ((<var-expr1> <val-expr1>)
                    (<var-expr2> <val-expr2>)
                    ... )
           <body>)

    expand into something like

        (with-cell-contents
          (list var-expr1 var-expr2 ...)
          (list val-expr1 val-expr2 ...)
          (lambda ()
           <body>))

I don't object to this in principle, but I'd rather a somewhat simpler
primitive that doesn't promote lists in this way.  For example, the
following:

    (fluid-let ((<var-expr1> <val-expr1>)
                (<var-expr2> <val-expr2>)
                ...
                (<var-exprN> <val-exprN>))
       <body>)

expands into

    (let ((var1 <var-expr1>)
          (val1 <val-expr1>)
          (var2 <var-expr2>)
          (val2 <val-expr2>)
          ...
          (varN <var-exprN>)
          (valN <val-exprN>)
          (body-thunk (lambda () <body>)))

       (with-fluid-binding var1 val1
          (lambda ()
             (with-fluid-binding var2 val2
                (lambda ()
                   ...
                      (with-fluid-binding varN valN
                         body-thunk) ... )))))

That is, I prefer a primitive that establishes exactly one binding at a
time.  Also, since I conceive of this construct in terms of new bindings in
the fluid environment, as opposed to changing the ``contents'' of anything,
a prefer a name for the primitive that says so.  Thus my
``with-fluid-binding'' in contrast to Jinx's ``with-cell-contents''.

    3) There are many incompatible versions of FLUID-LET out there, so I
    think we should use a different name for it so that existing
    implementations can continue using their code without having to
    rewrite it and can provide two different mechanisms, the standard, and
    the old one.  I would suggest WITH-FLUID-CONTENTS or something like
    that, but I'm not good at choosing names.

Cedar Scheme is one of those implementations with an incompatible construct
called FLUID-LET, so we would have to rewrite our code as well, but I don't
anticipate it being very hard to do.  It seems to me that a very simple
global query-replace could be used to change all of the uses of the old
construct to use a different name.  That way, the new standard construct
can use the stylistically correct and appropriate name and old code need
not be rewritten.  For example, we might rename our old construct to
SHALLOW-BIND...  (Unlike Scheme Xerox, our new implementation, Cedar Scheme
does not support multiple threads of execution.)

I think it's important, when we reach consensus on a feature with which
we've all experimented, that we can reasonably expect some implementations
to change for the new standard.

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

I believe that the above discussion answers all standing comments on the
fluid binding proposal.  Are there any further comments or responses to the
above?

	Pavel

∂12-Jul-89  1400	@mc.lcs.mit.edu,@LIFE.ai.mit.edu:cph@zurich.ai.mit.edu 	scheme mailing list
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89  14:00:16 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22080;
          12 Jul 89 16:51 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 16:45:56 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21962;
          12 Jul 89 16:43 EDT
Received: from ZURICH.AI.MIT.EDU ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA02542; Wed, 12 Jul 89 16:23:08 EDT
Return-Path: <cph@ZURICH.AI.MIT.EDU>
Received: by ZURICH.AI.MIT.EDU; Wed, 12 Jul 89 16:20:03 edt
Date: Wed, 12 Jul 89 16:20:03 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907122020.AA13254@ZURICH.AI.MIT.EDU>
To: pavel.pa@xerox.com
Cc: scheme-standard@LIFE.ai.mit.edu, rrrs-authors@LIFE.ai.mit.edu
In-Reply-To: Chris Haynes's message of Wed, 12 Jul 89 12:09:16 -0500
Subject: scheme mailing list

   Date: Wed, 12 Jul 89 12:09:16 -0500
   From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>

      Date: Thu, 06 Jul 89 18:52:11 PDT
      From: Pavel.pa@Xerox.COM

      Chris, can you add someone to the Scheme-Standard mailing list?  I've tried
      writing to scheme-standard-request@mc.lcs.mit.edu (but it doesn't exist)
      and cph@kleph.ai.mit.edu (but got nasty mailer failures).

      I'd like to see my summer intern, Jim Rauen <Rauen.pa@Xerox.Com>, have
      access to both scheme-standard and rrrs-authors; so far, I haven't managed
      to succeed at either of them.  Sigh.

      Thanks,

	      Pavel

The correct address is

    scheme-standard-request@wheaties.ai.mit.edu

My correct address is

    cph@zurich.ai.mit.edu

(recent system reconfiguration prevents "kleph" from accepting mail).

I've added rauen to "scheme-standard".

I have to look into "rrrs-authors" -- JAR left me in charge of it
while he's away.

I've set things up so that the following addresses will work,
forwarding mail to the appropriate mailing lists.  I may actually move
the lists to this machine for ease of maintainance.

rrrs-authors@life.ai.mit.edu
rrrs-authors-request@life.ai.mit.edu
scheme@life.ai.mit.edu
scheme-request@life.ai.mit.edu

∂12-Jul-89  1433	@mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com 	R↑3.95RS: open-input-file open-output-file
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89  14:33:09 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22672;
          12 Jul 89 17:28 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 17:24:43 EDT
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa22596;
          12 Jul 89 17:22 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	id AA02411; Wed, 12 Jul 89 14:22:24 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	for rrrs-authors@mc.lcs.mit.edu; id AA02411; Wed, 12 Jul 89 14:22:24 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
	id AA01036; Tue, 11 Jul 89 13:56:11 EDT
Date: Tue, 11 Jul 89 13:57:19 EDT
From: jmiller@crl.dec.com
Message-Id: <8907111757.AA00833@peanut.DEC.COM>
To: Alan@reagan.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden  10-Jul-89 1709 EDT's message of Tue, 11 Jul 89 03:57:03 EDT <8907110757.AA00450@crl.crl.dec.com>
Subject: R↑3.95RS: open-input-file open-output-file
Reply-To: JMiller@crl.enet.dec.com

I agree completely with you.  One of the things that Scheme needs is a
"reasonable" error (condition, exception, take your pick) system.  In
lieu of that, which I suspect will take some time to agree upon, I
believe we need a mechanism for PORTABLE programs to use procedures
that SIGNAL an error.  There are very few such procedures: only these
two (OPEN-[IN/OUT]PUT-FILE), two similar ones that can be built on top
of these (CALL-WITH-[IN/OUT]PUT-FILE), and READ.  In addition, numeric
operations are permitted to signal an error when they reach
implementation limits on representations.

Is it really a high price to pay, pending agreement on an error
system, to allow a portable mechanism for detecting the errors
generated by OPEN-[IN/OUT]PUT-FILE?  Notice that my proposal would not
make this the default behavior: only with explicit programmer action
would it be possible to receive a value of #F instead of an error.
Making this change would allow programs, for example, to try
alternative file names given a root file name (this allows porting
across Scheme implementations, not operating systems).  A similar
change to READ would allow portable programs to recover from user
input errors.

--Jim

∂12-Jul-89  1444	@mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com 	EQV? and =  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89  14:44:37 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22908;
          12 Jul 89 17:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 17:24:50 EDT
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa22598;
          12 Jul 89 17:23 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	id AA02503; Wed, 12 Jul 89 14:22:55 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	for rrrs-authors@mc.lcs.mit.edu; id AA02503; Wed, 12 Jul 89 14:22:55 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
	id AA01246; Tue, 11 Jul 89 16:54:54 EDT
Date: Tue, 11 Jul 89 16:56:02 EDT
From: jmiller@crl.dec.com
Message-Id: <8907112056.AA00888@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: EQV? and =
Reply-To: JMiller@crl.enet.dec.com

I thought that 
   (and (number? x) (number? y) (= x y)) implied
   (eqv? x y).
By my reading of R3.95RS this isn't true (consider x=3 and y=3.0),
although I believe
   (and (number? x) (number? y) (eqv? x y)) implies
   (= x y)
Have I got this right?

--Jim


∂12-Jul-89  1716	@mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89  17:16:36 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24940;
          12 Jul 89 20:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 20:09:01 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24788;
          12 Jul 89 20:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03806; Wed, 12 Jul 89 20:03:45 EDT
Return-Path: <@spencer.cs.uoregon.edu:will@cs.uoregon.edu>
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Wed, 12 Jul 89 20:00:43 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
	(5.59++/IDA-1.2.8) id AA20470; Wed, 12 Jul 89 17:03:12 PDT
Received: by spencer.cs.uoregon.edu; Wed, 12 Jul 89 17:03:23 PDT
Date: Wed, 12 Jul 89 17:03:23 PDT
From: will@cs.uoregon.edu
Message-Id: <8907130003.AA17137@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: last call: changes for R4RS

The P1178 working group on Scheme has requested a few more changes to the
R3.95RS before it becomes the R4RS.  From the votes taken at P1178, I
judge that two of these changes are sufficiently controversial that they
will require positive action by the authors to be adopted.  The other
changes that were requested appear to be noncontroversial, and I will
implement these other changes unless the authors object.

I have promised the P1178 editors that I will deliver the final draft of
the R4RS to them by the end of July so they can incorporate it into the
IEEE standard they're drafting.  So if you want to influence the R4RS,
you'd better send mail to RRRS-AUTHORS within the next two weeks.

I will be off the net during that time because my department is moving
into a new building this weekend, and the computers will be shut down
until the move is completed.  I have made arrangements to read mail sent
to RRRS-AUTHORS during that time, but I will be unable to send mail myself.

Peace,
William Clinger
(503) 345-6995 (home)

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

Controversial changes requiring positive action by the authors if they are
to be adopted in the R4RS:

Section 6.3.
P1178 has requested again that LIST-REF be made essential, for parallelism
with VECTOR-REF and STRING-REF.  Their previous request that LIST-TAIL be
made essential has been dropped.

Section 6.5.5.
P1178 has requested that MIN and MAX be renamed INF and SUP.  The rationale
is that the somewhat surprising behavior of MIN and MAX when given mixed
exact and inexact arguments would be more acceptable if their names were
less familiar.  A second rationale is that the fact that the mathematical
infimum and supremum operations, when given an infinite set of "arguments",
may return a result that is not in the argument set; this is the surprising
thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
Background: In any case, a note will be added to point out and explain this
behavior, which is required in order for exact results to be trusted.  It
happens that MIN and MAX behave this way in Common Lisp as well, although
the motivation was rather different.

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

Noncontroversial changes that will be adopted in the R4RS unless the authors
object:

Section 6.5.3.
EXPT will be added to the list of procedures that are required to return
an exact integer if all their arguments are exact and the mathematically
expected result is representable as an exact integer within the
implementation.  Examples of what will be newly required:

    (expt 2 3)     -->  8      ; exact 8
    (expt -3 0)    -->  1      ; exact 1
    (expt 1 -20)   -->  1      ; exact 1

Section 6.5.5.
If a variable x has a proper number as its value, then (= x x) will be
required to be true.  Note: "proper number" is intended to exclude NaNs
et cetera.  [Alternatively we could require NUMBER?---and therefore
REAL?---to be false of NaNs.  I'd rather not try to specify this level
of detail until we have more experience with non-IEEE implementations
of inexact arithmetic.]

Section 6.2.
EQV?-ness is preserved when storing into and fetching from the standard
data structures (pairs, vectors, strings).  [Note: EQ?-ness isn't
necessarily preserved.  Preservation of EQV?-ness implies preservation
of exactness, which is the context in which P1178 requested this change.]

P1178 and individuals also pointed out several places where editorial
changes would improve the presentation, but none of these changes affect
the content so I'm not going to list them here.

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

Summary of substantive changes that I have posted in previous messages:

Add ... as a new peculiar identifier.

Change branch cuts for ATAN.

Require INTEGER->CHAR and CHAR->INTEGER be one-to-one.

Restore CHAR-UPPER-CASE?.

Make the truth value of the empty list be unspecified.

Fix the second production for <decimal 10>.

Change the specification of NUMBER->STRING to fix bugs pointed out by
Kent Dybvig.


∂12-Jul-89  1731	@mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	legion 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89  17:31:02 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25119;
          12 Jul 89 20:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 20:09:18 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24819;
          12 Jul 89 20:06 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03862; Wed, 12 Jul 89 20:05:55 EDT
Return-Path: <@spencer.cs.uoregon.edu:will@cs.uoregon.edu>
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Wed, 12 Jul 89 20:02:56 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
	(5.59++/IDA-1.2.8) id AA20486; Wed, 12 Jul 89 17:05:28 PDT
Received: by spencer.cs.uoregon.edu; Wed, 12 Jul 89 17:05:39 PDT
Date: Wed, 12 Jul 89 17:05:39 PDT
From: will@cs.uoregon.edu
Message-Id: <8907130005.AA17154@spencer.cs.uoregon.edu>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: legion

In response to Pavel's sermon/supplication, here is what I think of some
of the ideas that have been mooted about recently.

If indeed we must add fluid variables to the language, then I think that
we should do something very like Pavel's proposal.  I'm not keen on
adding fluid variables, however.  If we are to add any dynamic features
I'd rather add DYNAMIC-WIND, which seems simpler and more useful.  If
we had DYNAMIC-WIND and a macro package, then people could pull their
favorite semantics for fluid variables out of the yellow pages.

Jinx:
    ...I'll state my position, which I believe coincides with his and
    was the consensus of most implementors a while ago.

    An implementation that does not allow assignment of the initial
    variables (including those bound to procedures) in an RnRs environment
    is in ERROR....It is acceptable, however, for an implementation to
    default to "benchmark" mode, as long as the following two conditions
    are met:

    1) There is a way to take it out of benchmark mode.
    2) Appropriate warnings about redefinition/warning are given when the
    implementation is in benchmark mode and an assignment/redefinition is
    "attempted".

I agree with this statement.  I would add to it that while the number
of people who need to get out of benchmark mode is very small, they
usually have pretty good reasons for wanting to escape from it.
Furthermore it isn't very hard to design a Scheme system so that the
vast majority of users who run in benchmark mode do not lose any
performance as a result of the tiny minority who need to escape from it.

Pavel:
    ...The way you'll lose horribly in Scheme Xerox is that your program
    won't compile.  I'm not asking R4RS to prohibit redefinition, I'm
    simply asking it to let me do so in my own implementation.

It is perfectly all right for your compiler to prohibit redefinition,
so long as your system provides a second mode in which redefinition is
allowed.  The second mode doesn't have to be fast.  It could be
implemented by a pure interpreter layered on top of everything else,
using an entirely separate environment.  Furthermore you could require
that users who wish to program in non-benchmark mode must do so by
loading the interpreter interactively and calling a special
read/eval/print loop.  In other words, the requirement you've been so
concerned about is absolutely trivial.  You should go ahead and build
your system however you want, and implement the non-benchmark mode
after you've got everything else running.

Jinx:
    I think most people would agree that R4RS as it currently stands is a
    toy language.  Besides macros, fluid binding and other well known
    conveniences, it lacks any practical way of separating large programs
    into semi-independent subprograms without exporting zillions of names
    into the top level environment.

I do not agree that R4RS is a toy language.  Compare it to C: Scheme's
unrestricted block structure, together with the first-class-ness of all
objects that allows a locally defined object to be stored into a global
variable, provides at least as much control over names as you get with
C.  C doesn't have fluid variables, nor does it have environments, nor
does it have EVAL, et cetera.  C has macros, but if C's macros are the
decisive feature that makes C a non-toy language then we can trivially
make R4RS into a non-toy language by wedding it to the C preprocessor.

Scheme is deficient in several ways, but we can justify proposed
improvements without characterizing the existing language as a toy.

Pavel:
        ...the user cannot portably assign to (or even rebind) variables
        named ``if'', ``or'', ``delay'', or even ``unquote''...
Morry:
    This is one of the reasons we need macros.  As soon as we have them,
    I will be able to override the default definitions for special forms
    as well.

This is speculation, since not all macro facilities allow this override.
Common Lisp provides an example.

Jinx:
    We've been trying to fix this for quite a while.  It has not been
    fixed in R4RS because of political and technical problems having to do
    with the actual solutions suggested, not because we don't agree that
    this should be fixed.

I am not convinced that it should be fixed.  So long as the set of
syntactic keywords is very small, keeping them reserved contributes to
readability.  It also appears that the various macro facilities that
have been proposed would be significantly easier to use correctly if
syntactic keywords remain reserved.  In fact, I believe that one of
the main reasons we don't yet have a standard macro facility is that
too much effort has been devoted to the difficulties that arise only
when syntactic keywords can be shadowed by lexical variables.

Jim Miller:
    I'd like to suggest that Pavel use "|" instead of ":" for his module
    separator.

I thought this was an excellent suggestion.  In addition to the four
reserved brackets ([, ], {, }), the three varieties of quote mark
(", ', `), and the comma, there are four very usable characters
available for extending the lexical syntax of identifiers: |  @  #  \.
If an implementation consumes these four and is still hungry for more,
then I doubt we can appease it for long by feeding it a colon.

Will:
      2.  (This reason is pretty weak.)  For the compiler writer, I
          think the freedom to rearrange definitions makes closure
          analysis a little simpler when procedure definitions are
          mixed with definitions of variables containing non-procedure
          values.

This is incorrect.  The compiler would still have the freedom to move
procedure definitions in front of other definitions, since it could
make a difference only if the program is in error.  Once the procedure
definitions have been grouped together, their order makes no difference
under either semantics.

Peace, Will

∂12-Jul-89  1745	@mc.lcs.mit.edu,@life.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	Regularization of list, vector, and string procedures    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89  17:45:24 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25254;
          12 Jul 89 20:32 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Jul 89 20:09:33 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24837;
          12 Jul 89 20:08 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03872; Wed, 12 Jul 89 20:08:06 EDT
Return-Path: <@spencer.cs.uoregon.edu:will@cs.uoregon.edu>
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Wed, 12 Jul 89 20:05:07 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
	(5.59++/IDA-1.2.8) id AA20496; Wed, 12 Jul 89 17:07:37 PDT
Received: by spencer.cs.uoregon.edu; Wed, 12 Jul 89 17:07:48 PDT
Date: Wed, 12 Jul 89 17:07:48 PDT
From: will@cs.uoregon.edu
Message-Id: <8907130007.AA17164@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Regularization of list, vector, and string procedures
Cc: mkatz@sesame.stanford.edu


    6)  String=? is only present for symetry with string-ci=? and should NOT
        be generalized to list=? and vector=? since we already have =?.

I think you meant EQUAL? instead of =?.

    1)  Create list? which checks for a null terminated list...

This is useful.  I prefer the name PROPER-LIST?.

    2)  Generalize apply...[to be generic in the last argument]

I'd prefer to avoid generic procedures at the lowest levels of Scheme.
Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?

    3)  There are several possibilities for map and foreach:
        a)  ...
        b)  Introduce list-map, string-map, vector-map, list-foreach,
            string-foreach, and vector-foreach...
        c)  The same 6 procedures would be introduced as in b).  In this
            case the name would specify the type of the return value.
            The procedures would be polymorphic over arguments of type
            list, string, and vector...

In c), it doesn't make sense to have three versions of FOR-EACH distinguished
by the type of their return value, since presumably the return value is
unspecified in each case.  Again, I'd prefer type-specific procedures over
generic procedures, because the types are usually known and something like
(VECTOR-FOREACH F V1 V2) conveys more information than (FOREACH F V1 V2).
As a practical matter, the type-specific procedures would have to exist
anyway, and the question is whether the programmer gets to refer to them
directly or must go through a generic interface that obscures the type
information.

The argument in favor of generic procedures is that there would have to be
3 type-specific versions of FOR-EACH and 9 type-specific versions of MAP
even if all the arguments to these procedures are required to be of the
same type.  It gets worse if we relax that requirement or if we add more
sequence types.

Here's a counter-proposal: define MAKE-FOREACH and MAKE-MAP that take a
description of the argument and result types for the FOR-EACH or MAP
procedure needed and return the appropriate FOR-EACH or MAP procedure.
Implementations would then be free to special-case these procedures as much
as they feel is necessary, using EQ? tests on the arguments.  Sample
implementation and use of MAKE-MAP:

>>> (define (make-map maker0 setter0 length1 ref1 . more-length&ref-procs)
      (do ((length-procs (list length1) (cons (car procs) length-procs))
           (ref-procs (list ref1) (cons (cadr procs) ref-procs))
           (procs more-length&ref-procs (cddr more-length&ref-procs)))
          ((null? procs)
           (let ((length-procs (reverse length-procs))
                 (ref-procs (reverse ref-procs)))
             (lambda (f x1 . more-args)
               (let ((args (cons x1 more-args))
                     (n (length1 x1)))
                 (for-each (lambda (length-proc arg)
                             (if (not (= (length-proc arg) n))
                                 (error "Arguments have different lengths")))
                           (cdr length-procs)
                           (cdr args))
                 (let ((result (maker0 n)))
                   (do ((i (- n 1) (- i 1)))
                       ((negative? i) result)
                       (setter0 result i (apply f (map (lambda (ref arg)
                                                         (ref arg i))
                                                       ref-procs
                                                       args)))))))))))
make-map
>>> (define map:string&list->vector
      (make-map make-vector vector-set!
                string-length string-ref
                length list-ref))
map:string&list->vector
>>> (map:string&list->vector list "abcdef" '(0 1 2 3 4 5))
#((#\a 0) (#\b 1) (#\c 2) (#\d 3) (#\e 4) (#\f 5))

This proposal is substantially more general than generic MAP or FOR-EACH
would be (since the length, ref, and setter procedures could perform
arbitrary computations), and could be made equally efficient for the
cases that could be handled by generic MAP and generic FOR-EACH.

Peace, Will


∂12-Jul-89  2216	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #157 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 12 Jul 89  22:16:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa29664;
          13 Jul 89 0:58 EDT
Date: 13 JUL 89  00:10:56 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #157 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907130058.aa29664@mintaka.lcs.mit.edu>

Scheme Digest #157                             13 JUL 89  00:10:56 EDT

Today's Topics:

        DO syntax in XScheme
        do loop for 1.6 XScheme

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

Date: Wed, 12 Jul 89 16:46:56 GMT
From: NETWORK%FRSAC11.BITNET@mitvma.mit.edu
Subject: DO syntax in XScheme
Message-ID:  <8907121059.aa12607@mintaka.lcs.mit.edu>


I am looking deseparatly for a do construct for XSCHEME, 0.15 or 0.16.
The change in macros.s between 0.15 and 0.16 break my
syntax for named-lambda. Any comments or working named-lambda in 0.16 ?
The benchmarks give a noticeable slowdown from 0.15 to 0.16, any comments ?

Any understandable documentation on the macro.s package welcome.

I need the ststuff.c for the atari ST, using MWC, by the way.
I made up something to work with Lattice 3.04, but it may be less than ideal.

Regards,

Jean-Pierre H. Dumas

network@frsac11 (bitnet)
network%frsac11.bitnet@cunyvm.cuny.edu (arpanet)
dumas@sumex-aim.stanford.edu (arpanet)

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

Date: 12 Jul 89 21:19:40 GMT
From: Shawn McLean <news!mclean@think.com>
Subject: re: do loop for 1.6 XScheme
Message-Id: <MCLEAN.89Jul12171940@pozzo.think.com>

Help yourself.  Also included is a defsetf clone. -shawn

;;; (c) Copyright 1989, Shawn Mclean
;;; All rights reserved
;;; Permission is granted for unrestricted non-commercial use
;;; created: Tue 3-28-1989 22:32
;;; XScheme - Version 0.16
;;; commonlisp compatibility macros and functions

;;;
;;; macros
;;;

(macro defmacro 
  (lambda (form)
    (let* ((name (cadr form)) (form (cddr form))
           (arglist (car form)) (form (cdr form))
           (body (car form)))
    (put name '%arglist arglist)
      `(macro ,name
         (lambda (form)
           (apply (lambda ,arglist ,body) (cdr form)))))))

;;;
;;; lists
;;;

(macro first (lambda (form) `(car ,(cadr form))))
(macro second (lambda (form) `(cadr ,(cadr form))))
(macro third (lambda (form) `(caddr ,(cadr form))))
(macro fourth (lambda (form) `(cadddr ,(cadr form))))
(macro fifth (lambda (form) `(caddddr ,(cadr form))))
(macro nth (lambda (form) `(list-ref ,(cadr form) ,(caddr form))))

(macro push
  (lambda (form)
    (let ((item (cadr form))
          (list (caddr form)))
      `(set! ,list (cons ,item ,list)))))

(macro pop 
  (lambda (form)
    (let ((list (cadr form))
          (item (gensym 'item)))
      `(let ((,item (car ,list)))
         (set! ,list (cdr ,list))
         ,item))))

;;;
;;; loops
;;;

(macro do
  (lambda (form)
    (let (locals test body exits inits updates)
      (set! locals (reverse (cadr form)))
      (set! form (cddr form))
      (set! test (car form))
      (set! form (cdr form))
      (set! body form)
      (set! exits (cdr test))
      (set! test (list 'not (car test)))
      (while locals
        (let* ((local (car locals))
               (var (if (list? local) (car local) local))
               (init (cadr local))
               (update (caddr local)))
          (push (list var init) inits)
          (if update (push `(set! ,var ,update) updates))
          (set! locals (cdr locals))))
      `(let ,inits (while ,test ,@body ,@updates) ,@exits))))

(macro do*
  (lambda (form)
    (let (locals test body exits inits updates)
      (set! locals (reverse (cadr form)))
      (set! form (cddr form))
      (set! test (car form))
      (set! form (cdr form))
      (set! body form)
      (set! exits (cdr test))
      (set! test (list 'not (car test)))
      (while locals
        (let* ((local (car locals))
               (var (if (list? local) (car local) local))
               (init (cadr local))
               (update (caddr local)))
          (push (list var init) inits)
          (if update (push `(set! ,var ,update) updates))
          (set! locals (cdr locals))))
      `(let* ,inits (while ,test ,@body ,@updates) ,@exits))))

(macro dotimes
  (lambda (form)
    (let* ((control (cadr form))
           (body (cddr form))
           (var (car control))
           (limit (cadr control)))
      `(let ((,var 0))
         (while (< ,var ,limit) ,@body (set! ,var (1+ ,var)))))))

(macro dolist
  (lambda (form)
    (let* ((control (cadr form))
           (body (cddr form))
           (item (car control))
           (list (cadr control))
           (items (gensym 'items)))
      `(let ((,items ,list))
         (while (not (null? ,items))
           (set! ,item (car ,items))
           ,@body
           (set! ,items (cdr ,items)))))))

;;;
;;; debugger
;;;
;;; Is this the way to do this?

(define break
  (lambda args
    (display "break: ") (dolist (arg (cdr args)) (display arg))
    (let ((env (environment-bindings (the-environment))))
      (dolist (binding env)
        (map display (car binding) ":	" (cdr binding))
        (newline))
      (read))))

;;;
;;; string conversions
;;; not common lisp

(define integer->string
  (lambda (integer)
    (let ((done nil) (integer-string nil))
      (while (not done)
        (push (integer->char (+ (char->integer #\0) (remainder integer 10)))
              integer-string)
        (set! integer (quotient integer 10))
        (set! done (= integer 0)))
      (list->string integer-string))))
       

;;;
;;; general accessor
;;;
;;; This is a defsetf clone that works on global functions.  A modifier
;;; function is first defined with defset, and following set will invert a
;;; reference.  For example:
;;;
;;; (set (car foo) 'bar) => (set-car! foo 'bar)
;;;
;;; If anything, this saves you from typing !'s all over the place.  set
;;; will accept one or pairs of auguments.

(macro set
  (lambda (pairs)
    (if (odd? (length (cdr pairs)))
        (error "odd number of arguments to set")
        (do* ((place (cdr pairs) (cdr place))
             (value (cdr place) (cdr place))
             (assignments nil))
            ((null? place)
             (if (cdr assignments)
                 `(begin ,@(reverse assignments))
	         (car assignments)))
          (set! assignments (cons (general-set (car place) (car value))
                                  assignments))
          (set! place (cdr place))))))

(define general-set
  (lambda (place value)
    (if (list? place)
        ((get (car place) 'set) (cadr place) value)
        `(set! ,place ,value))))

(defmacro defset (function lambda-list values form)
  (let ((set-function `(lambda (,@lambda-list ,@values) ,form)))
   `(begin (put ',function 'set ,set-function) ',function)))

(defset car (list) (value) `(set-car! ,list ,value))
(defset cdr (list) (value) `(set-cdr! ,list ,value))

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

End of Scheme Digest
********************

∂13-Jul-89  0537	@mc.lcs.mit.edu,@life.ai.mit.edu:ramsdell@linus.mitre.org 	fluid variables 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  05:37:00 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04407;
          13 Jul 89 8:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 08:30:46 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04309;
          13 Jul 89 8:28 EDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02056; Thu, 13 Jul 89 08:28:17 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA22160; Thu, 13 Jul 89 08:24:46 EDT
Posted-Date: Thu, 13 Jul 89 08:24:40 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA02866; Thu, 13 Jul 89 08:24:40 EDT
Date: Thu, 13 Jul 89 08:24:40 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907131224.AA02866@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:05:39 PDT <8907130005.AA17154@spencer.cs.uoregon.edu>
Subject: fluid variables
Reply-To: ramsdell@mitre.org

I support the general idea adding fluid variables to Scheme.  We
should face the fact that current-input-port and current-output-port
really should be fluid variables, and define with-input-from-file and
with-output-to-file in terms of fluid-let and call-with-input-file and
call-with-output-file.

I will withdraw my support if implementors feel fluid variables would
slow down their Scheme implementation.
John

∂13-Jul-89  1137	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	last call: changes for R4RS   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  11:36:52 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09942;
          13 Jul 89 14:14 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 14:08:56 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09681;
          13 Jul 89 14:00 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00494; Thu, 13 Jul 89 14:00:13 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 13:57:13 edt
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05014; Thu, 13 Jul 89 11:57:23 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA27346; Thu, 13 Jul 89 08:56:23 PDT
Date: Thu, 13 Jul 89 08:56:23 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907131556.AA27346@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:03:23 PDT <8907130003.AA17137@spencer.cs.uoregon.edu>
Subject: last call: changes for R4RS

   Date: Wed, 12 Jul 89 17:03:23 PDT
   From: will@cs.uoregon.edu

   Section 6.3.
   P1178 has requested again that LIST-REF be made essential, for parallelism
   with VECTOR-REF and STRING-REF.  Their previous request that LIST-TAIL be
   made essential has been dropped.

I have said it beofre, but just to make my position clear, I support the
inclusion of LIST-REF in R4RS if the rest of the proposal for regularization of
sting, vector, and list procedures is adopted; and, I oppose it, otherwise.

   Section 6.5.5.
   P1178 has requested that MIN and MAX be renamed INF and SUP.  

Personally, I prefer the names MIN nad MAX despite the infinum and supremum
semantics.  But, I do not feel stonrgly enough about this to put up much of an
argument. 

-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂13-Jul-89  1141	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	Regularization of list, vector, and string procedures  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  11:41:43 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10119;
          13 Jul 89 14:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 14:09:10 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09685;
          13 Jul 89 14:00 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00497; Thu, 13 Jul 89 14:00:24 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 13:57:25 edt
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04957; Thu, 13 Jul 89 11:49:38 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA27294; Thu, 13 Jul 89 08:48:35 PDT
Date: Thu, 13 Jul 89 08:48:35 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907131548.AA27294@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:07:48 PDT <8907130007.AA17164@spencer.cs.uoregon.edu>
Subject: Regularization of list, vector, and string procedures

   Date: Wed, 12 Jul 89 17:07:48 PDT
   From: will@cs.uoregon.edu


       6)  String=? is only present for symetry with string-ci=? and should NOT
	   be generalized to list=? and vector=? since we already have =?.

   I think you meant EQUAL? instead of =?.

Correct.  RNRS changed between the tie I wrote the initial message (about 1
year ago) and when I reposted it.

       1)  Create list? which checks for a null terminated list...

   This is useful.  I prefer the name PROPER-LIST?.

For symetry with STRING? and VECTOR?, I think it should be called LIST? even
though PROPER-LIST? would be a better name in the absence of these
considerations. 

       2)  Generalize apply...[to be generic in the last argument]

   I'd prefer to avoid generic procedures at the lowest levels of Scheme.
   Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
   LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?

I must be suffering from brain damage.  This is clearly a better idea and more
in keeping with the spirit of my other recommendations.

       3)  There are several possibilities for map and foreach:
	   a)  ...
	   b)  Introduce list-map, string-map, vector-map, list-foreach,
	       string-foreach, and vector-foreach...
	   c)  The same 6 procedures would be introduced as in b).  In this
	       case the name would specify the type of the return value.
	       The procedures would be polymorphic over arguments of type
	       list, string, and vector...

   In c), it doesn't make sense to have three versions of FOR-EACH distinguished
   by the type of their return value, since presumably the return value is
   unspecified in each case.  Again, I'd prefer type-specific procedures over
   generic procedures, because the types are usually known and something like
   (VECTOR-FOREACH F V1 V2) conveys more information than (FOREACH F V1 V2).
   As a practical matter, the type-specific procedures would have to exist
   anyway, and the question is whether the programmer gets to refer to them
   directly or must go through a generic interface that obscures the type
   information.

   The argument in favor of generic procedures is that there would have to be
   3 type-specific versions of FOR-EACH and 9 type-specific versions of MAP
   even if all the arguments to these procedures are required to be of the
   same type.  It gets worse if we relax that requirement or if we add more
   sequence types.

   Here's a counter-proposal: define MAKE-FOREACH and MAKE-MAP that take a
   description of the argument and result types for the FOR-EACH or MAP
   procedure needed and return the appropriate FOR-EACH or MAP procedure.
   Implementations would then be free to special-case these procedures as much
   as they feel is necessary, using EQ? tests on the arguments.  Sample
   implementation and use of MAKE-MAP:

   >>> (define (make-map maker0 setter0 length1 ref1 . more-length&ref-procs)
	 (do ((length-procs (list length1) (cons (car procs) length-procs))
	      (ref-procs (list ref1) (cons (cadr procs) ref-procs))
	      (procs more-length&ref-procs (cddr more-length&ref-procs)))
	     ((null? procs)
	      (let ((length-procs (reverse length-procs))
		    (ref-procs (reverse ref-procs)))
		(lambda (f x1 . more-args)
		  (let ((args (cons x1 more-args))
			(n (length1 x1)))
		    (for-each (lambda (length-proc arg)
				(if (not (= (length-proc arg) n))
				    (error "Arguments have different lengths")))
			      (cdr length-procs)
			      (cdr args))
		    (let ((result (maker0 n)))
		      (do ((i (- n 1) (- i 1)))
			  ((negative? i) result)
			  (setter0 result i (apply f (map (lambda (ref arg)
							    (ref arg i))
							  ref-procs
							  args)))))))))))
   make-map
   >>> (define map:string&list->vector
	 (make-map make-vector vector-set!
		   string-length string-ref
		   length list-ref))
   map:string&list->vector
   >>> (map:string&list->vector list "abcdef" '(0 1 2 3 4 5))
   #((#\a 0) (#\b 1) (#\c 2) (#\d 3) (#\e 4) (#\f 5))

   This proposal is substantially more general than generic MAP or FOR-EACH
   would be (since the length, ref, and setter procedures could perform
   arbitrary computations), and could be made equally efficient for the
   cases that could be handled by generic MAP and generic FOR-EACH.

As I implied in my original message, I did not really like the alternatives I
was presenting.  On the other hand, I thing Will's suggestion is a good one.
I, for one, put my stamp of approval on this proposal.  Additionally, I would
suggest that MAP and FOREACH remain bound to their current values for backward
compatibility. 



-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂13-Jul-89  1156	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  11:56:17 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10332;
          13 Jul 89 14:36 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 14:16:03 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09175;
          13 Jul 89 13:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00297; Thu, 13 Jul 89 13:40:59 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 13 Jul 89 13:26:05 edt
Received: from fafnir.think.com by Think.COM; Thu, 13 Jul 89 13:19:49 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 13 Jul 89 13:18:16 EDT
Received: by verdi.think.com; Thu, 13 Jul 89 13:18:12 EDT
Date: Thu, 13 Jul 89 13:18:12 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907131718.AA13175@verdi.think.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:03:23 PDT <8907130003.AA17137@spencer.cs.uoregon.edu>
Subject: last call: changes for R4RS

   Date: Wed, 12 Jul 89 17:03:23 PDT
   From: will@cs.uoregon.edu

   ...
   Section 6.5.5.
   P1178 has requested that MIN and MAX be renamed INF and SUP.  The rationale
   is that the somewhat surprising behavior of MIN and MAX when given mixed
   exact and inexact arguments would be more acceptable if their names were
   less familiar.  A second rationale is that the fact that the mathematical
   infimum and supremum operations, when given an infinite set of "arguments",
   may return a result that is not in the argument set; this is the surprising
   thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
   Background: In any case, a note will be added to point out and explain this
   behavior, which is required in order for exact results to be trusted.  It
   happens that MIN and MAX behave this way in Common Lisp as well, although
   the motivation was rather different.

I find this proposal quite startling.  The objection is that MIN and MAX
don't work properly, and therefore the solution is not to correct their
behavior but to change their names!?

The first rationale is bogus.  INF and SUP are standard mathematic
terminology.  It is clearly not a question of the terminology as such being
more or less familiar; one can only perhaps say that they are familiar to
fewer people.  This is an advantage?  Those who do know what INF and SUP are
supposed to mean will only be confused in exactly the same way by the faulty
behavior; those who do not know what they mean are likely to read the
description and then internalize them as "Oh, they are just like MIN and MAX,
only with funny names."

The second rationale is fallacious.  Indeed INF (resp. SUP) may return values
not in the set of arguments, but such result is guaranteed to be larger
(resp. smaller) than any of the arguments.  The example given fails to have
this property, and renaming MIN and MAX to INF and SUP will not repair the
problem.

Note that Common Lisp does not require MIN and MAX to have faulty
behavior; it merely permits it.  When comparing a rational and a float,
MIN and MAX may either apply floating-point contagion and then compare
(leading to possible anomalies), or treat the float as exact and possibly
return the rational, not converted to a float.

The problem is that MIN (or INF) is supposed to return the largest value that
is no smaller than any argument, and currently it fails to do so in Scheme.
So why not just say it that way?  Change the definition of MIN and MAX.
Don't give them new names that will have the same problem.

--Guy

∂13-Jul-89  1202	@mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu 	legion  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  12:01:53 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11183;
          13 Jul 89 14:45 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 14:22:39 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa10062;
          13 Jul 89 14:21 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00745; Thu, 13 Jul 89 14:20:57 EDT
Received: from REAGAN.AI.MIT.EDU (reagan.ai.mit.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 14:17:51 edt
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 235316; Thu 13-Jul-89 13:38:32 EDT
Date: Thu, 13 Jul 89 13:38 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: legion
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: <8907130005.AA17154@spencer.cs.uoregon.edu>
Message-Id: <19890713173826.2.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Wed, 12 Jul 89 17:05:39 PDT
    From: will@cs.uoregon.edu
    ...
    Pavel:
	    ...the user cannot portably assign to (or even rebind) variables
	    named ``if'', ``or'', ``delay'', or even ``unquote''...
    ...
    Jinx:
	We've been trying to fix this for quite a while.  It has not been
	fixed in R4RS because of political and technical problems having to do
	with the actual solutions suggested, not because we don't agree that
	this should be fixed.

    I am not convinced that it should be fixed.  So long as the set of
    syntactic keywords is very small, keeping them reserved contributes to
    readability.

Isn't this an argument against having macros at all?  Perhaps you have
always been opposed to macros and I never caught on?  Or perhaps I don't
understand your notion of "reserved":

		  It also appears that the various macro facilities that
    have been proposed would be significantly easier to use correctly if
    syntactic keywords remain reserved.

I suppose that if by "syntactic keywords remain reserved" you mean that I
am not allowed to introduce any new ones, then indeed all macro facilities
are equally easy to use -- because then you aren't allows to define any
macros at all!  Or perhap you draw some kind of distinction between
"syntactic keywords" (that only implementors can create) and "macros" (that
users define)?  Like perhaps I am not allowed to shadow IF, while I am
allowed to shadow PUSH (assuming PUSH is a macro that I myself defined)?  I
fail to see how this kind of distinction could contribute to anything
except confusion.

					 In fact, I believe that one of
    the main reasons we don't yet have a standard macro facility is that
    too much effort has been devoted to the difficulties that arise only
    when syntactic keywords can be shadowed by lexical variables.

I completely disagree.  I believe that one of the advantages of syntactic
closures is that it solves this problem using exactly the same mechanism it
uses to solve the problems of ordinary lexical variable shadowing.  The
"difficulties that arise only when syntactic keywords can be shadowed by
lexical variables" are subdued with no additional "effort" whatsoever.
This issue has nothing to do with why we don't have a standard macro
facility.

∂13-Jul-89  1233	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	Correction  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  12:33:07 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12614;
          13 Jul 89 15:14 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 15:10:26 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12295;
          13 Jul 89 15:04 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01670; Thu, 13 Jul 89 15:04:48 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 13 Jul 89 15:01:52 edt
Received: from fafnir.think.com by Think.COM; Thu, 13 Jul 89 15:04:46 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 13 Jul 89 15:03:12 EDT
Received: by verdi.think.com; Thu, 13 Jul 89 15:03:05 EDT
Date: Thu, 13 Jul 89 15:03:05 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907131903.AA13779@verdi.think.com>
To: gls@think.com
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Thu, 13 Jul 89 13:18:12 EDT <8907131718.AA13175@verdi.think.com>
Subject: Correction

   Date: Thu, 13 Jul 89 13:18:12 EDT
   From: Guy Steele <gls@Think.COM>
   ...
   The second rationale is fallacious.  Indeed INF (resp. SUP) may return values
   not in the set of arguments, but such result is guaranteed to be larger
   (resp. smaller) than any of the arguments.  ...

Sorry--that should have read "smaller (resp. larger)".  Editing error.
--Guy


∂13-Jul-89  1238	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Fluid binding   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  12:38:26 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12895;
          13 Jul 89 15:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 15:16:05 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12538;
          13 Jul 89 15:11 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01893; Thu, 13 Jul 89 15:11:36 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 15:08:23 edt
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA01156; Thu, 13 Jul 89 05:37:32 EDT
Received: from hpda.HP.COM by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA29989; Thu, 13 Jul 89 02:21:05 pdt
Received: from hpesogg (hpesogr) by hpda.HP.COM; Thu, 13 Jul 89 02:21:47 pdt
Message-Id: <8907130921.AA28558@hpda.HP.COM>
Received: by hpesogg; Thu, 13 Jul 89 02:20:39 pdt
Date: Thu, 13 Jul 89 02:20:39 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@hpesogg.hp.com
In-Reply-To: Pavel.pa@xerox.com's message of Wed, 12 Jul 89 11:00:52 PDT
Subject: Fluid binding
Reply-To: jinx%hpda@sde.hp.com

	1) MAKE-FLUID, FLUID-REF and FLUID-SET! don't have much to do with
	fluids, they have to do with cells (or boxes, as some other people
	call them).  As such, I would like them to be renamed to
	MAKE-CELL, CELL-REF, and CELL-SET!.

	Alternatively we could have both MAKE-CELL, CELL-REF, CELL-SET! to
	manipulate cells (the selector and mutator always provide the global
	value), and FLUID-CELL-REF, FLUID-CELL-SET! to access the current
	dynamic value.  Which of the accessors is written on top of which
	depends on whether the implementation is deep or shallow.

    When I first read this, it seemed very reasonable.  On later thought,
    however, I concluded otherwise.  For the first paragraph, I think that,
    conceptually, MAKE-FLUID, FLUID-REF and FLUID-SET! have nothing to do with
    cells at all.  Rather, they traffic in ``fluid variables'', opaque values
    that are the domain of the ``fluid environment'' (the range is locations,
    just as in the lexical environment).  Certainly one implementation of these
    procedures (and the one I would use) has MAKE-FLUID return a cell, as you
    suggest, but I think renaming them in terms of cells is a convolution of
    their abstract semantics with one particular concrete realization.

I think calling these objects fluid "variables" in the context of
other Scheme variables is very misleading.  Lexical (ordinary) Scheme
variables can't be aliased, since their addresses cannot be passed
around.  These can.  Lexical variables can only be affected by special
forms, these can be affected (and usually are) by procedures.  Lexical
variables are not first class, they are not even objects since they
are not expressible values.  Yours are first class objects.  It seems
to me that these fluid variables are much more similar to pairs than
to anything else in the language.

Let's put it another way.  In the absence of FLUID-LET, what is the
difference between your fluids and 1-slot records?  Your
interpretation is that there is a lot of hair in fluid environments,
etc.  Mine is simpler: there are cells, and there is a special form
which establishes a temporary/isolated contents for them.  Except for
efficiency, there is no reason why that could not be generalized to
pairs, vectors, etc.

    I have additional problems with idea in the second paragraph.  In a
    shallow-binding implementation, CELL-REF is identical to FLUID-CELL-REF
    while in a deep-binding implementation, their semantics is quite different.
    I think it unwise for the language semantics to change depending upon a
    property of the implementation that should be completely invisible.

The proposal was not completely serious, but you misunderstood it
anyway.

The semantics of these procedures would be the same whether the
implementation was shallow or deep.  They would be implemented
differently, and which set was primitive would also vary.

In a shallow implementation, FLUID-CELL-REF and FLUID-CELL-SET! would
be the procedures which merely dereferenced/mutated the cell, and
CELL-REF and CELL-SET! would be implemented on top of them.

In a deep implementation, CELL-REF and CELL-SET! would be the
primitive forms, and the fluid versions would be implemented on top
of them.

In either case, the fluid forms would access/mutate the current fluid
location, while the non-fluid forms would access the global location,
which is not the same as the physical cell.  The physical cell could
be accessed/mutated by %CELL-REF and %CELL-SET! which would be one of
the sets, depending on the implementation.  I did not suggest adding
the % procedures because they (and only they) are implementation
dependent.


    I don't object to this in principle, but I'd rather a somewhat simpler
    primitive that doesn't promote lists in this way.  For example, the
    following:

	(fluid-let ((<var-expr1> <val-expr1>)
		    (<var-expr2> <val-expr2>)
		    ...
		    (<var-exprN> <val-exprN>))
	   <body>)

    expands into

	(let ((var1 <var-expr1>)
	      (val1 <val-expr1>)
	      (var2 <var-expr2>)
	      (val2 <val-expr2>)
	      ...
	      (varN <var-exprN>)
	      (valN <val-exprN>)
	      (body-thunk (lambda () <body>)))

	   (with-fluid-binding var1 val1
	      (lambda ()
		 (with-fluid-binding var2 val2
		    (lambda ()
		       ...
			  (with-fluid-binding varN valN
			     body-thunk) ... )))))

    That is, I prefer a primitive that establishes exactly one binding at a
    time.  Also, since I conceive of this construct in terms of new bindings in
    the fluid environment, as opposed to changing the ``contents'' of anything,
    a prefer a name for the primitive that says so.  Thus my
    ``with-fluid-binding'' in contrast to Jinx's ``with-cell-contents''.

No problem, except with the name.  I was just suggesting that there
should be a basic procedure in terms of which FLUID-LET could be
expanded.

    Cedar Scheme is one of those implementations with an incompatible construct
    called FLUID-LET, so we would have to rewrite our code as well, but I don't
    anticipate it being very hard to do.  It seems to me that a very simple
    global query-replace could be used to change all of the uses of the old
    construct to use a different name.  That way, the new standard construct
    can use the stylistically correct and appropriate name and old code need
    not be rewritten.  For example, we might rename our old construct to
    SHALLOW-BIND...  (Unlike Scheme Xerox, our new implementation, Cedar Scheme
    does not support multiple threads of execution.)

Your solution assumes that you can reach all code that used FLUID-LET.
That is unlikely in a wide-spread implementation.

A second objection is purely based on the name.  I don't think that
FLUID-LET is a very appropriate name for your form, since it is (in my
mind, where all you are doing is data structure manipulation)
unrelated to LET.  I'd much rather have your form be called ISOLATE,
TEMPORARILY, or something like that.


∂13-Jul-89  1446	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	last call: changes for R4RS  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  14:46:20 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16307;
          13 Jul 89 17:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 17:04:27 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15743;
          13 Jul 89 17:03 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA00499; Thu, 13 Jul 89 17:03:15 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 13 Jul 89 17:00:18 edt
Date: Thu, 13 Jul 89 17:00:18 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907132100.AA22760@zurich.ai.mit.edu>
To: gls@think.com
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Thu, 13 Jul 89 13:18:12 EDT <8907131718.AA13175@verdi.think.com>
Subject: last call: changes for R4RS

   Date: Thu, 13 Jul 89 13:18:12 EDT
   From: Guy Steele <gls@think.com>

   I find this proposal quite startling.  The objection is that MIN and MAX
   don't work properly, and therefore the solution is not to correct their
   behavior but to change their names!?

   [...]

   The problem is that MIN (or INF) is supposed to return the largest value that
   is no smaller than any argument, and currently it fails to do so in Scheme.
   So why not just say it that way?  Change the definition of MIN and MAX.
   Don't give them new names that will have the same problem.

   --Guy

I disagree with the statements in these paragraphs because they
presume a definition of "proper" that I believe is incorrect.

All of this boils down to the meaning of `<', which is very poorly
defined for inexact numbers.  Because of this I don't believe that
statements like "don't work properly" and "fails to do so in Scheme"
can be applied here: given a fuzzy definition of `<' on inexact
numbers we are forced to accept a fuzzy definition of "largest" and
"smaller" as well, which further forces us to accept that the result
of `min' will be "correct" (by the definition above) modulo all the
fuzz.  This is different from it being correct in a mathematical
sense, but then, that is what the inexactness stuff is all about
anyway.

On the other hand, the above definition will normally hold, except
when inexact numbers are involved AND some implementation limit is
reached, in which case the arithmetic is specifically allowed to
return an inexact number which is mathematically incorrect; then it is
the user's responsibility to deal with the "incorrect" answer.

Perhaps a simpler solution to the whole problem is to add a prominent
warning note, like the one attached to `<' and friends, that warns
about the unreliability of `max' and `min' when inexact numbers are in
use.

∂13-Jul-89  1520	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  15:20:08 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17466;
          13 Jul 89 18:11 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 18:06:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17285;
          13 Jul 89 18:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01319; Thu, 13 Jul 89 18:03:48 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 13 Jul 89 18:00:51 edt
Received: from fafnir.think.com by Think.COM; Thu, 13 Jul 89 18:03:50 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 13 Jul 89 18:02:12 EDT
Received: by verdi.think.com; Thu, 13 Jul 89 18:02:10 EDT
Date: Thu, 13 Jul 89 18:02:10 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907132202.AA14486@verdi.think.com>
To: cph@zurich.ai.mit.edu
Cc: gls@think.com, will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Thu, 13 Jul 89 17:00:18 edt <8907132100.AA22760@zurich.ai.mit.edu>
Subject: last call: changes for R4RS

   Date: Thu, 13 Jul 89 17:00:18 edt
   From: cph@zurich.ai.mit.edu (Chris Hanson)

      Date: Thu, 13 Jul 89 13:18:12 EDT
      From: Guy Steele <gls@think.com>

      I find this proposal quite startling.  The objection is that MIN and MAX
      don't work properly, and therefore the solution is not to correct their
      behavior but to change their names!?

      [...]

      The problem is that MIN (or INF) is supposed to return the largest value that
      is no smaller than any argument, and currently it fails to do so in Scheme.
      So why not just say it that way?  Change the definition of MIN and MAX.
      Don't give them new names that will have the same problem.

      --Guy

   I disagree with the statements in these paragraphs because they
   presume a definition of "proper" that I believe is incorrect.

   All of this boils down to the meaning of `<', which is very poorly
   defined for inexact numbers.  Because of this I don't believe that
   statements like "don't work properly" and "fails to do so in Scheme"
   can be applied here: given a fuzzy definition of `<' on inexact
   numbers we are forced to accept a fuzzy definition of "largest" and
   "smaller" as well, which further forces us to accept that the result
   of `min' will be "correct" (by the definition above) modulo all the
   fuzz.  This is different from it being correct in a mathematical
   sense, but then, that is what the inexactness stuff is all about
   anyway.

   On the other hand, the above definition will normally hold, except
   when inexact numbers are involved AND some implementation limit is
   reached, in which case the arithmetic is specifically allowed to
   return an inexact number which is mathematically incorrect; then it is
   the user's responsibility to deal with the "incorrect" answer.

   Perhaps a simpler solution to the whole problem is to add a prominent
   warning note, like the one attached to `<' and friends, that warns
   about the unreliability of `max' and `min' when inexact numbers are in
   use.

Fine.  I am happy to agree with everything you say, and your final
suggestion is indeed probably the best solution.  The blame can be laid on
<, or on inexactness, if you wish.  My main point still stands: WHATEVER
the fundamental difficulty, or wherever you wish to place the blame, simply
renaming the functions to INF and SUP does not solve the problem; the
rationales advanced to support the renaming remain bogus.

--Guy

∂13-Jul-89  1537	@mc.lcs.mit.edu,@LIFE.ai.mit.edu:gjs@hpesogg.hp.com 	last call: changes for R4RS
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  15:37:12 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17712;
          13 Jul 89 18:22 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 18:12:24 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17477;
          13 Jul 89 18:11 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01377; Thu, 13 Jul 89 18:11:20 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 18:08:22 edt
Received: from hpda.HP.COM by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA15414; Thu, 13 Jul 89 15:10:58 pdt
Received: from hpesogg (hpcup18) by hpda.HP.COM; Thu, 13 Jul 89 15:08:35 pdt
Message-Id: <8907132208.AA24978@hpda.HP.COM>
Received: by hpesogg; Thu, 13 Jul 89 15:07:27 pdt
Date: Thu, 13 Jul 89 15:07:27 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
To: cph@zurich.ai.mit.edu
Cc: gls@think.com, will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Thu, 13 Jul 89 17:00:18 edt <8907132100.AA22760@zurich.ai.mit.edu>
Subject: last call: changes for R4RS

You say:

     Perhaps a simpler solution to the whole problem is to add a prominent
     warning note, like the one attached to `<' and friends, that warns
     about the unreliability of `max' and `min' when inexact numbers are in
     use.

I agree with your suggestion completely.  It is consistent with
everything else we are doing to do it that way.  We don't change the
name of "+" to make it less misleading, we warn about the possible
problems and limitations that appear.

∂13-Jul-89  1622	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	last call: changes for R4RS   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  16:22:02 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18935;
          13 Jul 89 19:16 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:13:04 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18724;
          13 Jul 89 19:05 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01904; Thu, 13 Jul 89 19:05:45 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:02:41 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA29641; Thu, 13 Jul 89 16:04:41 PDT
Date: Thu, 13 Jul 89 16:04:41 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907132304.AA29641@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Wed, 12 Jul 89 17:03:23 PDT <8907130003.AA17137@spencer.cs.uoregon.edu>
Subject: last call: changes for R4RS


ciao,

In the section entitled Procedure calls (4.1.3):

"The operator and operand expressions are evaluated (in an indeterminate order)
and the resulting procedure is passed the resulting arguments."

Is the intention here that the order can be any order as long as it is either
"right-to left" or "left-to-right" or is an implementation truely free to use
any order (which could lead to interleaving on a multi-process implementation)?

(peace chance)

	mas

∂13-Jul-89  1635	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Confusion  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  16:35:04 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19225;
          13 Jul 89 19:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:13:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18782;
          13 Jul 89 19:08 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01922; Thu, 13 Jul 89 19:08:10 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:05:13 edt
Received: from hpda.HP.COM by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA16657; Thu, 13 Jul 89 16:07:40 pdt
Received: from hpesogg (hpesogr) by hpda.HP.COM; Thu, 13 Jul 89 16:05:58 pdt
Message-Id: <8907132305.AA01682@hpda.HP.COM>
Received: by hpesogg; Thu, 13 Jul 89 16:04:39 pdt
Date: Thu, 13 Jul 89 16:04:39 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: willc@cs.uoregon.edu
Cc: gls@think.com, rrrs-authors@hpesogg.hp.com
Subject: Confusion
Reply-To: jinx%hpda@sde.hp.com

I'm confused about a lot of things.  Perhaps I should have read Will's
original message more carefully, rather than assume that I knew what
was going on.

       P1178 has requested that MIN and MAX be renamed INF and SUP.  The rationale
       is that the somewhat surprising behavior of MIN and MAX when given mixed
       exact and inexact arguments would be more acceptable if their names were
       less familiar.  A second rationale is that the fact that the mathematical
       infimum and supremum operations, when given an infinite set of "arguments",
       may return a result that is not in the argument set; this is the surprising
       thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
       Background: In any case, a note will be added to point out and explain this
       behavior, which is required in order for exact results to be trusted.  It
       happens that MIN and MAX behave this way in Common Lisp as well, although
       the motivation was rather different.

As far as I understand it (and GJS agrees with me), the example Will
shows could only be correct in an implementation where 
(>= 9.999999999999998e99 #e1e100) is true.  If it isn't, the
implementation of MAX/SUP is in error.  

If (>= 9.999999999999998e99 #e1e100) holds, then it is not surprising
that MAX/SUP returns 9.999999999999998e99.  Perhaps users of such an
implementation should flame at the implementor of >= or of the numeric
printing routine.

The rationale for the renaming these procedures is that MAX and MIN
have a common connotation of returning one of the elements of the
input set.  Clearly these procedures don't do this.  They are more
like the mathematical definition of SUP and INF which are defined to
return the smallest value >= (or <=) than any of the input parameters.

A different way to look at this is that numbers are not ordered in a
line, but in a lattice.  Along the exact and the inexact dimension,
the results are as expected, but when mixing them, we look for the SUP
(INF) in the lattice, so again, the names make sense.


    The second rationale is fallacious.  Indeed INF (resp. SUP) may return values
    not in the set of arguments, but such result is guaranteed to be larger
    (resp. smaller) than any of the arguments.  The example given fails to have
    this property, and renaming MIN and MAX to INF and SUP will not repair the
    problem.

    The problem is that MIN (or INF) is supposed to return the largest value that
    is no smaller than any argument, and currently it fails to do so in Scheme.
    So why not just say it that way?  Change the definition of MIN and MAX.
    Don't give them new names that will have the same problem.

The rationale is not fallacious if you understand that larger or
smaller mean >= and <=, not the expected >= and <= that you compute by
looking at the printed representation.  On a good implementation these
two notions of >= should be very close.

If the implementation returns true to the query 
(>= 9.999999999999998e99 #e1e100), it is consistent, and is doing what
you expect (modulo it's poor definition of >= or of number->string).

∂13-Jul-89  1721	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	last call: changes for R4RS  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  17:21:02 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19850;
          13 Jul 89 19:47 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:39:48 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19529;
          13 Jul 89 19:35 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA02199; Thu, 13 Jul 89 19:35:13 EDT
Received: from localhost by zurich.ai.mit.edu; Thu, 13 Jul 89 19:32:16 edt
Date: Thu, 13 Jul 89 19:32:16 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907132332.AA23738@zurich.ai.mit.edu>
To: shaff@sesame.stanford.edu
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Mike Shaff's message of Thu, 13 Jul 89 16:04:41 PDT <8907132304.AA29641@sesame.Stanford.EDU>
Subject: last call: changes for R4RS

   Date: Thu, 13 Jul 89 16:04:41 PDT
   From: Mike Shaff <shaff@sesame.stanford.edu>


   ciao,

   In the section entitled Procedure calls (4.1.3):

   "The operator and operand expressions are evaluated (in an indeterminate order)
   and the resulting procedure is passed the resulting arguments."

   Is the intention here that the order can be any order as long as it is either
   "right-to left" or "left-to-right" or is an implementation truely free to use
   any order (which could lead to interleaving on a multi-process implementation)?

   (peace chance)

	   mas

Certainly the implementation is free to use any SEQUENTIAL order.
It has never been clear to me whether the specification permits
simultaneous evaluation of two different arguments.

∂13-Jul-89  1726	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	last call: changes for R4RS   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  17:25:56 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20401;
          13 Jul 89 19:56 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:50:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19803;
          13 Jul 89 19:45 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02291; Thu, 13 Jul 89 19:45:08 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:42:04 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA29795; Thu, 13 Jul 89 16:43:26 PDT
Date: Thu, 13 Jul 89 16:43:26 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907132343.AA29795@sesame.Stanford.EDU>
To: jinx%hpda@sde.hp.com
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Thu, 13 Jul 89 16:29:25 pdt <8907132333.AA03563@hpda.HP.COM>
Subject: last call: changes for R4RS


ciao,

In an almost immediate response from both Jinx and Chris:

   From: Guillermo J. Rozas <jinx@hpesogg.hp.com>

   Any sequential order is the intention.  Interleaving should not be
   allowed because there are no locking primitives to serialize side
   effects.

   The MIT Scheme compiler chooses an order that it thinks is convenient
   for any given combination, but will not interleave the computation
   (unless interleaving does not make a difference).


   From: cph@zurich.ai.mit.edu (Chris Hanson)

   Certainly the implementation is free to use any SEQUENTIAL order.
   It has never been clear to me whether the specification permits
   simultaneous evaluation of two different arguments.


This being the case (and presuming this is the generally agreed thinking)
shouldn't this choice be made more explicit.  I think the absence of said
locking primitives (at the current time) is an issue whose ramifications should
be noted.

(peace chance)

	mas

∂13-Jul-89  1734	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: evaluation order  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  17:34:01 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20762;
          13 Jul 89 20:05 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:55:58 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20133;
          13 Jul 89 19:54 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02362; Thu, 13 Jul 89 19:54:12 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:51:13 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 89 16:38:06 PDT
Date: Thu, 13 Jul 89 16:39:54 PDT
From: Pavel.pa@xerox.com
Subject: Re: evaluation order
In-Reply-To: <8907132304.AA29641@sesame.Stanford.EDU>
To: Mike Shaff <shaff@sesame.stanford.edu>
Cc: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890713-163806-2604@Xerox>

I believe the intent is that the operator and operands are evaluated one at
a time in some order.  The order need not be either right-to-left or
left-to-right. You can, in some cases, perform the evaluation in parallel,
but the result must be ``serializable'', to steal a term from transaction
systems; that is, the effect must be indistinguishable from some
non-parallel, non-interleaved evaluation.

	Pavel

∂13-Jul-89  1747	@mc.lcs.mit.edu,@LIFE.ai.mit.edu:jinx@hpesogg.hp.com 	last call: changes for R4RS    
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  17:47:28 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21151;
          13 Jul 89 20:20 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 19:34:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19431;
          13 Jul 89 19:33 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02185; Thu, 13 Jul 89 19:33:21 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 19:30:16 edt
Received: from hpda.HP.COM by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA17182; Thu, 13 Jul 89 16:32:47 pdt
Received: from hpesogg (hpesogr) by hpda.HP.COM; Thu, 13 Jul 89 16:33:15 pdt
Message-Id: <8907132333.AA03563@hpda.HP.COM>
Received: by hpesogg; Thu, 13 Jul 89 16:29:25 pdt
Date: Thu, 13 Jul 89 16:29:25 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: shaff@sesame.stanford.edu
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Mike Shaff's message of Thu, 13 Jul 89 16:04:41 PDT <8907132304.AA29641@sesame.Stanford.EDU>
Subject: last call: changes for R4RS
Reply-To: jinx%hpda@sde.hp.com


    ciao,

    In the section entitled Procedure calls (4.1.3):

    "The operator and operand expressions are evaluated (in an indeterminate order)
    and the resulting procedure is passed the resulting arguments."

    Is the intention here that the order can be any order as long as it is either
    "right-to left" or "left-to-right" or is an implementation truely free to use
    any order (which could lead to interleaving on a multi-process implementation)?

    (peace chance)

	    mas

Any sequential order is the intention.  Interleaving should not be
allowed because there are no locking primitives to serialize side
effects.

The MIT Scheme compiler chooses an order that it thinks is convenient
for any given combination, but will not interleave the computation
(unless interleaving does not make a difference).

∂13-Jul-89  1756	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@bloom.la.tek.com 	Re: last call: changes for R4RS 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  17:56:30 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21557;
          13 Jul 89 20:39 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 20:35:55 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21436;
          13 Jul 89 20:31 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02735; Thu, 13 Jul 89 20:31:39 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Thu, 13 Jul 89 20:28:40 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa10349; 13 Jul 89 18:55 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
	id AA28581; Thu, 13 Jul 89 15:57:27 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA18298; Thu, 13 Jul 89 15:51:04 PDT
Received: by bloom.LA.TEK.COM (1.2/6.24)
	id AA01721; Thu, 13 Jul 89 15:55:52 pdt
Message-Id: <8907132255.AA01721@bloom.LA.TEK.COM>
To: Guy Steele <gls@think.com>
Cc: cph@zurich.ai.mit.edu, will%cs.uoregon.edu@relay.cs.net, 
    rrrs-authors@zurich.ai.mit.edu
Subject: Re: last call: changes for R4RS
In-Reply-To: Your message of Thu, 13 Jul 89 18:02:10 EDT.
	     <8907132202.AA14486@verdi.think.com>
Date: 13 Jul 89 15:55:47 PDT (Thu)
From: kend%bloom.la.tek.com@relay.cs.net

Guy says:

.. renaming the functions to INF and SUP does not solve the problem...

The point in the renaming is not to change a suprising behavior, but
to warn that the specified behavior is not in accord with the `simple'
behavior `expected' from MIN and MAX.  The IEEE draft expects to cross
reference MAX to SUP and MIN to INF in the index and point out potential
suprises caused by the definitions involved so that a user expecting
algebraic laws to hold is educated to a more refined model with respect to
the realities of machine arithmetic.

-Ken Dickey		kend@mrloog.LA.TEK.COM

∂13-Jul-89  1812	@mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com 	Arg evaluation order   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  18:12:20 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21742;
          13 Jul 89 20:50 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 20:47:01 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21614;
          13 Jul 89 20:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02865; Thu, 13 Jul 89 20:42:47 EDT
Received: from hobbes.ads.com ([128.229.32.19]) by zurich.ai.mit.edu; Thu, 13 Jul 89 20:39:48 edt
Received: by hobbes.ads.com (5.59/1.11)
	id AA00370; Thu, 13 Jul 89 17:39:34 PDT
Date: Thu, 13 Jul 89 17:39:34 PDT
From: Andy Cromarty <andy@ads.com>
Message-Id: <8907140039.AA00370@hobbes.ads.com>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Arg evaluation order
Cc: andy@ads.com, jinx%hpda@sde.hp.com

MAS writes:

        In the section entitled Procedure calls (4.1.3):

	"The operator and operand expressions are evaluated (in an 
	indeterminate order) and the resulting procedure is passed
	the resulting arguments."

	Is the intention here that the order can be any order as
	long as it is either "right-to left" or "left-to-right" or
	is an implementation truely free to use any order (which
	could lead to interleaving on a multi-process
	implementation)?  

Jinx replies:

    Any sequential order is the intention.  Interleaving should not be
    allowed because there are no locking primitives to serialize side
    effects.

    The MIT Scheme compiler chooses an order that it thinks is convenient
    for any given combination, but will not interleave the computation
    (unless interleaving does not make a difference).


This response surprised and, upon reflection, baffled me sufficiently
to raise me out of my torpor.  If we do not specify an evaluation
order, what would be the purpose of requiring sequentiality for
evaluation order?  This would seem to have the principal "benefit"
of permitting explicitly nonportable code to be written, in that any
reliance on evaluation order on the part of the programmer is
guaranteed to be implementation-specific.

If evaluation order is desirable, shouldn't we specify it?  If it is
undesirable or an area of legitimate experimentation (which position
I favor), shouldn't we leave it entirely unspecified, so that
compiler writers may experiment with it freely?   As a programmer, I
might well wish to interleave evaluations in an indeterminate way;
and locking or other appropriate means of achieving serialization
can be imposed by the compiler for the multiprocessor, in those
cases where the programmer "requests" it by using existing
primitives for specifying sequential evaluation.  (Note that we
already have constructs that can be used to impose sequentiality,
e.g. to order side-effecting operations--- including at least LAMBDA
bodies, the LET-family bodies, DO bodies, COND, CASE, and BEGIN.)

	        			asc

∂13-Jul-89  1820	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Arg evaluation order 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  18:20:52 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21932;
          13 Jul 89 21:02 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 20:58:03 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21811;
          13 Jul 89 20:55 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02971; Thu, 13 Jul 89 20:55:11 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 13 Jul 89 20:52:14 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA19542; Thu, 13 Jul 89 17:54:49 pdt
Message-Id: <8907140054.AA19542@sde.hp.com>
Received: by hpesogg; Thu, 13 Jul 89 17:53:42 pdt
Date: Thu, 13 Jul 89 17:53:42 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: andy@ads.com
Cc: rrrs-authors@zurich.ai.mit.edu, andy@ads.com
In-Reply-To: Andy Cromarty's message of Thu, 13 Jul 89 17:39:34 PDT <8907140039.AA00370@hobbes.ads.com>
Subject: Arg evaluation order
Reply-To: jinx%hpesogg@sde.hp.com

   This response surprised and, upon reflection, baffled me sufficiently
   to raise me out of my torpor.  If we do not specify an evaluation
   order, what would be the purpose of requiring sequentiality for
   evaluation order?  This would seem to have the principal "benefit"
   of permitting explicitly nonportable code to be written, in that any
   reliance on evaluation order on the part of the programmer is
   guaranteed to be implementation-specific.

   If evaluation order is desirable, shouldn't we specify it?  If it is
   undesirable or an area of legitimate experimentation (which position
   I favor), shouldn't we leave it entirely unspecified, so that
   compiler writers may experiment with it freely?   As a programmer, I
   might well wish to interleave evaluations in an indeterminate way;
   and locking or other appropriate means of achieving serialization
   can be imposed by the compiler for the multiprocessor, in those
   cases where the programmer "requests" it by using existing
   primitives for specifying sequential evaluation.  (Note that we
   already have constructs that can be used to impose sequentiality,
   e.g. to order side-effecting operations--- including at least LAMBDA
   bodies, the LET-family bodies, DO bodies, COND, CASE, and BEGIN.)

The problem is that there are perfectly portable sequential programs
which work when ANY sequential order is used, but not when
interleaved.  Consider, for example,

(define (count-nodes! graph-node)
  (if (node-marked? graph-node)
      0
      (begin
	(node-mark! graph-node)
	(1+ (if (node-leaf? graph-node)
		0
		(+ (count-nodes! (node-left graph-node))
		   (count-nodes! (node-right graph-node))))))))

And now think of what happens when a node has the same (eq?) left and
right components, and the arguments to + are interleaved.

∂13-Jul-89  1925	@mc.lcs.mit.edu,@life.ai.mit.edu:andy@ads.com 	Re:  Arg evaluation order   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  19:25:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23489;
          13 Jul 89 22:16 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 13 Jul 89 22:13:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa23305;
          13 Jul 89 22:08 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03672; Thu, 13 Jul 89 22:08:10 EDT
Received: from hobbes.ads.com ([128.229.32.19]) by zurich.ai.mit.edu; Thu, 13 Jul 89 22:05:11 edt
Received: by hobbes.ads.com (5.59/1.11)
	id AA00427; Thu, 13 Jul 89 19:06:39 PDT
Date: Thu, 13 Jul 89 19:06:39 PDT
From: Andy Cromarty <andy@ads.com>
Message-Id: <8907140206.AA00427@hobbes.ads.com>
To: jinx%hpesogg@sde.hp.com
Subject: Re:  Arg evaluation order
Cc: andy@ads.com, rrrs-authors@zurich.ai.mit.edu

Jinx writes:

	The problem is that there are perfectly portable sequential programs
	which work when ANY sequential order is used, but not when
	interleaved.  Consider, for example,

	(define (count-nodes! graph-node)
	  (if (node-marked? graph-node)
	      0
	      (begin
		(node-mark! graph-node)
		(1+ (if (node-leaf? graph-node)
			0
			(+ (count-nodes! (node-left graph-node))
			   (count-nodes! (node-right graph-node))))))))

	And now think of what happens when a node has the same (eq?) left and
	right components, and the arguments to + are interleaved.


So let's see.  I infer you are walking a binary cyclic digraph
(otherwise the node-mark! procedure isn't needed), in a
multiprocessor shared-memory environment (otherwise there's no race
condition to resolve).  (Knowing this, you might trivially solve
the problem with an atomic test-and-set replacing node-marked? and
node-mark!, but this is cheating, given my suggestion that implicit
serialization should be enough with the compiler generating the
needed serialization code).

Now, a compiler should be able trivially to determine that node-mark!
is a (potential) mutator, and hence that count-nodes! is a mutator; 
thus determining that there is a race condition just in case
	(eq? (node-left graph-node) (node-right graph-node))
is straightforward, although it's admittedly potentially expensive 
for a compiler to test for in general (but that's the compiler-writer's
business, isn't it, and perhaps the compiler executes combinatorically
quickly on the same multiprocessor for which it generates code).  Of course, 
once the compiler has determined that there is a race condition, there 
is nothing to prevent it from generating code that serializes the
evaluation of +'s args---in any order it deems convenient at the
time.  It even could produce code that tests the eq?-ness of +'s
args and serializes conditionally; this seems to work, although it
has the weakness that it is combinatorically expensive to test for 
race conditions of all left's vs. all right's (needed just in case one
processor executes + faster than another).  But a sufficiently "smart"
compiler also might be able to determine when the graph structure in
question is "small" and will not be grown during execution, in which
case the combinatoric cost of completely checking eq?-ness
(especially if it's just once per graph) is uncompelling and concurrent
unserialized execution could be a win in cases where no cells of the graph 
are found to be eq?, especially where (say) node-leaf? is a relatively
expensive operation to perform.  (This cost-comparison example is somewhat
strained, but then I didn't get to choose the example application. :-)

Note that under the interpretation I proposed, nothing prevents you
from writing a compiler that happens to serialize in whatever order
you find moral, whereas under your intepretation, I might be prohibited
from experimenting with compilers that leave the evaluation order 
undefined and make their own decisions about evaluation ordering 
dynamically.  Also, it is possible (I'm not sure) that your
counterexample begs the question of whether we automatically should
expect "old" sequential code always to run on a shared-memory
multiprocessor without rethinking or redesigning the code.
Apart from the incidental convenience this offers, I'm not sure why 
that would be a reasonable expectation, any more than (say) we would 
expect IBM/360 assembler code to run on a Sun.  Perhaps it's enough to
expect that code written for languages *designed* to execute in both
environments (e.g. FORTRAN-66, for the example of the 360 and Sun) need 
no redesign; in my view Scheme presently does not qualify as a language
explicitly designed to work both in uniprocessor and shared-memory
multiprocessor environments.  (After all, we still have people advocating
that a construct named WHEN, with all its colloquial intuitive appeal for
capturing time dependency, be [opinion warning:] wasted as syntactic sugar
for IF.)

					asc

∂13-Jul-89  2140	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Arg evaluation order 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  21:40:38 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27568;
          14 Jul 89 0:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 00:25:00 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa27410;
          14 Jul 89 0:18 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01280; Fri, 14 Jul 89 00:18:40 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 14 Jul 89 00:15:44 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA22738; Thu, 13 Jul 89 21:18:23 pdt
Message-Id: <8907140418.AA22738@sde.hp.com>
Received: by hpesogg; Thu, 13 Jul 89 21:17:49 pdt
Date: Thu, 13 Jul 89 21:17:49 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: andy@ads.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Andy Cromarty's message of Thu, 13 Jul 89 19:06:39 PDT <8907140206.AA00427@hobbes.ads.com>
Subject:  Arg evaluation order
Reply-To: jinx%hpesogg@sde.hp.com


    So let's see.  I infer you are walking a binary cyclic digraph
    (otherwise the node-mark! procedure isn't needed), in a
    multiprocessor shared-memory environment (otherwise there's no race
    condition to resolve).  (Knowing this, you might trivially solve
    the problem with an atomic test-and-set replacing node-marked? and
    node-mark!, but this is cheating, given my suggestion that implicit
    serialization should be enough with the compiler generating the
    needed serialization code).

This has nothing to do with parallel processing or race conditions, it
has to do with enforcing the consistency of data structures.  If the
language allows interleaved evaluation, there is nothing that prevents
a compiler for a SEQUENTIAL implementation from interleaving the
calls, by open coding, for example, and ignore the interaction between
tests and side effects on "different" branches of the computation.

    Now, a compiler should be able trivially to determine that node-mark!
    is a (potential) mutator, and hence that count-nodes! is a mutator; 
    thus determining that there is a race condition just in case
	    (eq? (node-left graph-node) (node-right graph-node))
    is straightforward, although it's admittedly potentially expensive 
    ....

Your argument suffers from two common bugs:

1) The "infinitely smart compiler" bug.

2) Separate compilation (not applicable to my simple example), which means
that the compiler can hardly ever tell anything about side effects
between two operands.

Besides, what are you really arguing?  It seems that you are saying
that the current requirement is fine, since a sufficiently smart
compiler will be able to take advantage of interleaving in those cases
where it won't compromise the sematics.

Please, let's make the "infinitely smart compiler" optional, and have
it do a little extra work when it wants to interleave, rather than
allow interleaving in the sequential language, eliminating
predictability.

    Note that under the interpretation I proposed, nothing prevents you
    from writing a compiler that happens to serialize in whatever order
    you find moral, whereas under your intepretation, I might be prohibited
    from experimenting with compilers that leave the evaluation order 
    undefined and make their own decisions about evaluation ordering 
    dynamically.

That is correct.  If you are designing a parallel language, you will
have to specify in which way I can control the evaluation, but that
takes you outside of Scheme.  Such a language would NOT be Scheme.
Let's not put everything and the kitchen sink into this language.

∂13-Jul-89  2211	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #158 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 13 Jul 89  22:11:13 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27730;
          14 Jul 89 0:39 EDT
Date: 14 JUL 89  00:11:00 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #158 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907140039.aa27730@mintaka.lcs.mit.edu>

Scheme Digest #158                             14 JUL 89  00:11:00 EDT

Today's Topics:

        Opening files with Cscheme

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

Date: 13 Jul 89 18:36:08 GMT
From: Les Milash <unicads!les@boulder.colorado.edu>
Subject: Opening files with Cscheme
Message-Id: <553@unicads.UUCP>

i have a thing called CScheme, which i love.  i have a manual called
RRRS.  i have a problem.

i'm trying to write a program that's c-preprocessor compatable, in that
it takes a -I/parameter -I/that/lists/a/bunch -I/of/directories/that
include files might be in.  so when the code includes foo.h i have to
find the first one of
	/parameter/foo.h
	/that/lists/a/bunch/foo.h
	/of/directories/that/foo.h
that exists.

RRRS talks about (open-input-file "filename") but if the file doesn't exist
i get an "out of range with "filename"" error and the program stops.

is there a way to figure out if some file exists without crashing?  or
some way to substitute some better error behaviour (i'd just as soon
have it return '() or #!the-you-screwed-up-object or something).
i have the CScheme source and am not adverse to making myself un-scheme-
compatable (but i imagine that scheme can do what i want somehow (else
what good is it?))

thanks in advance for the assistance!

Les Milash

wow! with a language like this, i might even be able to handle 
a shared-memory multiprocessor!

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

End of Scheme Digest
********************

∂14-Jul-89  0433	@mc.lcs.mit.edu,@life.ai.mit.edu:gjs@hpesogg.hp.com 	D. Press, Ing.   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 14 Jul 89  04:33:29 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04164;
          14 Jul 89 7:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 07:20:29 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04097;
          14 Jul 89 7:15 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03750; Fri, 14 Jul 89 07:15:51 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 14 Jul 89 07:12:54 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA06325; Fri, 14 Jul 89 04:15:32 pdt
Message-Id: <8907141115.AA06325@sde.hp.com>
Received: by hpesogg; Fri, 14 Jul 89 04:14:57 pdt
Date: Fri, 14 Jul 89 04:14:57 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
To: rrrs-authors@hpesogg.hp.com
Subject: D. Press, Ing.


A rather exercised character, D. Press, Ing. has been following the
activity of the Scheme mailing list.  He has communicated to us the
following commentary on the recent controversies.

			      GJS & HAL



I'm confused about the unreliability of `max' and `min' when inexact
numbers are not ordered in a line, but in a lattice.  Along the exact
and inexact arguments would be more acceptable if their names were
less familiar.  A second rationale is that the fact that the
mathematical infimum and supremum operations--- including at least
LAMBDA bodies, the LET-family bodies, DO not specify an indeterminate
order) and the resulting procedure is cheating, given my suggestion
that implicit serialization should be enough with an atomic
test-and-set replacing node-marked? and node-mark!  is a (potential)
mutator, and hence that count-nodes! is a mutator; thus determining
that there is convenient for any given combination, but will not
interleave the computation (unless interleaving does not make a
difference).

The point in the renaming is not to change a compiler should be able
trivially to determine that node-mark!  is a (potential) mutator, and
now think of what happens when a node has the same (eq?) left" or of
the numeric printing routine.

The rationale is that the somewhat surprising behavior of MIN and MAX
when given mixed exact and inexact arguments would be more acceptable
if their names were less familiar.  A second rationale is that the
somewhat surprising behavior of MIN and MAX when given mixed exact and
inexact arguments to + are interleaved.

So let's see.  I infer you are walking a common connotation of
returning one of the elements of what happens when a node has the
problem...
 
A second rationale is that the fact that the mathematical infimum and
supremum operations, when given an infinite set of "arguments", may
return a result that is not in the argument set; this is cheating,
given my suggestion that implicit serialization should be enough with
your suggestion completely. A second rationale is that the fact that
the mathematical infimum and supremum operations, when given an
infinite set of "arguments", may return a result that is not in the
argument set; this is cheating, given my suggestion that implicit
serialization should be enough with your suggestion completely.

"The operator and, upon reflection, baffled me sufficiently to raise
me out of my simple example), which means that the compiler can hardly
ever tell anything about side effects between tests and renaming MIN
and MAX to INF and SUP will not repair the problem is that there are
perfectly portable sequential programs which work when ANY sequential
order is the intention.  Interleaving should not be allowed because
there are you really arguing?  It seems that you are saying that the
current requirement is fine, since a sufficiently smart compiler will
be able to take advantage of interleaving in those cases where it
won't compromise the sematics.

			    D. Press, Ing.

∂14-Jul-89  0903	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	Released Report
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 14 Jul 89  09:03:22 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07281;
          14 Jul 89 11:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 11:54:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07215;
          14 Jul 89 11:53 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06100; Fri, 14 Jul 89 11:53:19 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 11:50:17 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA03006; Fri, 14 Jul 89 08:52:29 PDT
Date: Fri, 14 Jul 89 08:52:29 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907141552.AA03006@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Released Report


ciao,

Will writes:
  
  I have promised the P1178 editors that I will deliver the final draft of
  the R4RS to them by the end of July so they can incorporate it into the
  IEEE standard they're drafting.  So if you want to influence the R4RS,
  you'd better send mail to RRRS-AUTHORS within the next two weeks.

I am definitely in favor of moving forward on issues and getting the report out
to the public, however the latest version of the report that I have (via
zurich) still seems to have some areas that I thought were to be part of the
document (per L&FP such things as macros, name regularization, etc were to be
'rubber stamped' by the group).  Is there to be another beta release *before*
the submission to P1178?  If not, what happened to those and other favorites?

(peace chance)

	mas

∂15-Jul-89  0907	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	Released Report
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89  09:07:36 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02656;
          15 Jul 89 11:51 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Jul 89 11:54:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07215;
          14 Jul 89 11:53 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06100; Fri, 14 Jul 89 11:53:19 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 11:50:17 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA03006; Fri, 14 Jul 89 08:52:29 PDT
Date: Fri, 14 Jul 89 08:52:29 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907141552.AA03006@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Released Report


ciao,

Will writes:
  
  I have promised the P1178 editors that I will deliver the final draft of
  the R4RS to them by the end of July so they can incorporate it into the
  IEEE standard they're drafting.  So if you want to influence the R4RS,
  you'd better send mail to RRRS-AUTHORS within the next two weeks.

I am definitely in favor of moving forward on issues and getting the report out
to the public, however the latest version of the report that I have (via
zurich) still seems to have some areas that I thought were to be part of the
document (per L&FP such things as macros, name regularization, etc were to be
'rubber stamped' by the group).  Is there to be another beta release *before*
the submission to P1178?  If not, what happened to those and other favorites?

(peace chance)

	mas

∂15-Jul-89  0933	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #159 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89  09:33:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02876;
          15 Jul 89 12:12 EDT
Date: 15 JUL 89  12:01:47 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #159 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907151212.aa02876@mintaka.lcs.mit.edu>

Scheme Digest #159                             15 JUL 89  12:01:47 EDT

Today's Topics:

        Opening files with Cscheme

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

Date: Fri, 14 Jul 89 10:38:49 edt
From: Chris Hanson <cph@altdorf.ai.mit.edu>
Message-Id: <8907141438.AA01871@altdorf.ai.mit.edu>
Subject: Opening files with Cscheme

   Date: 13 Jul 89 18:36:08 GMT
   From: Les Milash <unicads!les@boulder.colorado.edu>

   i have a thing called CScheme, which i love.  i have a manual called
   RRRS.  i have a problem.

   is there a way to figure out if some file exists without crashing?

The procedure `file-exists?' does what you want.  It takes a single
argument which is a filename.

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

End of Scheme Digest
********************

∂15-Jul-89  1102	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Arg evaluation order 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89  11:02:35 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03930;
          15 Jul 89 13:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:44:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00388;
          14 Jul 89 14:44 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08472; Fri, 14 Jul 89 14:44:38 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 14:41:35 edt
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA07930; Fri, 14 Jul 89 14:09:18 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA14308; Fri, 14 Jul 89 11:08:31 pdt
Message-Id: <8907141808.AA14308@sde.hp.com>
Received: by hpesogg; Fri, 14 Jul 89 11:07:53 pdt
Date: Fri, 14 Jul 89 11:07:53 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: sfk@sknight.hpl.hp.com
Cc: andy@ads.com, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Steve Knight's message of Fri, 14 Jul 89 9:59:35 BST <8907140903.AA18355@otter.hpl.hp.com>
Subject: Arg evaluation order
Reply-To: jinx%hpesogg@sde.hp.com

   From: Steve Knight <sfk@sknight.hpl.hp.com>
   Date: Fri, 14 Jul 89 9:59:35 BST
   X-Mailer: Elm [version 2.0 beta]

   > This has nothing to do with parallel processing or race conditions, it
   > has to do with enforcing the consistency of data structures.

   I agree on this point.  Permitting arguments to be evaluated in arbitrary
   order makes the compiler writer's life easier at the expense of the language
   user. The belief that this compromise is acceptable stems from two sources, I
   think.

   1.	many other languages specify the absence of an evaluation order,

   2.	the loss of efficiency when evaluation order is specified.

   However, this ambiguity gives rise to a distinct class of potential program
   defects.

   Steve

I think you are confusing two different possibilities here:

1) Not specifying the order of argument evaluation, but requiring
arguments to be evaluated sequentially.  Let's call this option
"reordering" of argument evaluation.

2) Allowing interleaving of argument evaluation, ie. evaluate part of
one, then part of another, then part of yet another, then go back to
the first and continue, etc.  Let's called this "interleaving" of
argument evaluation.

The current report allows reordering, but not interleaving.  Andy was
asking for the language either to pick a particular order or to allow
interleaving.

The main reason for not specifying an order of argument evaluation is
not the loss of efficiency, but rather to discourage programs that
depend on any particular order, since they are at best obscure.  Some
of the hardest bugs to find that I have had to deal with arose from
depending on the order of argument evaluation.

Note that current implementations differ in the way they evaluate
their arguments.  Most evaluate left to right, but the MIT Scheme
interpreter, for example, evaluates from right to left.  Agreeing on a
particular order, besides undesirable, would probably be politically
infeasible at this point.

I also dispute your statement that the compiler writer's job becomes
easier if arguments can be evaluated in any order.  It is certainly
easier (although sometimes less efficient) to pick a particular order
and stick to it.  Most compilers do this, and they turn out perfectly
efficient code.  On the other hand, if the language does not specify
the order of argument evaluation, deciding when reordering is allowed
becomes trivial.

∂15-Jul-89  1210	@mc.lcs.mit.edu,@LIFE.ai.mit.edu:gls@think.com 	[postmaster@ames.UUCP: Returned mail: User unknown] 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89  12:10:26 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04564;
          15 Jul 89 14:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:53:15 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02145;
          14 Jul 89 16:54 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01025; Fri, 14 Jul 89 16:54:55 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Fri, 14 Jul 89 15:54:44 edt
Received: from fafnir.think.com by Think.COM; Fri, 14 Jul 89 15:57:44 EDT
Received: from verdi.think.com by fafnir.think.com; Fri, 14 Jul 89 15:56:13 EDT
Received: by verdi.think.com; Fri, 14 Jul 89 15:56:12 EDT
Date: Fri, 14 Jul 89 15:56:12 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907141956.AA19181@verdi.think.com>
To: rrrs-authors@ZURICH.ai.mit.edu
Subject: [postmaster@ames.UUCP: Returned mail: User unknown]

Date: Fri, 14 Jul 89 12:53:30 -0700
From: Mail Delivery Subsystem <postmaster@ames.UUCP>
Subject: Returned mail: User unknown
To: gls@think.UUCP

   ----- Transcript of session follows -----
550 rrrs-authors... User unknown

   ----- Unsent message follows -----
Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 14 Jul 89 12:53:30 -0700
Received: from verdi.think.com by news.think.com; Fri, 14 Jul 89 15:53:56 EDT
Received: by verdi.think.com; Fri, 14 Jul 89 15:51:27 EDT
Date: Fri, 14 Jul 89 15:51:27 EDT
>From: think!gls (Guy Steele)
Message-Id: <8907141951.AA19139@verdi.think.com>
To: ames!sde.hp.com!hplabs!jinx%hpda
Cc: willc@cs.uoregon.edu, think!gls, ames!rrrs-authors
In-Reply-To: Guillermo J. Rozas's message of Thu, 13 Jul 89 16:04:39 pdt <8907132305.AA01682@hpda.HP.COM>
Subject: Confusion

   Date: Thu, 13 Jul 89 16:04:39 pdt
   From: Guillermo J. Rozas <hplabs!hpesogg!jinx@ames.UUCP>

   I'm confused about a lot of things.  Perhaps I should have read Will's
   original message more carefully, rather than assume that I knew what
   was going on.

	  P1178 has requested that MIN and MAX be renamed INF and SUP.  The rationale
	  is that the somewhat surprising behavior of MIN and MAX when given mixed
	  exact and inexact arguments would be more acceptable if their names were
	  less familiar.  A second rationale is that the fact that the mathematical
	  infimum and supremum operations, when given an infinite set of "arguments",
	  may return a result that is not in the argument set; this is the surprising
	  thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
	  Background: In any case, a note will be added to point out and explain this
	  behavior, which is required in order for exact results to be trusted.  It
	  happens that MIN and MAX behave this way in Common Lisp as well, although
	  the motivation was rather different.

   As far as I understand it (and GJS agrees with me), the example Will
   shows could only be correct in an implementation where 
   (>= 9.999999999999998e99 #e1e100) is true.  If it isn't, the
   implementation of MAX/SUP is in error.  

   If (>= 9.999999999999998e99 #e1e100) holds, then it is not surprising
   that MAX/SUP returns 9.999999999999998e99.  Perhaps users of such an
   implementation should flame at the implementor of >= or of the numeric
   printing routine.

   The rationale for the renaming these procedures is that MAX and MIN
   have a common connotation of returning one of the elements of the
   input set.  Clearly these procedures don't do this.  They are more
   like the mathematical definition of SUP and INF which are defined to
   return the smallest value >= (or <=) than any of the input parameters.

   A different way to look at this is that numbers are not ordered in a
   line, but in a lattice.  Along the exact and the inexact dimension,
   the results are as expected, but when mixing them, we look for the SUP
   (INF) in the lattice, so again, the names make sense.


       The second rationale is fallacious.  Indeed INF (resp. SUP) may return values
       not in the set of arguments, but such result is guaranteed to be larger
       (resp. smaller) than any of the arguments.  The example given fails to have
       this property, and renaming MIN and MAX to INF and SUP will not repair the
       problem.

       The problem is that MIN (or INF) is supposed to return the largest value that
       is no smaller than any argument, and currently it fails to do so in Scheme.
       So why not just say it that way?  Change the definition of MIN and MAX.
       Don't give them new names that will have the same problem.

   The rationale is not fallacious if you understand that larger or
   smaller mean >= and <=, not the expected >= and <= that you compute by
   looking at the printed representation.  On a good implementation these
   two notions of >= should be very close.

   If the implementation returns true to the query 
   (>= 9.999999999999998e99 #e1e100), it is consistent, and is doing what
   you expect (modulo it's poor definition of >= or of number->string).

Thanks you for this exposition.  (This is what I get for mouthing
off without having been there, I guess.  I was reacting only to the
rationales expressed by Will.)

I now shift my position slightly.  I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it.  I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)

Therefore I argue to include all of SUP, INF, MAX, and MIN.

--Guy


∂15-Jul-89  1217	@mc.lcs.mit.edu:chaynes@iuvax.cs.indiana.edu 	Minutes of the 3rd IEEE Scheme Working Group meeting  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89  12:17:20 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04732;
          15 Jul 89 14:18 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:55:16 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa02609;
          14 Jul 89 17:28 EDT
Received: by iuvax.cs.indiana.edu 
Date: Fri, 14 Jul 89 16:23:53 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu, scheme@mc.lcs.mit.edu, 
    scheme-standard@wheaties.ai.mit.edu
Subject: Minutes of the 3rd IEEE Scheme Working Group meeting
Message-ID:  <8907141728.aa02609@mintaka.lcs.mit.edu>


		IEEE/MSC/P1178 Working Group on Scheme

                Unapproved Minutes of the Third Meeting

			     7 July 1989
			  MIT, Cambridge, MA


SUMMARY

R4RS numbers accepted.

Group believes all major technical issues have been resolved in
preparation for submission of draft.

Next meeting at POPL '90.


ACTIONS

The meeting was called to order by Chris Haynes at about 9:45AM.  The
following attendance list was collected:

	Hal Abelson			MIT
	Bill Campbell			University of Mass at Boston
	William Clinger			University of Oregon
	Ken Dickey			Tektronix
	Dan Friedman			Indiana University
	Dick Gabriel			Stanford University
	Chris Hanson			MIT
	Chris Haynes			Indiana University
	Sidney Marshal			Xerox
	Tim McNerney			ILA
	James S. Miller			Brandeis University
	Eric Ost			Indiana University
	John D. Ramsdell		The MITRE Corporation
	Guillerimo J. Rozas		MIT
	Gerald Jay Sussman		MIT
	Mitchell Wand			Northeastern University

1. The agenda was amended; the changes are reflected by the minutes.

2. John D. Ramsdell was elected secretary.

3. Minutes of the second meeting were accepted with no changes.

4. Differences from the last draft.

Chris Hanson described the changes to the draft introduce since the
last meeting.

Changes agreed on at last meeting:
   * "User Interface" appendix removed.
   * Restore `substring'.
   * Delete `with-input-from-port' and `with-output-to-port'.

Changes from R3.95RS:
   * Many small editorial changes.
   * Characters added to "extended alphabet" set: + - .
   * Added number section (pending outcome of third meeting).
   * Added description of "implementation error" in support of numbers section.
   * New description of:
	number->string
	string->number
	integer->char
	char->integer
	peek-char

5. Discuss the number section of the standard.

A long discussion followed, which continued until about 2:00PM (with a
lunch break).  This resulted in a much wider understanding and
appreciation of the exact/inexact distinction.  (In the process it was
clarified that non-numeric operations on numbers, such as storing and
retrieving them, are not allowed to affect their exactness.)

5.1 Moved and accepted: The editors will change wording in section
1.3.1 to clarify the notion of an implementation error.
Specific directions include, dropping the word "arbitrary" in
paragraph 3 and changing the following two sentences to read something
like: "When an implementation error is reported, the report must make
clear that an implementation restriction was violated. Implementation
restrictions are of course discouraged, but reporting their violation
is encouraged."

5.2 Moved and unanimously accepted: We accept the number section of
R4RS with some editorial changes.

5.3 Moved and accepted: We recommend that the R4RS authors rename the
procedure max to sup, and procedure min to inf.

5.4 Moved and rejected: If R4RS does not change the names of max and
min, P1178 should eliminate max and min.

5.5 Moved and accepted: Add expt to the list of procedures which
must return an exact result when given exact arguments (section 6.5.3).

5.6 Moved and accepted: Add an example showing the use of explicit
coercion of an inexact argument as an index of vector-ref.

5.7 Moved and unanimously accepted: The editors will add to the body
of the text the requirement that implementations must support a
minimal subset of numeric procedures and request that the R4RS authors
change the status to essential of any unessential procedure required
to support the minimal subset.

It was noted that the proscriptive wording (e.g., "shall", "must") in
appendix B.3) should be softened (e.g., "should").

The editors reaffirmed their intention to substantially extend
appendix B.3, including, for instance, a discussion of the
transitivity requirements for the numeric order and equality predicates.

6. R4RS status report

Will Clinger described the changes he expected between R3.95RS and
R4RS.  He promised a R3.99RS (R4RS without macro appendices) within a
month.  

* Add ... as a <peculiar identifier>.
* Change the branch cuts of some trig functions to be like Common Lisp's.
* Make char->integer and integer->char one-to-one.
* Return char-upper-case? to R4RS, which was dropped due to an editing error.
* Leave it unspecified as to whether the empty list counts as false.
* Change number->string description.

7. Moved and accepted:  We request that the R4RS authors add a
sentence encouraging that implementations support an international
character set, most likely ISO Latin 1 (ISO8859-1).

8. A move that ":" be change to not be an extended alphanumeric
character was not seconded.

9. Moved and accepted:  We request that the R4RS authors consider
making just list-ref (and not list-tail) essential.

10. A move to discuss changing the semantics of internal definitions was
not seconded.

11. Moved and accepted:  It is suggested that the next meeting of the
IEEE Scheme Working Group be on January 19, 1989, following the
Principles of Programming Languages conference in San Francisco, CA.

There was general consensus that at the next meeting the Working Group
could probably approve the draft standard for submission to the MSC
for public comment and balloting.  Therefore the draft to be
considered at the next meeting should be mailed to all those on the
Working Group mailing list no later than mid-November.

12. Moved and unanimously accepted:  The draft standard distributed at
the meeting (reflecting the changes detailed under item 4 above)
should be submitted to ISO WG-16 for consideration, with a brief 
cover statement to be drafted by Chris Haynes.

Dick Gabriel reported that ANSII asked X3J13 whether Scheme and Common
Lisp were distinct enough to justify two standards.  Bob Mathis
provided technical arguments convincing ANSII that they were distinct.

Meeting adjourned at about 3:30PM.


-- Minutes by John D. Ramsdell, edited by Chris Haynes



∂15-Jul-89  1323	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	Force & Delay manual reorganization
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89  13:23:04 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05784;
          15 Jul 89 15:37 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 15:03:08 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04281;
          14 Jul 89 19:25 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00232; Fri, 14 Jul 89 19:25:40 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 19:22:40 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA04729; Fri, 14 Jul 89 16:24:54 PDT
Date: Fri, 14 Jul 89 16:24:54 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907142324.AA04729@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Force & Delay manual reorganization


ciao,

Force and delay are currently in totally separate sections of R3.95RS which can
lead readers to hours of fun and enjoyment.  Perhaps the Delayed Evaluation
section (4.2.5) can be made a subsection of Control Features (6.9) and expanded
to include force.

(peace chance)

	mas

∂15-Jul-89  1328	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	Distinct types for continuations?  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89  13:28:48 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05915;
          15 Jul 89 15:49 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 15:03:27 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04423;
          14 Jul 89 19:40 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00358; Fri, 14 Jul 89 19:40:32 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 14 Jul 89 19:37:30 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA04796; Fri, 14 Jul 89 16:39:43 PDT
Date: Fri, 14 Jul 89 16:39:43 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907142339.AA04796@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Distinct types for continuations?


ciao,

It seems to us that continuations and procedures should be considered distinct
types.  With this in mind we propose the inclusion of a new procedure in R4RS
named continuation? that has the obvious semantics. The procedure procedure?
would, of course, need to be changed such that it would return #f if given a
continuation.  This only seems consistent with the decision at L&FP '88 to make
characters and numbers distinct types.

 (peace chance)

	mas & Morry Katz

∂15-Jul-89  2255	@mc.lcs.mit.edu,@LIFE.ai.mit.edu:shaff@sesame.stanford.edu 	Arg evaluation order
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89  22:55:26 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12851;
          16 Jul 89 0:35 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Jul 89 00:31:28 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12635;
          16 Jul 89 0:23 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10027; Sun, 16 Jul 89 00:23:26 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Sun, 16 Jul 89 00:20:15 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA08066; Sat, 15 Jul 89 11:32:27 PDT
Date: Sat, 15 Jul 89 11:32:27 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907151832.AA08066@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Fri, 14 Jul 89 11:07:53 pdt <8907141808.AA14308@sde.hp.com>
Subject: Arg evaluation order


ciao,

Jinx writes:

  1) Not specifying the order of argument evaluation, but requiring
  arguments to be evaluated sequentially.  Let's call this option
  "reordering" of argument evaluation.

  2) Allowing interleaving of argument evaluation, ie. evaluate part of
  one, then part of another, then part of yet another, then go back to
  the first and continue, etc.  Let's called this "interleaving" of
  argument evaluation.


  The current report allows reordering, but not interleaving.

I have not been advocating a change in the semantics that I think most people
agree is intended by the report, rather a clarification (or greater
specificity) in the language regarding this issue.

(peace chance)

	mas

∂15-Jul-89  2315	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #160 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 15 Jul 89  23:15:44 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13421;
          16 Jul 89 1:10 EDT
Date: 16 JUL 89  00:01:54 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #160 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907160110.aa13421@mintaka.lcs.mit.edu>

Scheme Digest #160                             16 JUL 89  00:01:54 EDT

Today's Topics:

        Opening files with Cscheme
        Minutes of the 3rd IEEE Scheme Working Group meeting

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

Date: 14 Jul 89 17:53:22 GMT
From: unicads!les@boulder.colorado.edu  (Les Milash)
Subject: Re: Opening files with Cscheme
Message-Id: <557@unicads.UUCP>

thanks, everyhody, for telling me about the function `file-exists?'.
you can stop now :-) you've been overwhelmingly helpful.


ya know, i've never gotten more code working faster than with this
wierd Scheme stuff!  i guess that's what it's all about, huh?

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

Date: Fri, 14 Jul 89 16:23:53 -0500
From: Chris Haynes <chaynes@iuvax.cs.indiana.edu>
Subject: Minutes of the 3rd IEEE Scheme Working Group meeting
Message-ID:  <8907141728.aa02609@mintaka.lcs.mit.edu>


		IEEE/MSC/P1178 Working Group on Scheme

                Unapproved Minutes of the Third Meeting

			     7 July 1989
			  MIT, Cambridge, MA


SUMMARY

R4RS numbers accepted.

Group believes all major technical issues have been resolved in
preparation for submission of draft.

Next meeting at POPL '90.


ACTIONS

The meeting was called to order by Chris Haynes at about 9:45AM.  The
following attendance list was collected:

	Hal Abelson			MIT
	Bill Campbell			University of Mass at Boston
	William Clinger			University of Oregon
	Ken Dickey			Tektronix
	Dan Friedman			Indiana University
	Dick Gabriel			Stanford University
	Chris Hanson			MIT
	Chris Haynes			Indiana University
	Sidney Marshal			Xerox
	Tim McNerney			ILA
	James S. Miller			Brandeis University
	Eric Ost			Indiana University
	John D. Ramsdell		The MITRE Corporation
	Guillerimo J. Rozas		MIT
	Gerald Jay Sussman		MIT
	Mitchell Wand			Northeastern University

1. The agenda was amended; the changes are reflected by the minutes.

2. John D. Ramsdell was elected secretary.

3. Minutes of the second meeting were accepted with no changes.

4. Differences from the last draft.

Chris Hanson described the changes to the draft introduce since the
last meeting.

Changes agreed on at last meeting:
   * "User Interface" appendix removed.
   * Restore `substring'.
   * Delete `with-input-from-port' and `with-output-to-port'.

Changes from R3.95RS:
   * Many small editorial changes.
   * Characters added to "extended alphabet" set: + - .
   * Added number section (pending outcome of third meeting).
   * Added description of "implementation error" in support of numbers section.
   * New description of:
	number->string
	string->number
	integer->char
	char->integer
	peek-char

5. Discuss the number section of the standard.

A long discussion followed, which continued until about 2:00PM (with a
lunch break).  This resulted in a much wider understanding and
appreciation of the exact/inexact distinction.  (In the process it was
clarified that non-numeric operations on numbers, such as storing and
retrieving them, are not allowed to affect their exactness.)

5.1 Moved and accepted: The editors will change wording in section
1.3.1 to clarify the notion of an implementation error.
Specific directions include, dropping the word "arbitrary" in
paragraph 3 and changing the following two sentences to read something
like: "When an implementation error is reported, the report must make
clear that an implementation restriction was violated. Implementation
restrictions are of course discouraged, but reporting their violation
is encouraged."

5.2 Moved and unanimously accepted: We accept the number section of
R4RS with some editorial changes.

5.3 Moved and accepted: We recommend that the R4RS authors rename the
procedure max to sup, and procedure min to inf.

5.4 Moved and rejected: If R4RS does not change the names of max and
min, P1178 should eliminate max and min.

5.5 Moved and accepted: Add expt to the list of procedures which
must return an exact result when given exact arguments (section 6.5.3).

5.6 Moved and accepted: Add an example showing the use of explicit
coercion of an inexact argument as an index of vector-ref.

5.7 Moved and unanimously accepted: The editors will add to the body
of the text the requirement that implementations must support a
minimal subset of numeric procedures and request that the R4RS authors
change the status to essential of any unessential procedure required
to support the minimal subset.

It was noted that the proscriptive wording (e.g., "shall", "must") in
appendix B.3) should be softened (e.g., "should").

The editors reaffirmed their intention to substantially extend
appendix B.3, including, for instance, a discussion of the
transitivity requirements for the numeric order and equality predicates.

6. R4RS status report

Will Clinger described the changes he expected between R3.95RS and
R4RS.  He promised a R3.99RS (R4RS without macro appendices) within a
month.  

* Add ... as a <peculiar identifier>.
* Change the branch cuts of some trig functions to be like Common Lisp's.
* Make char->integer and integer->char one-to-one.
* Return char-upper-case? to R4RS, which was dropped due to an editing error.
* Leave it unspecified as to whether the empty list counts as false.
* Change number->string description.

7. Moved and accepted:  We request that the R4RS authors add a
sentence encouraging that implementations support an international
character set, most likely ISO Latin 1 (ISO8859-1).

8. A move that ":" be change to not be an extended alphanumeric
character was not seconded.

9. Moved and accepted:  We request that the R4RS authors consider
making just list-ref (and not list-tail) essential.

10. A move to discuss changing the semantics of internal definitions was
not seconded.

11. Moved and accepted:  It is suggested that the next meeting of the
IEEE Scheme Working Group be on January 19, 1989, following the
Principles of Programming Languages conference in San Francisco, CA.

There was general consensus that at the next meeting the Working Group
could probably approve the draft standard for submission to the MSC
for public comment and balloting.  Therefore the draft to be
considered at the next meeting should be mailed to all those on the
Working Group mailing list no later than mid-November.

12. Moved and unanimously accepted:  The draft standard distributed at
the meeting (reflecting the changes detailed under item 4 above)
should be submitted to ISO WG-16 for consideration, with a brief 
cover statement to be drafted by Chris Haynes.

Dick Gabriel reported that ANSII asked X3J13 whether Scheme and Common
Lisp were distinct enough to justify two standards.  Bob Mathis
provided technical arguments convincing ANSII that they were distinct.

Meeting adjourned at about 3:30PM.


-- Minutes by John D. Ramsdell, edited by Chris Haynes



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

End of Scheme Digest
********************

∂16-Jul-89  1000	@mc.lcs.mit.edu,@decwrl.dec.com:jmiller@crl.dec.com 	[Scheme-Request@mc.lcs.mit.edu: Scheme Digest #158] 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 16 Jul 89  10:00:17 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00739;
          16 Jul 89 11:05 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 15 Jul 89 12:55:30 EDT
Received: from decwrl.dec.com by mintaka.lcs.mit.edu id aa02848;
          14 Jul 89 17:46 EDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	id AA28239; Fri, 14 Jul 89 09:24:31 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	for rrrs-authors@mc.lcs.mit.edu; id AA28239; Fri, 14 Jul 89 09:24:31 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
	id AA05497; Fri, 14 Jul 89 09:42:05 EDT
Date: Fri, 14 Jul 89 09:43:04 EDT
From: jmiller@crl.dec.com
Message-Id: <8907141343.AA02131@peanut.DEC.COM>
To: rrrs-authors@mc.lcs.mit.edu
Subject: [Scheme-Request@mc.lcs.mit.edu: Scheme Digest #158]
Reply-To: JMiller@crl.enet.dec.com

For anyone how hasn't seen it, here's an independent message that
serves to emphasize my argument in favor of Ken Dickey's suggestion
that OPEN-[IN/OUT]PUT-FILE should allow some way of avoiding the
signalled error.  The problem is real, not just hypothetical as you
can see from an honest-to-goodness USER of the language.

The message was sent to Scheme@mc.lcs.mit.edu.  I editted it for this
transmission.

--Jim

Date: 13 Jul 89 18:36:08 GMT
From: Les Milash <unicads!les@boulder.colorado.edu>

i have a manual called RRRS.  i have a problem.

i'm trying to write a program that's c-preprocessor compatable, in that
it takes a -I/parameter -I/that/lists/a/bunch -I/of/directories/that
include files might be in.  so when the code includes foo.h i have to
find the first one of
	/parameter/foo.h
	/that/lists/a/bunch/foo.h
	/of/directories/that/foo.h
that exists.

RRRS talks about (open-input-file "filename") but if the file doesn't exist
i get an "out of range with "filename"" error and the program stops.

is there a way to figure out if some file exists without crashing?  or
some way to substitute some better error behaviour (i'd just as soon
have it return '() or #!the-you-screwed-up-object or something).
i have the CScheme source and am not adverse to making myself un-scheme-
compatable (but i imagine that scheme can do what i want somehow (else
what good is it?))


∂16-Jul-89  1341	@mc.lcs.mit.edu,@life.ai.mit.edu:danvy@freja.diku.dk 	Re:  Distinct types for continuations?   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 16 Jul 89  13:41:00 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04312;
          16 Jul 89 16:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 16 Jul 89 16:26:24 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04243;
          16 Jul 89 16:22 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA13763; Sun, 16 Jul 89 16:20:46 EDT
Received: from freja.diku.dk ([129.142.96.1]) by zurich.ai.mit.edu; Sun, 16 Jul 89 16:17:32 edt
Received: by freja.diku.dk
	(5.61++/IDA-1.2.8) id AA15278; Sun, 16 Jul 89 17:06:06 +0200
Date: Sun, 16 Jul 89 17:06:06 +0200
From: Olivier Danvy <danvy@diku.dk>
Message-Id: <8907161506.AA15278@freja.diku.dk>
To: rrrs-authors@zurich.ai.mit.edu, shaff@sesame.stanford.edu
Subject: Re:  Distinct types for continuations?


	A problem in distinguishing procedures and continuations
	is the one of eta-redexes.
	We would have
		(call-with-current-continuation continuation?) -> #t
		(call-with-current-continuation procedure?) -> #f
	and
		(call-with-current-continuation
		  (lambda (k)
		    (continuation? k))) -> #t
	but
		(call-with-current-continuation
		  (lambda (k)
		    (continuation? (lambda (v)
				     (k v))))) -> #f

	In other terms, do we want to distinguish k and (lambda (v) (k v))?
	Or to introduce some operator "throw" or "continue"?


	A motivation for representing first-class continuations as procedures
	is that procedures can be defined as continuation transformers:
		Cont = Val -> Ans
		Proc = Cont -> Val -> Ans = Cont -> Cont
	Then it is possible to present first-class continuations
	as procedures that substitute the continuations that were reified
	for the current continuation.


		Peace as well,		Olivier

∂16-Jul-89  2144	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #161 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 16 Jul 89  21:44:07 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09261;
          17 Jul 89 0:32 EDT
Date: 17 JUL 89  00:01:56 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #161 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907170032.aa09261@mintaka.lcs.mit.edu>

Scheme Digest #161                             17 JUL 89  00:01:56 EDT

Today's Topics:

        Xscheme object context diffs & sample (425 lines)
        The defintion of TRUE and FALSE in Scheme.

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

Date: 16 Jul 89 14:12:44 GMT
From: David W Crabb <phoenix!crabb@princeton.edu>
Subject: Xscheme object context diffs & sample (425 lines)
Message-Id: <9447@phoenix.Princeton.EDU>

Since, as far as I know, no solution to the bad behavior of the objects 
in Xscheme has yet appeared here, I am posting one.

Two files are appended to this posting:
    xschemen.dif
    tryit.xs
The former consists of context diffs for the program PATCH . These must be
compiled in order to make the object/class capability of Xscheme, vers. 0.16,
work in a manner similar to Xlisp (especially the versions of Xlisp prior to 
the introduction of "send").
The second file is for trying out some of those capabilities, and is
designed to illustrate how close the modification comes to implementing
what was presumably the original design idea.

Note that very few lines of code need to be added or modified:

  xscomn.c   1 line added

  xsintn.c   3 lines added    1 line deleted

  xsobjn.c   8 lines added    4 lines deleted     4 lines modified


---------------- xschemen.dif ----------------------------------------

*** xscom.c	Thu Jul 13 14:50:58 1989
--- xscomn.c	Thu Jul 13 15:19:04 1989
***************
*** 1,3
  /* xscom.c - a simple scheme bytecode compiler */
  /*	Copyright (c) 1988, by David Michael Betz
  	All Rights Reserved

--- 1,8 -----
+ /**  modified  xlfunction
+ 	David W. Crabb	(crabb@phoenix.princeton.edu)
+      July,  1989
+ **/
+ 
  /* xscom.c - a simple scheme bytecode compiler */
  /*	Copyright (c) 1988, by David Michael Betz
  	All Rights Reserved
***************
*** 101,107
      return (pop());
  }
  
! /* xlfunction - compile a function */
  LVAL xlfunction(fun,fargs,body,ctenv)
    LVAL fun,fargs,body,ctenv;
  {

--- 106,112 -----
      return (pop());
  }
  
! /* xlfunction - compile a function */  /* used only by clanswer()  **/
  LVAL xlfunction(fun,fargs,body,ctenv)
    LVAL fun,fargs,body,ctenv;
  {
***************
*** 110,115
      rplaca(info,newframe(ctenv,1));
      rplacd(info,cons(NIL,NIL));
  
      /* setup the base of the code for this function */
      cbase = cptr = 0;
  

--- 115,122 -----
      rplaca(info,newframe(ctenv,1));
      rplacd(info,cons(NIL,NIL));
  
+     rplacd (car(info), ctenv);	 /** DWC: 7/5/89 */
+ 
      /* setup the base of the code for this function */
      cbase = cptr = 0;
  
***************
*** 316,322
      /* initialize the argument name list and slot number */
      restarg = last = NIL;
      slotn = 1;
!     
      /* handle each required argument */
      while (consp(fargs) && (arg = car(fargs)) && !lambdakey(arg)) {
  

--- 323,329 -----
      /* initialize the argument name list and slot number */
      restarg = last = NIL;
      slotn = 1;
! 
      /* handle each required argument */
      while (consp(fargs) && (arg = car(fargs)) && !lambdakey(arg)) {
  
*** xsint.c	Thu Jul 13 14:50:59 1989
--- xsintn.c	Thu Jul 13 14:50:59 1989
***************
*** 1,3
  /* xsint.c - xscheme bytecode interpreter */
  /*	Copyright (c) 1988, by David Michael Betz
  	All Rights Reserved

--- 1,8 -----
+ /**  modified METHOD case of  xlapply()
+ 	David W. Crabb	(crabb@phoenix.princeton.edu)
+      July, 1989
+ **/
+ 
  /* xsint.c - xscheme bytecode interpreter */
  /*	Copyright (c) 1988, by David Michael Betz
  	All Rights Reserved
***************
*** 6,11
  #include "xscheme.h"
  #include "xsbcode.h"
  
  /* sample rate (instructions per sample) */
  #define SRATE	1000
  

--- 11,19 -----
  #include "xscheme.h"
  #include "xsbcode.h"
  
+ /**  from  xsobj.c :  */
+ #define IVENV 1
+ 
  /* sample rate (instructions per sample) */
  #define SRATE	1000
  
***************
*** 356,362
  	break;
      case METHOD:
  	xlfun = getcode(xlval);
! 	xlenv = cons(top(),getenv(xlval));
  	base = pc = getcodestr(xlfun);
  	break;
      case CONTINUATION:

--- 364,374 -----
  	break;
      case METHOD:
  	xlfun = getcode(xlval);
! 
! 	xlenv = getenv(xlval);	/** DWC  7/5/89 */
! 	tmp = getivar(top(),IVENV);   /**  DWC	7/11  */
! 	rplacd(xlenv, tmp);
! 
  	base = pc = getcodestr(xlfun);
  	break;
      case CONTINUATION:
*** xsobj.c	Thu Jul 13 14:50:59 1989
--- xsobjn.c	Thu Jul 13 15:10:12 1989
***************
*** 1,3
  /* xsobj.c - xscheme object-oriented programming support */
  /*	Copyright (c) 1988, by David Michael Betz
  	All Rights Reserved

--- 1,8 -----
+ /**  Modifications to clanswer(), clisnew(), and clnew() .
+        David W. Crabb	(crabb@phoenix.princeton.edu)
+      July, 1989
+ **/
+ 
  /* xsobj.c - xscheme object-oriented programming support */
  /*	Copyright (c) 1988, by David Michael Betz
  	All Rights Reserved
***************
*** 13,18
  static LVAL s_self,k_isnew;
  static LVAL class,object;
  
  /* instance variable numbers for the class 'Class' */
  #define MESSAGES	1	/* list of messages */
  #define IVARS		2	/* list of instance variable names */

--- 18,28 -----
  static LVAL s_self,k_isnew;
  static LVAL class,object;
  
+ /**  DWC:  instance variable numbers for objects  */
+ #define IVENV 1  /** ivars now passed as an environment  */
+ /**  number of instance variables for objects  */
+ #define IVTOT 2
+ 
  /* instance variable numbers for the class 'Class' */
  #define MESSAGES	1	/* list of messages */
  #define IVARS		2	/* list of instance variable names */
***************
*** 140,146
  /* clnew - create a new object instance */
  clnew()
  {
!     LVAL self;
  
      /* create a new object */
      self = xlgaobject();

--- 150,157 -----
  /* clnew - create a new object instance */
  clnew()
  {
! 	       int i;
!     LVAL self, ivframe,ivars,c ;
  
      /* create a new object */
      self = xlgaobject();
***************
*** 144,150
  
      /* create a new object */
      self = xlgaobject();
!     xlval = newobject(self,getivcnt(self,IVARTOTAL));
  
      /* send the 'isnew' message */
      xlsend(xlval,k_isnew);

--- 155,161 -----
  
      /* create a new object */
      self = xlgaobject();
!     xlval = newobject(self,IVTOT);
  
      ivars = getivar(self,IVARS);
      ivframe = newframe(NIL,listlength(ivars) + 1);
***************
*** 146,151
      self = xlgaobject();
      xlval = newobject(self,getivcnt(self,IVARTOTAL));
  
      /* send the 'isnew' message */
      xlsend(xlval,k_isnew);
  }

--- 157,167 -----
      self = xlgaobject();
      xlval = newobject(self,IVTOT);
  
+     ivars = getivar(self,IVARS);
+     ivframe = newframe(NIL,listlength(ivars) + 1);
+     setelement(car(ivframe),0,ivars);
+     setivar(xlval,IVENV, ivframe);
+ 
      /* send the 'isnew' message */
      xlsend(xlval,k_isnew);
  }
***************
*** 153,159
  /* clisnew - initialize a new class */
  LVAL clisnew()
  {
!     LVAL self,ivars,cvars,super;
      int n;
  
      /* get self, the ivars, cvars and superclass */

--- 169,175 -----
  /* clisnew - initialize a new class */
  LVAL clisnew()
  {
!     LVAL self,ivars,cvars,super, tmp;
      int n;
  
      /* get self, the ivars, cvars and superclass */
***************
*** 163,172
      super = (moreargs() ? xlgaobject() : object);
      xllastarg();
  
-     /* create the class variable compile-time environment */
-     xlval = cons(xlenter("%%CLASS"),copylists(cvars,NIL));
-     cpush(cons(xlval,getivar(super,CVARS)));
-     
      /* create the class variable environment */
      xlval = newvector(listlength(xlval)); setelement(xlval,0,self);
      cpush(cons(xlval,getivar(super,CVALS)));

--- 179,184 -----
      super = (moreargs() ? xlgaobject() : object);
      xllastarg();
  
      /* create the class variable environment */
      xlval = newvector(listlength(xlval)); setelement(xlval,0,self);
      cpush(cons(xlval,getivar(super,CVALS)));
***************
*** 172,178
      cpush(cons(xlval,getivar(super,CVALS)));
  
      /* store the instance and class variable lists and the superclass */
!     setivar(self,IVARS,copylists(getivar(super,IVARS),ivars));
      setivar(self,CVALS,pop());
      setivar(self,CVARS,pop());
      setivar(self,SUPERCLASS,super);

--- 184,191 -----
      cpush(cons(xlval,getivar(super,CVALS)));
  
      /* store the instance and class variable lists and the superclass */
!     setivar(self,IVARS,ivars);	/* to be retrieved in  clnew()	**/
! 
      setivar(self,CVALS,pop());
  
      tmp = newframe(NIL,listlength(cvars) + 1);
***************
*** 174,180
      /* store the instance and class variable lists and the superclass */
      setivar(self,IVARS,copylists(getivar(super,IVARS),ivars));
      setivar(self,CVALS,pop());
!     setivar(self,CVARS,pop());
      setivar(self,SUPERCLASS,super);
  
      /* compute the instance variable count */

--- 187,197 -----
      setivar(self,IVARS,ivars);	/* to be retrieved in  clnew()	**/
  
      setivar(self,CVALS,pop());
! 
!     tmp = newframe(NIL,listlength(cvars) + 1);
!     setelement(car(tmp),0,cvars);
!     setivar(self,CVARS,tmp);
! 
      setivar(self,SUPERCLASS,super);
  
      /* compute the instance variable count */
***************
*** 191,197
  LVAL clanswer()
  {
      extern LVAL xlfunction();
!     LVAL self,msg,fargs,code,mptr;
  
      /* message symbol, formal argument list and code */
      self = xlgaobject();

--- 208,214 -----
  LVAL clanswer()
  {
      extern LVAL xlfunction();
!     LVAL self,msg,fargs,code,mptr, tmp;
  
      /* message symbol, formal argument list and code */
      self = xlgaobject();
***************
*** 206,214
      /* add 'self' to the argument list */
      cpush(cons(s_self,fargs));
  
!     /* extend the class variable environment with the instance variables */
!     xlval = cons(getivar(self,IVARS),getivar(self,CVARS));
!     
      /* compile and store the method */
      xlval = xlfunction(msg,top(),code,xlval);
      rplacd(mptr,cvmethod(xlval,getivar(self,CVALS)));

--- 223,230 -----
      /* add 'self' to the argument list */
      cpush(cons(s_self,fargs));
  
!     tmp = getivar (self,CVARS) ;   /** now an env from	clisnew()  */
! 
      /* compile and store the method */
      xlval = xlfunction(msg,top(),code,tmp);
      rplacd(mptr,cvmethod(xlval, tmp));
***************
*** 210,217
      xlval = cons(getivar(self,IVARS),getivar(self,CVARS));
      
      /* compile and store the method */
!     xlval = xlfunction(msg,top(),code,xlval);
!     rplacd(mptr,cvmethod(xlval,getivar(self,CVALS)));
      drop(1);
  
      /* return the object */

--- 226,233 -----
      tmp = getivar (self,CVARS) ;   /** now an env from	clisnew()  */
  
      /* compile and store the method */
!     xlval = xlfunction(msg,top(),code,tmp);
!     rplacd(mptr,cvmethod(xlval, tmp));
      drop(1);
  
      /* return the object */


----------------------- tryit.xs  ------------------------------------

;  "tryit.xs"  for loading into xscheme - modified version .
;      David W. Crabb        crabb@phoenix.princeton.edu

(define aClass (Class 'new '(ivar1 ivar2) '(cvar1 cvar2)))
(define anInst (aClass 'new))

(aClass 'answer 'set-cvar1 '(value) '( (set! cvar1 value)))
(aClass 'answer 'cvar1? '() '( (print cvar1)))

(aClass 'show)
(anInst 'set-cvar1 592)
(anInst 'cvar1?)                                                ;  >>  592

(aClass 'answer 'set-ivar1 '() '( (set! ivar1 5505)))
(anInst 'set-ivar1)
(aClass 'answer 'ivar1? '() '( (print ivar1)))
(anInst 'ivar1?)                                                ;  >> 5505

(define subClass (Class 'new '(ivar1 ivar2) '(cvar1 cvar2) aClass ))
(define subInst (subClass 'new))
(subInst 'cvar1?)                                               ;  >>  592
(subInst 'ivar1?)                                               ;  >>  ()

(aClass 'answer 'reset-ivar1 '() '( (set! ivar1 -66)))
(subInst 'reset-ivar1)  (subInst 'ivar1?)			;  >>  -66
(anInst 'ivar1?)                                                ;  >>  5505


;;  -------------------- eof ----------------------------------------------

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

Date: 16 Jul 89 04:18:26 GMT
From: "Mario O. Bourgoin" <mob@media-lab.media.mit.edu>
Subject: The defintion of TRUE and FALSE in Scheme.
Message-Id: <152@mit-amt.MEDIA.MIT.EDU>

I've been wanting to replace the usual LISP definitions of TRUE and
FALSE by functions because that seems more in the spirit of Scheme.
Furthermore, with functions we can eliminate ``if'' and ``cond'' from
the essential syntax of Scheme which simplifies the analysis of
extensions to Scheme such as Zabih, McAllester, and Chapman's
non-deterministic operator, ``amb''.  I would like to get the Scheme
community's reaction to the specification of particular objects for
TRUE and FALSE, namely the functions:

(define true (lambda (iftrue iffalse) iftrue))
(define false (lambda (iftrue iffalse) iffalse))

Naturally, the constants #t and #f would always denote the appropriate
one of these two functions.

Given the above definitions for TRUE and FALSE, ``if'' statements can
be replaced according to the following pattern:

(if predicate iftrue iffalse) =>
((predicate (lambda () iftrue) (lambda () iffalse)))

And ``cond'' may be replaced thus:

(cond (predicate1 body1)
      (predicate2 body2)
      (predicate3 body3)
      (else bodyelse))

becomes:

((predicate1
  (lambda () body1)
  (lambda ()
    ((predicate2
      (lambda () body2)
      (lambda ()
        ((predicate3
          (lambda () body3)
          (lambda () bodyelse)))))))))

The logical connectives ``not'', ``and'', and ``or'' could be defined
as follows.

(not predicate) => (predicate false true)

(or predicate1 predicate2) => (predicate1 true predicate2)

(and predicate1 predicate2) => (predicate1 predicate2 false)

Naturally, the definitions for ``or'' and ``and'' can be extended to
handle a variable number of parameters.

Please tell me of any problems you see with such a definition.

--Mario O. Bourgoin

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

End of Scheme Digest
********************

∂17-Jul-89  0910	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	[gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89  09:09:59 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16229;
          17 Jul 89 12:00 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 11:54:51 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa16079;
          17 Jul 89 11:49 EDT
Received: from fafnir.think.com by Think.COM; Mon, 17 Jul 89 11:49:22 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 17 Jul 89 11:47:41 EDT
Received: by verdi.think.com; Mon, 17 Jul 89 11:47:39 EDT
Date: Mon, 17 Jul 89 11:47:39 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907171547.AA24575@verdi.think.com>
To: rrrs-authors@mc.lcs.mit.edu, rrrs-authors@life.ai.mit.edu
Subject: [gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]


I apologize to those who receive multiple copies of this.  The mailers
seem to be a bit confused.
--Guy

Date: Fri, 14 Jul 89 15:56:12 EDT
From: Guy Steele <gls@Think.COM>
To: rrrs-authors@zurich.ai.mit.edu
Subject: [postmaster@ames.UUCP: Returned mail: User unknown]

Date: Fri, 14 Jul 89 12:53:30 -0700
>From: Mail Delivery Subsystem <postmaster@ames.UUCP>
Subject: Returned mail: User unknown
To: gls@think.UUCP

   ----- Transcript of session follows -----
550 rrrs-authors... User unknown

   ----- Unsent message follows -----
Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 14 Jul 89 12:53:30 -0700
Received: from verdi.think.com by news.think.com; Fri, 14 Jul 89 15:53:56 EDT
Received: by verdi.think.com; Fri, 14 Jul 89 15:51:27 EDT
Date: Fri, 14 Jul 89 15:51:27 EDT
>From: think!gls (Guy Steele)
Message-Id: <8907141951.AA19139@verdi.think.com>
To: ames!sde.hp.com!hplabs!jinx%hpda
Cc: willc@cs.uoregon.edu, think!gls, ames!rrrs-authors
In-Reply-To: Guillermo J. Rozas's message of Thu, 13 Jul 89 16:04:39 pdt <8907132305.AA01682@hpda.HP.COM>
Subject: Confusion

   Date: Thu, 13 Jul 89 16:04:39 pdt
   From: Guillermo J. Rozas <hplabs!hpesogg!jinx@ames.UUCP>

   I'm confused about a lot of things.  Perhaps I should have read Will's
   original message more carefully, rather than assume that I knew what
   was going on.

	  P1178 has requested that MIN and MAX be renamed INF and SUP.  The rationale
	  is that the somewhat surprising behavior of MIN and MAX when given mixed
	  exact and inexact arguments would be more acceptable if their names were
	  less familiar.  A second rationale is that the fact that the mathematical
	  infimum and supremum operations, when given an infinite set of "arguments",
	  may return a result that is not in the argument set; this is the surprising
	  thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
	  Background: In any case, a note will be added to point out and explain this
	  behavior, which is required in order for exact results to be trusted.  It
	  happens that MIN and MAX behave this way in Common Lisp as well, although
	  the motivation was rather different.

   As far as I understand it (and GJS agrees with me), the example Will
   shows could only be correct in an implementation where 
   (>= 9.999999999999998e99 #e1e100) is true.  If it isn't, the
   implementation of MAX/SUP is in error.  

   If (>= 9.999999999999998e99 #e1e100) holds, then it is not surprising
   that MAX/SUP returns 9.999999999999998e99.  Perhaps users of such an
   implementation should flame at the implementor of >= or of the numeric
   printing routine.

   The rationale for the renaming these procedures is that MAX and MIN
   have a common connotation of returning one of the elements of the
   input set.  Clearly these procedures don't do this.  They are more
   like the mathematical definition of SUP and INF which are defined to
   return the smallest value >= (or <=) than any of the input parameters.

   A different way to look at this is that numbers are not ordered in a
   line, but in a lattice.  Along the exact and the inexact dimension,
   the results are as expected, but when mixing them, we look for the SUP
   (INF) in the lattice, so again, the names make sense.


       The second rationale is fallacious.  Indeed INF (resp. SUP) may return values
       not in the set of arguments, but such result is guaranteed to be larger
       (resp. smaller) than any of the arguments.  The example given fails to have
       this property, and renaming MIN and MAX to INF and SUP will not repair the
       problem.

       The problem is that MIN (or INF) is supposed to return the largest value that
       is no smaller than any argument, and currently it fails to do so in Scheme.
       So why not just say it that way?  Change the definition of MIN and MAX.
       Don't give them new names that will have the same problem.

   The rationale is not fallacious if you understand that larger or
   smaller mean >= and <=, not the expected >= and <= that you compute by
   looking at the printed representation.  On a good implementation these
   two notions of >= should be very close.

   If the implementation returns true to the query 
   (>= 9.999999999999998e99 #e1e100), it is consistent, and is doing what
   you expect (modulo it's poor definition of >= or of number->string).

Thanks you for this exposition.  (This is what I get for mouthing
off without having been there, I guess.  I was reacting only to the
rationales expressed by Will.)

I now shift my position slightly.  I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it.  I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)

Therefore I argue to include all of SUP, INF, MAX, and MIN.

--Guy




∂17-Jul-89  1059	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	[gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]    
Received: from lcs.mit.edu (XX.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89  10:58:53 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16409;
          17 Jul 89 12:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 11:55:04 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16080;
          17 Jul 89 11:49 EDT
Received: from Think.COM (Gateway.Think.COM) by life.ai.mit.edu (4.1/AI-4.10) id AA00664; Mon, 17 Jul 89 11:49:05 EDT
Received: from fafnir.think.com by Think.COM; Mon, 17 Jul 89 11:49:22 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 17 Jul 89 11:47:41 EDT
Received: by verdi.think.com; Mon, 17 Jul 89 11:47:39 EDT
Date: Mon, 17 Jul 89 11:47:39 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907171547.AA24575@verdi.think.com>
To: rrrs-authors@mc.lcs.mit.edu, rrrs-authors@life.ai.mit.edu
Subject: [gls@Think.COM: [postmaster@ames.UUCP: Returned mail: User unknown]]


I apologize to those who receive multiple copies of this.  The mailers
seem to be a bit confused.
--Guy

Date: Fri, 14 Jul 89 15:56:12 EDT
From: Guy Steele <gls@Think.COM>
To: rrrs-authors@zurich.ai.mit.edu
Subject: [postmaster@ames.UUCP: Returned mail: User unknown]

Date: Fri, 14 Jul 89 12:53:30 -0700
>From: Mail Delivery Subsystem <postmaster@ames.UUCP>
Subject: Returned mail: User unknown
To: gls@think.UUCP

   ----- Transcript of session follows -----
550 rrrs-authors... User unknown

   ----- Unsent message follows -----
Received: by ames.arc.nasa.gov (5.61/1.2); Fri, 14 Jul 89 12:53:30 -0700
Received: from verdi.think.com by news.think.com; Fri, 14 Jul 89 15:53:56 EDT
Received: by verdi.think.com; Fri, 14 Jul 89 15:51:27 EDT
Date: Fri, 14 Jul 89 15:51:27 EDT
>From: think!gls (Guy Steele)
Message-Id: <8907141951.AA19139@verdi.think.com>
To: ames!sde.hp.com!hplabs!jinx%hpda
Cc: willc@cs.uoregon.edu, think!gls, ames!rrrs-authors
In-Reply-To: Guillermo J. Rozas's message of Thu, 13 Jul 89 16:04:39 pdt <8907132305.AA01682@hpda.HP.COM>
Subject: Confusion

   Date: Thu, 13 Jul 89 16:04:39 pdt
   From: Guillermo J. Rozas <hplabs!hpesogg!jinx@ames.UUCP>

   I'm confused about a lot of things.  Perhaps I should have read Will's
   original message more carefully, rather than assume that I knew what
   was going on.

	  P1178 has requested that MIN and MAX be renamed INF and SUP.  The rationale
	  is that the somewhat surprising behavior of MIN and MAX when given mixed
	  exact and inexact arguments would be more acceptable if their names were
	  less familiar.  A second rationale is that the fact that the mathematical
	  infimum and supremum operations, when given an infinite set of "arguments",
	  may return a result that is not in the argument set; this is the surprising
	  thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.
	  Background: In any case, a note will be added to point out and explain this
	  behavior, which is required in order for exact results to be trusted.  It
	  happens that MIN and MAX behave this way in Common Lisp as well, although
	  the motivation was rather different.

   As far as I understand it (and GJS agrees with me), the example Will
   shows could only be correct in an implementation where 
   (>= 9.999999999999998e99 #e1e100) is true.  If it isn't, the
   implementation of MAX/SUP is in error.  

   If (>= 9.999999999999998e99 #e1e100) holds, then it is not surprising
   that MAX/SUP returns 9.999999999999998e99.  Perhaps users of such an
   implementation should flame at the implementor of >= or of the numeric
   printing routine.

   The rationale for the renaming these procedures is that MAX and MIN
   have a common connotation of returning one of the elements of the
   input set.  Clearly these procedures don't do this.  They are more
   like the mathematical definition of SUP and INF which are defined to
   return the smallest value >= (or <=) than any of the input parameters.

   A different way to look at this is that numbers are not ordered in a
   line, but in a lattice.  Along the exact and the inexact dimension,
   the results are as expected, but when mixing them, we look for the SUP
   (INF) in the lattice, so again, the names make sense.


       The second rationale is fallacious.  Indeed INF (resp. SUP) may return values
       not in the set of arguments, but such result is guaranteed to be larger
       (resp. smaller) than any of the arguments.  The example given fails to have
       this property, and renaming MIN and MAX to INF and SUP will not repair the
       problem.

       The problem is that MIN (or INF) is supposed to return the largest value that
       is no smaller than any argument, and currently it fails to do so in Scheme.
       So why not just say it that way?  Change the definition of MIN and MAX.
       Don't give them new names that will have the same problem.

   The rationale is not fallacious if you understand that larger or
   smaller mean >= and <=, not the expected >= and <= that you compute by
   looking at the printed representation.  On a good implementation these
   two notions of >= should be very close.

   If the implementation returns true to the query 
   (>= 9.999999999999998e99 #e1e100), it is consistent, and is doing what
   you expect (modulo it's poor definition of >= or of number->string).

Thanks you for this exposition.  (This is what I get for mouthing
off without having been there, I guess.  I was reacting only to the
rationales expressed by Will.)

I now shift my position slightly.  I agree that a procedure that computes
(??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
good name for it.  I also believe that a procedure is useful that is
defined to return some one of its arguments such that the returned argument
is >= all other arguments, and that MAX is a good name for that procedure.
(One might also argue that, everything else being equal (!), MAX should
return the least-exact argument having that property, but I won't push that.)

Therefore I argue to include all of SUP, INF, MAX, and MIN.

--Guy




∂17-Jul-89  1337	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	Distinct types for continuations?  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89  13:37:32 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19418;
          17 Jul 89 16:30 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 16:27:14 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19335;
          17 Jul 89 16:23 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03828; Mon, 17 Jul 89 16:22:43 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Mon, 17 Jul 89 16:19:29 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA16188; Mon, 17 Jul 89 09:52:43 PDT
Date: Mon, 17 Jul 89 09:52:43 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907171652.AA16188@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Olivier Danvy's message of Sun, 16 Jul 89 17:06:06 +0200 <8907161506.AA15278@freja.diku.dk>
Subject:  Distinct types for continuations?


ciao,

According to our reading of Will's denotational semantics for R3.95RS,
continuations and procedures of one argument are in different semantic domains.
This seems to add credence to our desire to be able to distinguish between
continuations and procedures.  If it is indeed decided that continuations and
their eta converted versions [e.g., (lambda (v) (k v))] should be
indistinguishable then the denotational semantics should be updated to reflect
this similarity.

(peace chance)

	mas & Morry

∂17-Jul-89  1443	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89  14:43:40 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20283;
          17 Jul 89 17:34 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 17 Jul 89 17:30:20 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 237020; Mon 17-Jul-89 17:29:57 EDT
Date: Mon, 17 Jul 89 17:29 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Numbers
To: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907171547.AA24575@verdi.think.com>,
             <8907141728.aa02609@mintaka.lcs.mit.edu>,
             <8907132208.AA24978@hpda.HP.COM>
Message-ID: <19890717212952.6.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Fri, 14 Jul 89 15:51:27 EDT
    From: think!gls (Guy Steele)
    Subject: Confusion

    I now shift my position slightly.  I agree that a procedure that computes
    (??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
    good name for it.  I also believe that a procedure is useful that is
    defined to return some one of its arguments such that the returned argument
    is >= all other arguments, and that MAX is a good name for that procedure.
    (One might also argue that, everything else being equal (!), MAX should
    return the least-exact argument having that property, but I won't push that.)

    Therefore I argue to include all of SUP, INF, MAX, and MIN.

    --Guy

Except MAX and MIN have a bug with respect to the notion of exactness.
They return an exact answer when they are not entitled to.  And they have
the good names, so programmers will use them and nobody will use INF and
SUP.  Doing this is a subtle way of degrading the concept of an exact
number.

    Date: Thu, 13 Jul 89 15:07:27 pdt
    From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
    You say:

	 Perhaps a simpler solution to the whole problem is to add a prominent
	 warning note, like the one attached to `<' and friends, that warns
	 about the unreliability of `max' and `min' when inexact numbers are in
	 use.

    I agree with your suggestion completely.  It is consistent with
    everything else we are doing to do it that way.  We don't change the
    name of "+" to make it less misleading, we warn about the possible
    problems and limitations that appear.

Indeed, if we do this, then MIN and MAX are unreliable in the same way that
the numeric predicates are.  They will be the only numeric -functions- that
require such a warning.  INF and SUP require no such warning.

If we really aren't going to take exactness seriously, then I would rather
not have it at all.  If we -are- going to take exactness seriously, then we
should flush "unreliable" MIN and MAX, and change the names of INF and SUP
back to MIN and MAX.  INF and SUP are the correct Scheme representation for
the mathematical functions in question, given the principles of exactness.


From the Unapproved Minutes of the Third Meeting of the IEEE Working Group
on Scheme:

    5.5 Moved and accepted: Add expt to the list of procedures which
    must return an exact result when given exact arguments (section 6.5.3).

Does this mean that (expt 2 50) -must- return an exact number?  Suppose I
have an implementation with 32 bit FIXNUMs as my exact numbers, IEEE
FLONUMs as my inexact numbers, but no BIGNUMs.  Am I forbidden from
returning a FLONUM (inexact) answer, even though my FLONUMs have the range?
Does this mean that (expt 2 50) would have to signal an error, even though
(* (expt 2 25) (expt 2 25)) would be allowed to return a FLONUM (inexact)
answer?

    The editors reaffirmed their intention to substantially extend
    appendix B.3, including, for instance, a discussion of the
    transitivity requirements for the numeric order and equality predicates.

This should be fun.  Once you start letting people take their naive notions
of how numbers should behave and turn them into -requirements-, all hell
can break lose.  On what basis do you decide that the order predicates are
required to be transitive, but that + is not required to be associative?
The danger is that requirements may be adopted just in case people can
imagine a way to meet them in an implementation that uses floating point
for its inexact numbers.  Unless some restraint is exercised, this can
eliminate plausible implementations of inexact numbers that aren't floating
point.

∂17-Jul-89  1517	@mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu 	Distinct types for continuations?
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89  15:17:26 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20669;
          17 Jul 89 18:00 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 17:56:36 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20499;
          17 Jul 89 17:47 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04965; Mon, 17 Jul 89 17:47:02 EDT
Received: from REAGAN.AI.MIT.EDU (reagan.ai.mit.edu) by zurich.ai.mit.edu; Mon, 17 Jul 89 17:43:56 edt
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 237034; Mon 17-Jul-89 17:46:53 EDT
Date: Mon, 17 Jul 89 17:46 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Distinct types for continuations?
To: shaff@sesame.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: <8907171652.AA16188@sesame.Stanford.EDU>
Message-Id: <19890717214647.7.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Mon, 17 Jul 89 09:52:43 PDT
    From: Mike Shaff <shaff@sesame.stanford.edu>
    According to our reading of Will's denotational semantics for R3.95RS,
    continuations and procedures of one argument are in different semantic domains.
    This seems to add credence to our desire to be able to distinguish between
    continuations and procedures.  If it is indeed decided that continuations and
    their eta converted versions [e.g., (lambda (v) (k v))] should be
    indistinguishable then the denotational semantics should be updated to reflect
    this similarity.

Assuming that the denotational semantics hasn't changed drastically since
R3RS, this is false.  The objects in the continuation domain are not handed
directly to users, and they would not function correctly if they were.  If
you will look at the definition of CALL-WITH-CURRENT-CONTINUATION I think
you will find that it carefully constructs an appropriate object from the
domain of procedures.  (Perhaps the name should be changed to
"CALL-WITH-PROCEDURE-CONTAINING-CURRENT-CONTINUATION".)  If we decide that
the objects created by CALL-WITH-CURRENT-CONTINUATION -are- distinguishable
from procedures, only then will it be necessary to change the denotational
semantics.

∂17-Jul-89  1533	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	Numbers  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89  15:33:31 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20859;
          17 Jul 89 18:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 18:08:13 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20761;
          17 Jul 89 18:05 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05320; Mon, 17 Jul 89 18:05:26 EDT
Received: from localhost by zurich.ai.mit.edu; Mon, 17 Jul 89 18:02:17 edt
Date: Mon, 17 Jul 89 18:02:17 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907172202.AA10010@zurich.ai.mit.edu>
To: Alan@REAGAN.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 17:29 EDT <19890717212952.6.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers

   Date: Mon, 17 Jul 89 17:29 EDT
   From: Alan Bawden <Alan@REAGAN.ai.mit.edu>

   >From the Unapproved Minutes of the Third Meeting of the IEEE Working Group
   on Scheme:

       5.5 Moved and accepted: Add expt to the list of procedures which
       must return an exact result when given exact arguments (section 6.5.3).

   Does this mean that (expt 2 50) -must- return an exact number?  Suppose I
   have an implementation with 32 bit FIXNUMs as my exact numbers, IEEE
   FLONUMs as my inexact numbers, but no BIGNUMs.  Am I forbidden from
   returning a FLONUM (inexact) answer, even though my FLONUMs have the range?
   Does this mean that (expt 2 50) would have to signal an error, even though
   (* (expt 2 25) (expt 2 25)) would be allowed to return a FLONUM (inexact)
   answer?

Whoa, calm down Alan.  The list of procedures is prefixed by the
following sentence: "Finally, the procedures listed below will always
return an exact integer result provided all their arguments are exact
integers and the mathematically expected result is representable as an
exact integer within the implementation:".  I don't think this should
be cause for alarm, especially since `*' is also in that list.

       The editors reaffirmed their intention to substantially extend
       appendix B.3, including, for instance, a discussion of the
       transitivity requirements for the numeric order and equality predicates.

   This should be fun.  Once you start letting people take their naive notions
   of how numbers should behave and turn them into -requirements-, all hell
   can break lose.  On what basis do you decide that the order predicates are
   required to be transitive, but that + is not required to be associative?
   The danger is that requirements may be adopted just in case people can
   imagine a way to meet them in an implementation that uses floating point
   for its inexact numbers.  Unless some restraint is exercised, this can
   eliminate plausible implementations of inexact numbers that aren't floating
   point.

Am I missing something, or weren't you a party to the discussions at
which it was decided that transitivity was a reasonable requirement?
Looking through my archives I don't see any objections from you and
there is one particular piece of mail which shows you in favor of it.

The reason transitivity is mentioned re appendix B.3 is that we intend
to explain why it is difficult to achieve this correctly, NOT why we
decided to make it a requirement.

In any case the appendix is non-binding so that anything stated there
cannot be a requirement.

∂17-Jul-89  1603	@MC.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89  16:03:07 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21526;
          17 Jul 89 18:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 17 Jul 89 18:54:27 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa21462;
          17 Jul 89 18:50 EDT
Received: from fafnir.think.com by Think.COM; Mon, 17 Jul 89 18:50:37 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 17 Jul 89 18:48:55 EDT
Received: by verdi.think.com; Mon, 17 Jul 89 18:48:53 EDT
Date: Mon, 17 Jul 89 18:48:53 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907172248.AA26384@verdi.think.com>
To: Alan@REAGAN.ai.mit.edu
Cc: gls@think.com, rrrs-authors@MC.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 17:29 EDT <19890717212952.6.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers

   Date: Mon, 17 Jul 89 17:29 EDT
   From: Alan Bawden <Alan@reagan.ai.mit.edu>

       Date: Fri, 14 Jul 89 15:51:27 EDT
       From: think!gls (Guy Steele)
       Subject: Confusion

       I now shift my position slightly.  I agree that a procedure that computes
       (??? 1.4 #e1e100) ==> 9.999999999999998e99 may be useful, and that SUP is a
       good name for it.  I also believe that a procedure is useful that is
       defined to return some one of its arguments such that the returned argument
       is >= all other arguments, and that MAX is a good name for that procedure.
       (One might also argue that, everything else being equal (!), MAX should
       return the least-exact argument having that property, but I won't push that.)

       Therefore I argue to include all of SUP, INF, MAX, and MIN.

       --Guy

   Except MAX and MIN have a bug with respect to the notion of exactness.
   They return an exact answer when they are not entitled to.  And they have
   the good names, so programmers will use them and nobody will use INF and
   SUP.  Doing this is a subtle way of degrading the concept of an exact
   number.

Of course they have the bug.  That's the point.  There is an inherent
conflict between the notions of "returns the biggest argument" and
"observes functional rules of exactness".  So I say give the user his
choice of bugs.  I am not impressed by arguments that the users will
necessarily be naive.

   ...	
   Indeed, if we do this, then MIN and MAX are unreliable in the same way that
   the numeric predicates are.  They will be the only numeric -functions- that
   require such a warning.  INF and SUP require no such warning.

So I happen to regard INF and SUP as "functions" (they really *do* something)
whereas MAX and MIN are just fancy "conditionals" (conditional selectors)
packaged up.  Note that CLtL places the descriptions of the Common Lisp MAX
and MIN in the section titled "Comparisons on Numbers", along with =, <, etc.;
they are not in with +, *, etc.

--Guy

∂17-Jul-89  1757	@MC.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89  17:57:43 PDT
Received: by mintaka.lcs.mit.edu id ab22949; 17 Jul 89 20:39 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22897;
          17 Jul 89 20:37 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 17 Jul 89 20:26:53 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 237082; Mon 17-Jul-89 20:26:32 EDT
Date: Mon, 17 Jul 89 20:26 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Numbers
To: gls@think.com
cc: rrrs-authors@MC.lcs.mit.edu
In-Reply-To: <8907172248.AA26384@verdi.think.com>
Message-ID: <19890718002629.0.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Mon, 17 Jul 89 18:48:53 EDT
    From: gls@Think.COM (Guy Steele)

       Date: Mon, 17 Jul 89 17:29 EDT
       From: Alan Bawden <Alan@reagan.ai.mit.edu>
       ...
       Except MAX and MIN have a bug with respect to the notion of exactness.
       They return an exact answer when they are not entitled to.  And they have
       the good names, so programmers will use them and nobody will use INF and
       SUP.  Doing this is a subtle way of degrading the concept of an exact
       number.

    Of course they have the bug.  That's the point.  There is an inherent
    conflict between the notions of "returns the biggest argument" and
    "observes functional rules of exactness".  So I say give the user his
    choice of bugs.  

Then you shouldn't mind if we make MIN and MAX behave the functional way,
and call the ones based on comparison BIGGEST and SMALLEST.

If, whenever someone doesn't like the consequences of the exactness rules,
we introduce a new procedure whose behavior he likes better, giving it the
old name and giving a new name to the old procedure, then ultimately what
good is exactness?  In order to reap the benefits of exactness the user has
to write his program using a bunch of unfamiliar names (unfamiliar to
computer weenies) like INF and SUP.

The functions FLOOR, CEILING, TRUNCATE and ROUND are the next candidates
for this treatment.  Shall we have two versions of each of them, one that
always returns an exact integer, even given an inexact argument, and
another that properly returns an inexact given an inexact?  (Assuming an
implementation in which inexacts are floating point -- if inexacts are
intervals, then FLOOR might really be able to properly return an exact.)
There are certainly people who would prefer the former behavior, even
though the latter is the proper representation of the mathematical
functions.

I'm quite serious when I suggest that if we can't apply the notion of
exactness consistently, then we should abandon it.  I would be perfectly
content if Scheme merely had some reasonable rules for floating point
numbers.  But if Scheme is going to pretend to do something cleaner and
more general, based on an actual -principle-, then it shouldn't be cowardly
about applying that principle.  

    I am not impressed by arguments that the users will necessarily be
    naive. 

I am.  It seems to me that the assumption that users will be naive is the
foundation of the art of programming language design.  I'm certainly very
naive when I'm writing programs, and I'm grateful for a programming
language that supports me by making the naive choice also the correct
choice as often as possible.

∂17-Jul-89  1905	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89  19:05:17 PDT
Received: by mintaka.lcs.mit.edu id aa23907; 17 Jul 89 21:53 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23823;
          17 Jul 89 21:45 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 17 Jul 89 21:08:57 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 237111; Mon 17-Jul-89 21:08:11 EDT
Date: Mon, 17 Jul 89 21:08 EDT
From: Alan Bawden <Alan@REAGAN.ai.mit.edu>
Subject: Numbers
To: cph@ZURICH.ai.mit.edu
cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907172202.AA10010@zurich.ai.mit.edu>
Message-ID: <19890718010808.1.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Mon, 17 Jul 89 18:02:17 edt
    From: cph@zurich.ai.mit.edu (Chris Hanson)

       Date: Mon, 17 Jul 89 17:29 EDT
       From: Alan Bawden <Alan@REAGAN.ai.mit.edu>

	   5.5 Moved and accepted: Add expt to the list of procedures which
	   must return an exact result when given exact arguments (section 6.5.3).

       Does this mean that (expt 2 50) -must- return an exact number?...

    Whoa, calm down Alan.  

Just what did I say that made you think I had lost my calm?  I was just
looking for clarification of what "-must- return an exact result" meant.

			   The list of procedures is prefixed by the
    following sentence: "Finally, the procedures listed below will always
    return an exact integer result provided all their arguments are exact
    integers and the mathematically expected result is representable as an
    exact integer within the implementation:".  I don't think this should
    be cause for alarm, especially since `*' is also in that list.

Actually, I'd be more interested to know what -isn't- on the list.  I'll
bet SQRT isn't there because people think that SQRT of an exact 4 should be
allowed to return something inexact rather than an exact 2.  Am I right?
I suspect that if I understood more about this "list" I would argue that
-all- numeric functions belonged on it (including SQRT).

       ...  On what basis do you decide that the order predicates are
       required to be transitive, but that + is not required to be
       associative?...

    Am I missing something, or weren't you a party to the discussions at
    which it was decided that transitivity was a reasonable requirement?

Probably.

    Looking through my archives I don't see any objections from you and
    there is one particular piece of mail which shows you in favor of it.

I don't recall ever strongly advocating it, but I do recall a time when I
through it would be reasonable.  I have changed my mind.  After accepting
two or three of these requirements on the behavior of inexact numbers (you
will recall that we tried to add requirements so that a portable number
printer was possible), I started to worry that I couldn't see when these
requirements were going to stop accumulating.

    The reason transitivity is mentioned re appendix B.3 is that we intend
    to explain why it is difficult to achieve this correctly, NOT why we
    decided to make it a requirement.

Well, the language that I quoted from the minutes certainly made it sound
like a requirement.  (What am I -supposed- to think "transitivity
requirements" means?)  I guess that's what makes those minutes unofficial.

∂17-Jul-89  2126	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #162 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 17 Jul 89  21:26:15 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25197;
          18 Jul 89 0:12 EDT
Date: 18 JUL 89  00:02:01 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #162 
To: Scheme@mc.lcs.mit.edu
Reply-to: Scheme@mc.lcs.mit.edu
Message-ID:  <8907180012.aa25197@mintaka.lcs.mit.edu>

Scheme Digest #162                             18 JUL 89  00:02:01 EDT

Today's Topics:

        Question: "Records" in scheme?

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

Date: 17 Jul 89 18:03:02 GMT
From: Brian of ASTD-CP <brian@topaz.rutgers.edu>
Subject: Question: "Records" in scheme?
Message-Id: <1455@jato.Jpl.Nasa.Gov>

Is there a way to create contiguous-memory aggregate variables in
scheme?  I'd like to be able to read in some arrays of structs
created by a C program (equivalent to arrays of records in Pascal)
into scheme, parse & plot them, and translate parts of them into
scheme lists / vectors.  I guess I could print the data out and
read them into scheme data structures, using ASCII as the
communication medium, but they're on the big side (several megs)
and I'd prefer to read them in "binary format" if possible.

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

End of Scheme Digest
********************

∂18-Jul-89  0833	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89  08:33:50 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01518;
          18 Jul 89 11:28 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 11:25:02 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa01452;
          18 Jul 89 11:23 EDT
Received: from fafnir.think.com by Think.COM; Tue, 18 Jul 89 11:23:55 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 18 Jul 89 11:22:07 EDT
Received: by verdi.think.com; Tue, 18 Jul 89 11:22:03 EDT
Date: Tue, 18 Jul 89 11:22:03 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907181522.AA29642@verdi.think.com>
To: Alan@REAGAN.ai.mit.edu
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 20:26 EDT <19890718002629.0.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers

   Date: Mon, 17 Jul 89 20:26 EDT
   From: Alan Bawden <Alan@reagan.ai.mit.edu>

       Date: Mon, 17 Jul 89 18:48:53 EDT
       From: gls@Think.COM (Guy Steele)

	  Date: Mon, 17 Jul 89 17:29 EDT
	  From: Alan Bawden <Alan@reagan.ai.mit.edu>
	  ...
	  Except MAX and MIN have a bug with respect to the notion of exactness.
	  They return an exact answer when they are not entitled to.  And they have
	  the good names, so programmers will use them and nobody will use INF and
	  SUP.  Doing this is a subtle way of degrading the concept of an exact
	  number.

       Of course they have the bug.  That's the point.  There is an inherent
       conflict between the notions of "returns the biggest argument" and
       "observes functional rules of exactness".  So I say give the user his
       choice of bugs.  

   Then you shouldn't mind if we make MIN and MAX behave the functional way,
   and call the ones based on comparison BIGGEST and SMALLEST.

Despite the implied moral obligation to the contrary, in fact I do mind.
"Maximum" *means* "biggest", and "minimum" means "smallest".

However, research into the terminology leads me to another proposal.

"Supremum" and "infimum" refer to height, whereas "maximum" and "minimum"
technically (and literally) refer to *magnitude*:

Adjective	superus    inferus    magnus    parvus
Comparative	superior   inferior   major     minor
Superlative	supremus   infimus    maximus   minimus

[Yes, that really is "parvus", not something reasonable
like "minus". Don't blame me.]

From this I conclude that respect for the original meanings of the
terms would lead us to define SUP and INF to be what everyone else
calls MAX and MIN (ignoring for the moment the treatment of exactness).
We would then define (MAX A B) to be (SUP (ABS A) (ABS B)), and similarly
define MIN as INF of ABS's.  But I suppose computer "science" has
already blown that one for us as well, in the same way that people
sloppily refer to a floating-point significand as a "mantissa",
or use "<>" when they mean "/=".

   If, whenever someone doesn't like the consequences of the exactness rules,
   we introduce a new procedure whose behavior he likes better, giving it the
   old name and giving a new name to the old procedure, then ultimately what
   good is exactness?  In order to reap the benefits of exactness the user has
   to write his program using a bunch of unfamiliar names (unfamiliar to
   computer weenies) like INF and SUP.

The issue is not reaping the benefits of exactness; it is reaping the
benefits of inexactness.  Let us not confuse the two.

As long as we are having fun being polemical (:-), let me also ask this
question: is it the purpose of the rrrs-authors to cater primarily to
computer weenies?  (Read: to those corrupted by the accidents of prior
history?)

If the answer is "yes", then let me point out that Scheme weenies are
vastly outnumbered by C weenies, and every C weenie has the formula

	#define max(x,y) ((x) > (y)) ? (x) : (y)

engraved in his little weenie brain.  See?  MAX really is a conditional.

   The functions FLOOR, CEILING, TRUNCATE and ROUND are the next candidates
   for this treatment.  Shall we have two versions of each of them, one that
   always returns an exact integer, even given an inexact argument, and
   another that properly returns an inexact given an inexact?  (Assuming an
   implementation in which inexacts are floating point -- if inexacts are
   intervals, then FLOOR might really be able to properly return an exact.)
   There are certainly people who would prefer the former behavior, even
   though the latter is the proper representation of the mathematical
   functions.

There is a third possibility: if the inexactness is down at the level that
you can be sure that the integer result is exact (say you know the argument
to within .001 and it is well away from being an integer or half-integer,
as the case may be), then return an exact result; otherwise return an
inexact result (but note that the uncertainty of the result may be
relatively much, much larger than the uncertainty of the input).

   I'm quite serious when I suggest that if we can't apply the notion of
   exactness consistently, then we should abandon it.  I would be perfectly
   content if Scheme merely had some reasonable rules for floating point
   numbers.  But if Scheme is going to pretend to do something cleaner and
   more general, based on an actual -principle-, then it shouldn't be cowardly
   about applying that principle.  

I agree.

       I am not impressed by arguments that the users will necessarily be
       naive. 

   I am.  It seems to me that the assumption that users will be naive is the
   foundation of the art of programming language design.  I'm certainly very
   naive when I'm writing programs, and I'm grateful for a programming
   language that supports me by making the naive choice also the correct
   choice as often as possible.

IBM has touted ACRITH as a system that, by using high precision and
interval arithmetic, will save you from all possible ills.  See issues of
ACM SIGNUM for descriptions of why it actually loses horribly in many
cases.  I suspect that inexactness as currently treated by Scheme is
no panacea.

Gee, Alan, this is fun!  Best flame I've had this year.

--Guy

∂18-Jul-89  0901	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	Distinct types for continuations?  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89  09:01:44 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01826;
          18 Jul 89 11:53 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 11:48:53 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01764;
          18 Jul 89 11:46 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA14602; Tue, 18 Jul 89 11:45:56 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 18 Jul 89 11:42:45 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA23868; Tue, 18 Jul 89 08:44:43 PDT
Date: Tue, 18 Jul 89 08:44:43 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907181544.AA23868@sesame.Stanford.EDU>
To: Alan@reagan.ai.mit.edu
Cc: shaff@sesame.stanford.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 17:46 EDT <19890717214647.7.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Distinct types for continuations?

   Date: Mon, 17 Jul 89 17:46 EDT
   From: Alan Bawden <Alan@REAGAN.ai.mit.edu>

       Date: Mon, 17 Jul 89 09:52:43 PDT
       From: Mike Shaff <shaff@sesame.stanford.edu>
       According to our reading of Will's denotational semantics for R3.95RS,
       continuations and procedures of one argument are in different semantic domains.

   Assuming that the denotational semantics hasn't changed drastically since
   R3RS, this is false.  The objects in the continuation domain are not handed
   directly to users, and they would not function correctly if they were.  If
   you will look at the definition of CALL-WITH-CURRENT-CONTINUATION I think
   you will find that it carefully constructs an appropriate object from the
   domain of procedures.  

Now, somewhat bleary eyed from staring at denotational semantics, I have come
to recognize the source of my original misinterpretation and agree with Alan
that the domains of procedures and objects returned from
call-with-current-continuation are the same.  Furthermore, I am no longer as
firmly convinced that predicates which distinguish between procedures and
continuations are necessary.  However, if we only have a single procedure, I
believe that PROCEDURE? is a serious misnomer.  The function should really be
called APPLICABLE?.


    (Perhaps the name should be changed to
    "CALL-WITH-PROCEDURE-CONTAINING-CURRENT-CONTINUATION".)  

Perish the thought.  The name is long enough now that almost everyone uses
either CWCC or CALL/CC.  I can't even imagine typing CWPCCC.

-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂18-Jul-89  0925	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	ELSE in Scheme 
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89  09:25:34 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02319;
          18 Jul 89 12:20 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 12:17:54 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02092;
          18 Jul 89 12:12 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA15011; Tue, 18 Jul 89 12:12:16 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 18 Jul 89 12:09:06 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA24061; Tue, 18 Jul 89 09:11:25 PDT
Date: Tue, 18 Jul 89 09:11:25 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907181611.AA24061@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Subject: ELSE in Scheme

The following suggestion is intended to be noncontroversial and should be
considered to be self retracting upon the first serious objection.

According to my historian, ELSE was originally introduced into Scheme because
in the old days there was no printable/typable representation for the true
object.  This made it impossible to reliably specify an else clause for a COND.
The situation has changed since #t has been introduced in Scheme, and we are no
longer dependent on the tenuous binding of T to the truth object.  As a result,
ELSE is no longer really needed as a syntactic keyword.  I personally believe
that we should endeavor to minimize the number of keywords in Scheme.  I
therefore advocate that we remove ELSE from the list of syntactic keywords and
replace ELSE by #T in the COND examples in RNRS.  The dusty deck problem is
solved trivially by including (define ELSE #t) in a compatibility environment.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂18-Jul-89  1014	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	Numbers  
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89  10:13:56 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02825;
          18 Jul 89 13:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 12:57:24 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02696;
          18 Jul 89 12:51 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA15541; Tue, 18 Jul 89 12:51:44 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 18 Jul 89 12:48:30 edt
Date: Tue, 18 Jul 89 12:48:30 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907181648.AA14360@zurich.ai.mit.edu>
To: Alan@reagan.ai.mit.edu
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 17 Jul 89 21:08 EDT <19890718010808.1.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers

   Date: Mon, 17 Jul 89 21:08 EDT
   From: Alan Bawden <Alan@REAGAN.AI.MIT.EDU>

       Date: Mon, 17 Jul 89 18:02:17 edt
       From: cph@zurich.ai.mit.edu (Chris Hanson)

       Whoa, calm down Alan.  

   Just what did I say that made you think I had lost my calm?  I was just
   looking for clarification of what "-must- return an exact result" meant.

My apologies -- in retrospect there was nothing to indicate this and
my flippant comment was misplaced.

   Actually, I'd be more interested to know what -isn't- on the list.  I'll
   bet SQRT isn't there because people think that SQRT of an exact 4 should be
   allowed to return something inexact rather than an exact 2.  Am I right?
   I suspect that if I understood more about this "list" I would argue that
   -all- numeric functions belonged on it (including SQRT).

Correct.  I suppose it's a matter of practicality -- nobody wanted to
commit to implement `sqrt' to handle this case specially, presumably
because such behavior isn't too interesting.  To take it further, I
suppose it wouldn't hurt to add the transcendental functions to the
list, since there should be no case where exact integer arguments
produce a mathematical result which is an integer (I'm guessing on
this -- but I suspect it's true).

Here is a list of those number-valued procedures that do not appear in
the list:

    / sqrt
    exp log sin cos tan asin acos atan make-polar angle
    make-rectangular real-part imag-part magnitude
    exact->inexact inexact->exact

The only good reason why `/' and `sqrt' should not be in the list is
efficiency and implementation complexity.  Maybe that's not good
enough.  

I suspect that there's no argument for keeping the transcendental
functions out of the list since my intuition tells me that there is no
case where integer arguments provide an integer result; if there is
such a case, it's probably pretty obscure, and perhaps that would be a
good reason to exclude them from the list.  A similar argument holds
for `make-polar' and `angle'.

For the procedures in the third line above, I see no reason not to
include them in the list as well.  Finally, `exact->inexact' clearly
cannot be in the list, while `inexact->exact' should have been
included in the first place.

Summary: the only procedures that seem to matter are `/' and `sqrt',
and the argument in favor of excluding them is pragmatic.

       Am I missing something, or weren't you a party to the discussions at
       which it was decided that transitivity was a reasonable requirement?

   Probably.

       Looking through my archives I don't see any objections from you and
       there is one particular piece of mail which shows you in favor of it.

   I don't recall ever strongly advocating it, but I do recall a time when I
   through it would be reasonable.  I have changed my mind.  After accepting
   two or three of these requirements on the behavior of inexact numbers (you
   will recall that we tried to add requirements so that a portable number
   printer was possible), I started to worry that I couldn't see when these
   requirements were going to stop accumulating.

I remember those discussions.  I believe that most of the requirements
were eliminated in the final draft, but the transitivity requirement
was not.  I believe the reason for the transitivity requirement was to
eliminate the N-squared behavior on the number of arguments, which
seems like a pretty good reason to me.

       The reason transitivity is mentioned re appendix B.3 is that we intend
       to explain why it is difficult to achieve this correctly, NOT why we
       decided to make it a requirement.

   Well, the language that I quoted from the minutes certainly made it sound
   like a requirement.  (What am I -supposed- to think "transitivity
   requirements" means?)  I guess that's what makes those minutes unofficial.

There is an explicit transitivity requirement in the R4RS numbers
section, which was placed there after earlier discussions of which you
were a part.  The IEEE Standard picked up this requirement along with
the rest of the numbers section.  However, the decision reached at the
meeting was to expand the appendix to explain the consequences of this
requirement.  Perhaps the minutes should be edited to make this
clearer.

∂18-Jul-89  1206	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by SAIL.Stanford.EDU with TCP; 18 Jul 89  12:06:46 PDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04500;
          18 Jul 89 15:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Jul 89 14:56:41 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa04376;
          18 Jul 89 14:52 EDT
Received: from fafnir.think.com by Think.COM; Tue, 18 Jul 89 14:52:45 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 18 Jul 89 14:51:02 EDT
Received: by verdi.think.com; Tue, 18 Jul 89 14:51:00 EDT
Date: Tue, 18 Jul 89 14:51:00 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907181851.AA02935@verdi.think.com>
To: cph@zurich.ai.mit.edu
Cc: Alan@REAGAN.ai.mit.edu, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 18 Jul 89 12:48:30 edt <8907181648.AA14360@zurich.ai.mit.edu>
Subject: Numbers

   Date: Tue, 18 Jul 89 12:48:30 edt
   From: Chris Hanson <cph@zurich.ai.mit.edu>
								 ... I
   suppose it wouldn't hurt to add the transcendental functions to the
   list, since there should be no case where exact integer arguments
   produce a mathematical result which is an integer (I'm guessing on
   this -- but I suspect it's true).

 0
e  = cos 0 = 1.  But you are right if you say there are *very*
few such exceptions.

∂18-Jul-89  1528	cph@zurich.ai.mit.edu 	test message
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Jul 89  15:28:27 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA19538; Tue, 18 Jul 89 18:01:58 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 18 Jul 89 17:58:54 edt
Date: Tue, 18 Jul 89 17:58:54 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8907182158.AA16987@zurich.ai.mit.edu>
To: rrrs-authors@ai.mit.edu
Subject: test message

This is a test, please ignore.

∂18-Jul-89  2204	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #163 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 18 Jul 89  22:04:29 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA23793; Wed, 19 Jul 89 00:20:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09750;
          19 Jul 89 0:05 EDT
Date: 19 JUL 89  00:01:59 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #163 
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id:  <8907190005.aa09750@mintaka.lcs.mit.edu>

Scheme Digest #163                             19 JUL 89  00:01:59 EDT

Today's Topics:

        scheme for unix systems
        test message

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

Date: 18 Jul 89 20:06:55 GMT
From: gwusun!bleen.gwu.edu!stoler@uunet.uu.net
Subject: scheme for unix systems
Message-Id: <1418@bleen.gwusun.gwu.edu>

We are in the process of installing an HP 9000/835se and need to know of
an implementation of scheme that runs on said machine.

We also need to know of implementations that run on a SUN 3/180 and
similar machines.

Public domain implementations that can be ftp'd would be nice but commercial
products are okay too.

Thanks all.

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

Date: Tue, 18 Jul 89 18:06:27 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907182206.AA16993@zurich.ai.mit.edu>
Subject: test message

This is a test message, please ignore.

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

End of Scheme Digest
********************

∂19-Jul-89  2155	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #164 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 19 Jul 89  21:55:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12182; Thu, 20 Jul 89 00:20:05 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24709;
          20 Jul 89 0:03 EDT
Date: 20 JUL 89  00:02:08 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #164 
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id:  <8907200003.aa24709@mintaka.lcs.mit.edu>

Scheme Digest #164                             20 JUL 89  00:02:08 EDT

Today's Topics:

        Scheme for unix systems

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

From: Duke Briscoe <briscoe-duke@YALE.EDU>
Message-Id: <8907191538.AA13269@ELI.CS.YALE.EDU>
Date: Wed, 19 Jul 89 11:41:23 EDT
Subject: re: Scheme for unix systems

The T language has a Scheme environment which is about 99% compatible
with the Scheme standard, based on my recent experience porting
several thousand lines of Scheme code to the T system.  The quality of
the T compiler is very good, producing code which is comparable in
speed to Pascal and C.  It also adds some useful extensions to Scheme,
including multiple return values, a simple object system, debugger and
inspector, macros, structures, hash tables.  It is available for
VAXes, Sun 3, Apollo, HPs, and both parallel and sequential versions
for Encore Multimax.  According to the information I have from Lisp
Pointers Vol. 1, #6, it is available by FTP from some sites at MIT,
but I just tried there, and I couldn't find it.  Maybe someone else
can give the latest info on how to get it.

-------


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

End of Scheme Digest
********************

∂20-Jul-89  1457	@mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu 	BYTES (a.k.a. 1's and 0's)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Jul 89  14:57:04 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA22327; Thu, 20 Jul 89 17:38:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06187;
          20 Jul 89 17:33 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU 20 Jul 89 17:33:54 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 276082; 20 Jul 89 17:33:48 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Thu, 20 Jul 89 17:33:11 EDT
Message-Id: <2825962373-3531500@RTS-8>
Sender: ziggy@rts-8.lcs.mit.edu
Date: Thu, 20 Jul 89  17:32:53 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: BYTES (a.k.a. 1's and 0's)

 I am building a simulator for a computer CPU, which is much like building an
interpreter for a language.  My problem is that the processor instruction set I
want to simulate includes instructions like LOGICAL-AND, SHIFT-LEFT, ROTATE,
SIGN-EXTEND and such like, for 2's complement numbers.

 My problem is that I *know* that the underlying processor my Scheme is running
on has these instructions but my portable Revised↑3 implementation of Scheme
does not give me access to these underlying instructions (precisely because they
are not in the Revised↑3 manual).

 It seems a *real* inconvenience to implement these (say) as procedures over
lists/vectors of booleans and I don't cherish the thought of MOD/QUOT-ing till
I'm blue in the face. And it's a shame knowing these features are just out of
reach, buried behind an abstraction barrier between my CPU and Scheme.

 Has there ever been a proposal to add this stuff to the Report?
 If so, what were the compelling reasons for it's rejection?
 Does anyone have a Revised↑3 portable implementation of this stuff I can use
   in the meantime?
 Doesn't Bombin' LISP (oh, sorry... Common LISP) provide such a facility?
 Should I be using a non-toy language like C instead? (;-)!!!!!!!)
								    Cheers,
								    ~Ziggy

∂20-Jul-89  1631	@mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu 	Bitwise logical operations    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Jul 89  16:31:18 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA23471; Thu, 20 Jul 89 19:12:36 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07222;
          20 Jul 89 19:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 20 Jul 89 19:08:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07202;
          20 Jul 89 19:04 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA23338; Thu, 20 Jul 89 19:04:18 EDT
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by zurich.ai.mit.edu; Thu, 20 Jul 89 19:01:07 edt
Received: from Edusa.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA23454; Thu, 20 Jul 89 16:01:31 PDT
Message-Id: <8907202301.AA23454@mojave.Stanford.EDU>
Received: by sid; Thu, 20 Jul 89 16:03:52 pdt
Date: Thu, 20 Jul 89 16:03:52 pdt
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Thu, 20 Jul 89  17:32:53 EDT <2825962373-3531500@RTS-8>
Subject: Bitwise logical operations
From: Jonathan Rees <jar%sid.stanford.edu@polya.stanford.edu>
Sender: jar@sid.stanford.edu

Come on now, you can define everything you need in Revised↑3 Scheme!

    (define (lognot i)
      (- -1 i))

    (define (logand x y)
      (cond ((= x 0) 0)
	    ((= x -1) y)
	    (else
	     (+ (ash (logand (ash x -1) (ash y -1)) 1)
		(if (and (odd? x) (odd? y)) 1 0)))))

    (define (logior x y)
      (lognot (logand (lognot x) (lognot y))))

    (define (logxor x y)
      (logand (lognot (logand x y)) (logior x y)))

    (define (ash n m)
      (define (ash-nonnegative n m)
	(if (> m 0)
	    (* n (expt 2 m))
	    (quotient n (expt 2 (- m)))))
      (cond ((or (= m 0) (= n 0)) n)
	    ((> n 0) (ash-nonnegative n m))
	    ((> m 0)
	     (- (ash-nonnegative (- n) m)))
	    (else
	     (lognot (ash-nonnegative (lognot n) m)))))

Seriously, however, I agree with you.  I think Scheme should include
two's-complement bitwise logical operations that work on integers.
I'd suggest adding to the report something similar to a subset of what
Common Lisp provides.  How about:

  (logand i1 ...)
  (logior i1 ...)
  (logxor i1 ...)
  (lognot i)
  (ash i1 i2)
  (integer-length i)

with the same meanings as in Common Lisp (assuming I remember the
Common Lisp names properly).  Of course they have to be insensitive to
word length.

Load bit field and deposit bit field are also pretty useful, but I
wouldn't advocate inventing a byte specifier pseudo-type like CL does.
Nor would I approve of CL's argument order, which I find impossible to
remember.

Logical shift and rotate don't make sense unless a word size is
supplied.  They can be synthesized pretty easily given the other
operations, so I'd say don't include them.

∂21-Jul-89  0124	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: last call: changes for R4RS 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  01:23:54 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28369; Fri, 21 Jul 89 04:11:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12217;
          21 Jul 89 2:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:42:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12174;
          21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27578; Fri, 21 Jul 89 02:38:11 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:07 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 10:33:29 PDT
Date: Thu, 20 Jul 89 10:34:19 PDT
From: Pavel.pa@xerox.com
Subject: Re: last call: changes for R4RS
In-Reply-To: <8907130003.AA17137@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-103329-118@Xerox>

I'd rather that we did not cut off debate on R4RS at the end of this month.
It seems to me that there are several reasonably important issues currently
on the table that could make it into R4RS in the very near future (e.g.,
uniform definition semantics, fluid binding, and regularization of
procedures).  I would hate to see R4RS come out so little changed from the
previous report; in a sense, what's the point?

I do, however, understand the desire of the IEEE group to have a solid
commitment from the authors very soon.  They might be satisfied, though,
with a promise that the set of valid R4RS programs will be a superset of
the valid R3.99RS programs.  None of the proposals I mentioned above
violate this promise (the only non-trivial case is uniform definition
semantics; the liberalized semantics supported by John Ramsdell and me does
not change the meaning of any valid R3.95RS program).  In this way, the
IEEE group can proceed with the assurance that they will publish a
conservative subset of R4RS without requiring that report to be finalized
immediately.

	Pavel

∂21-Jul-89  0125	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: last call: changes for R4RS 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  01:24:59 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28375; Fri, 21 Jul 89 04:14:15 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12219;
          21 Jul 89 2:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:42:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12176;
          21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27581; Fri, 21 Jul 89 02:38:25 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:16 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 10:58:57 PDT
Date: Thu, 20 Jul 89 10:59:23 PDT
From: Pavel.pa@xerox.com
Subject: Re: last call: changes for R4RS
In-Reply-To: <8907130003.AA17137@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-105857-125@Xerox>

    Controversial changes requiring positive action by the authors if they
are
    to be adopted in the R4RS:

    Section 6.3.
    P1178 has requested again that LIST-REF be made essential, for
parallelism
    with VECTOR-REF and STRING-REF.  Their previous request that LIST-TAIL
be
    made essential has been dropped.

I support this, strongly if the other non-controversial regularization
proposals are also accepted, and more weakly otherwise.

    Section 6.5.5.
    P1178 has requested that MIN and MAX be renamed INF and SUP.  The
rationale
    is that the somewhat surprising behavior of MIN and MAX when given
mixed
    exact and inexact arguments would be more acceptable if their names
were
    less familiar.  A second rationale is that the fact that the
mathematical
    infimum and supremum operations, when given an infinite set of
"arguments",
    may return a result that is not in the argument set; this is the
surprising
    thing about MIN and MAX, e.g. (MAX 1.4 #e1e100) ==>
9.999999999999998e99.
    Background: In any case, a note will be added to point out and explain
this
    behavior, which is required in order for exact results to be trusted.
It
    happens that MIN and MAX behave this way in Common Lisp as well,
although
    the motivation was rather different.

I believe that I agree with GLS on this one.  I do not see MAX as an
operation that computes a result in the same sense as addition.  Rather, it
is a convenient packaging of a common use of the <= function.  It seems to
me inconsistent that MAX should behave differently than the obvious
rewriting in terms of <=.  Once <= establishes a total order on the numbers
in any given implementation, MAX should perform the simple operation
implied by its name; that is, it should return the largest element in the
set of its arguments.  Just as <= does not return an ``inexact'' boolean,
MAX should not be affected by the exactness of its arguments.

I would have no problem with a repetition under MAX of the warning under <=
about comparing inexact numbers, so long as MAX is defined to return one of
its arguments.  If others have a great use for INF and SUP (by which I mean
what some are describing as the current semantics for MIN and MAX) then I
suppose I won't stand in the way; however, I feel strongly about the proper
meaning of MIN and MAX.

    Noncontroversial changes that will be adopted in the R4RS unless the
authors
    object:

    ...

    Section 6.2.
    EQV?-ness is preserved when storing into and fetching from the standard
    data structures (pairs, vectors, strings).  [Note: EQ?-ness isn't
    necessarily preserved.  Preservation of EQV?-ness implies preservation
    of exactness, which is the context in which P1178 requested this
change.]

I would be unhappy with any statement that distinguished between the
behavior of, for example, the car cell of a pair and the contents of a
lexical variable; EQ?-ness should not be guaranteed for one but not the
other.  Thus, I support this change only if it is extended to include
variables.  Pragmatically, the storage for a variable is just as likely to
be type-specialized as that for a pair or vector.

	Pavel

∂21-Jul-89  0342	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: legion  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  03:42:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29094; Fri, 21 Jul 89 06:30:36 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12221;
          21 Jul 89 2:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:42:50 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12178;
          21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27582; Fri, 21 Jul 89 02:38:26 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:22 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 11:10:44 PDT
Date: Thu, 20 Jul 89 11:11:17 PDT
From: Pavel.pa@xerox.com
Subject: Re: legion
In-Reply-To: <8907130005.AA17154@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-111044-128@Xerox>

  Date: Wed, 12 Jul 89 17:05:39 PDT
  From: will@cs.uoregon.edu

  If indeed we must add fluid variables to the language, then I think that
  we should do something very like Pavel's proposal.  I'm not keen on
  adding fluid variables, however.  If we are to add any dynamic features
  I'd rather add DYNAMIC-WIND, which seems simpler and more useful.  If
  we had DYNAMIC-WIND and a macro package, then people could pull their
  favorite semantics for fluid variables out of the yellow pages.

Unfortunately, DYNAMIC-WIND is not enough.  There appears to be a great
deal of confusion between the capabilities offered by DYNAMIC-WIND and
fluid binding; the two are completely orthogonal in general.  In
particular, on a shared-memory multiprocessor (I feel like a broken
record...), DYNAMIC-WIND cannot be used to implement fluid binding.  It can
only be used for shallow-binding implementations and, as I've described
twice already, shallow-binding cannot work correctly on a shared-memory
multiprocessor.

I would support an additional proposal to add DYNAMIC-WIND to the language,
but cannot support it to the exclusion of fluid binding.  If we are to
avoid discrimination against multiprocessor implementations like Scheme
Xerox, fluid binding must be a part of the language, not a yellow pages
package.

  Will:
      2.  (This reason is pretty weak.)  For the compiler writer, I
          think the freedom to rearrange definitions makes closure
          analysis a little simpler when procedure definitions are
          mixed with definitions of variables containing non-procedure
          values.

  This is incorrect.  The compiler would still have the freedom to move
  procedure definitions in front of other definitions, since it could
  make a difference only if the program is in error.  Once the procedure
  definitions have been grouped together, their order makes no difference
  under either semantics.

Given your retraction of this objection and John's and my unanswered
refutations of your first one, may we assume that you now support the
proposal to unify definition semantics?  If not, could you say more?

	Pavel

∂21-Jul-89  0346	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  03:46:16 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29100; Fri, 21 Jul 89 06:32:22 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12223;
          21 Jul 89 2:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:42:58 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12180;
          21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27587; Fri, 21 Jul 89 02:38:31 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:26 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 11:40:06 PDT
Date: Thu, 20 Jul 89 11:32:07 PDT
From: Pavel.pa@xerox.com
Subject: Re: Regularization of list, vector, and string procedures
In-Reply-To: <8907130007.AA17164@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-114006-139@Xerox>

Morry suggested adding a procedure named ``list?'' to test for a
null-terminated list.  Will approved, but preferred the name
``proper-list?''.

I thought this as well (the function is called ``proper-list?'' in Cedar
Scheme) and almost said so in my response to Morry.  First, however, I
looked up the definition of lists in R3RS.  In contrast to CLtL, which
explicitly allows ``list'' to refer both to ``true lists''
(null-terminated) and ``dotted lists'', R3RS is fairly strict on the point.
It says,

    ``A chain of pairs not ending in the empty list is called
    an IMPROPER LIST.  Note that an improper list is not a list.''

I thus concluded that ``proper-list?'' was a redundant name and that
``list?'' was more appropriate.  I don't feel very strongly about this,
though.

Will also says:

  I'd prefer to avoid generic procedures at the lowest levels of Scheme.
  Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
  LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?

Assuming that ``apply'' is initially bound to the same value as
``list-apply'', I don't object to this proposal.  It will be amusing to see
if I ever find a use for either of ``vector-apply'' or ``string-apply''.

Finally, Will made a proposal for higher-order functions ``make-map''  and
``make-for-each'' to provide for generalized mapping functionality.  I have
two objections to the proposal:

-- Since ``make-map'' takes a ``ref'' procedure for each aggregate
argument, it takes quadratic time to map down lists and other linked
structures.  While it might be the case, as Will states, that make-map
``could be made equally efficient for the cases that could be handled by
generic MAP'' (though I don't see how, in general), this inefficiency could
not be overcome for other, user-defined linked structures.  Thus, the
proposal is not as generally applicable as it might initially seem.

-- Such a facility crosses my threshold for the amount of experimentation
appropriate in the report.  To my knowledge, no implementation has any
experience with such a facility.  Thus, I would rather leave ``map'' and
``for-each'' as unsolved problems in R4RS and have Will or someone else
contribute an implementation of ``make-map'' and ``make-for-each'' to the
library.  Then we could all play around with them for a while before
committing them to the report.

	Pavel

∂21-Jul-89  0453	ramsdell@linus.mitre.org 	Priorities    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  04:52:59 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA29624; Fri, 21 Jul 89 07:33:00 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA28604; Fri, 21 Jul 89 07:29:25 EDT
Posted-Date: Fri, 21 Jul 89 07:29:03 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA06493; Fri, 21 Jul 89 07:29:04 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907211129.AA06493@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Priorities
Date: Fri, 21 Jul 89 07:29:03 EDT

I am worried that the important issues are being lost in this debate.
Let me give you my ranking of the issues.

(1) Issues from Snowbird.
  [A] Macros:  I had hoped to see some form of syntactic closures in
	R4RS.  I have heard there is no acceptable implementation
	of extend-syntax using syntactic closures yet.  It appears we
	must find an alternative to the Snowbird macro compromise.
  [B] Regularization of Procedure Names:  This is being discussed as
	it should be.

(2) Post Snowbird issues.
  [A] Uniform Definition Semantics:  Adding macros to Scheme may
	affect this proposal.
  [B] Fluid Binding:  Didn't Pavel say something about how this issue
	should be easy?

(3) Post R4RS issues.
  [A] Multiple Value Return:  We nearly had agreement, I suspect we
	could reach agreement in time for R5RS.
  [B] Modules:  There are no proposals on the table, but keep thinking!

I do not want to imply that the other issues being debated are not
worth discussing.  For example, I support the addition of bitwise
logical operators.  I just hope the above list of issues does not get
lost. 
John
 

∂21-Jul-89  0553	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: ELSE in Scheme    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  05:53:50 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00377; Fri, 21 Jul 89 08:39:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12227;
          21 Jul 89 2:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:43:13 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12184;
          21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27591; Fri, 21 Jul 89 02:38:39 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:35 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 20:07:57 PDT
Date: Thu, 20 Jul 89 12:05:04 PDT
From: Pavel.pa@xerox.com
Subject: Re: ELSE in Scheme
In-Reply-To: <8907181611.AA24061@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-200757-1264@Xerox>

I would rather see ELSE remain in the language.  The old LISP idiom of
using T as the predicate in the final COND-clause always struck me as a
hack that sort of ``happens'' to work.  In my mind ELSE is more abstract
and thus easier to read.  I remember, as a Common Lisp programmer, first
reading about Scheme and being pleased with ELSE's presence.  I always used
OTHERWISE at the end of my Common Lisp CASE expressions, too.

	Pavel

∂21-Jul-89  0807	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Fluid binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  08:07:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01820; Fri, 21 Jul 89 10:45:47 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12225;
          21 Jul 89 2:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 02:43:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12182;
          21 Jul 89 2:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27590; Fri, 21 Jul 89 02:38:36 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 02:35:30 edt
Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 89 20:07:15 PDT
Date: Thu, 20 Jul 89 12:01:25 PDT
From: Pavel.pa@xerox.com
Subject: Re: Fluid binding
In-Reply-To: <8907130921.AA28558@hpda.HP.COM>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890720-200715-1255@Xerox>

  Date: Thu, 13 Jul 89 02:20:39 pdt
  From: Guillermo J. Rozas <jinx@hpesogg.hp.com>

  I think calling these objects fluid "variables" in the context of
  other Scheme variables is very misleading.  Lexical (ordinary) Scheme
  variables can't be aliased, since their addresses cannot be passed
  around.  These can.  Lexical variables can only be affected by special
  forms, these can be affected (and usually are) by procedures.  Lexical
  variables are not first class, they are not even objects since they
  are not expressible values.  Yours are first class objects.  It seems
  to me that these fluid variables are much more similar to pairs than
  to anything else in the language.

  Let's put it another way.  In the absence of FLUID-LET, what is the
  difference between your fluids and 1-slot records?  Your
  interpretation is that there is a lot of hair in fluid environments,
  etc.  Mine is simpler: there are cells, and there is a special form
  which establishes a temporary/isolated contents for them.  Except for
  efficiency, there is no reason why that could not be generalized to
  pairs, vectors, etc.

Fascinating; your perspective is completely opposite to mine.  You ask,
``In the absence of FLUID-LET, what is the difference between your fluids
and 1-slot records?''  The answer, clearly, is ``nothing''.  But FLUID-LET
is the whole issue, isn't it?  You perceive my interpretation in terms of a
fluid environment as ``a lot of hair'', but it seems to me this idea os
``temporary/isolated contents'' is considerably hairier.  In particular,
FLUID-LET in your interpretation is a side-effect that must carefully be
un-done or re-done whenever control leaves or re-enters the body of the
form.  This seems very messy to me, conceptually; I shudder to think how it
would look when added to the formal semantics.  A fluid environment, on the
other hand, is another instance of a well-understood concept.  It is
essentially trivial to add it to the formal semantics, and under that
conception, FLUID-LET is no more a side-effect than LET.

Perhaps we can avoid having to convince one another on this issue, however.
If you could agree to leave the names MAKE-FLUID, FLUID-REF, FLUID-SET!,
FLUID-LET, and WITH-FLUID-BINDING, I would certainly have no problem with
describing both conceptions in the informal definition in the report.

This brings up the issue of using the name FLUID-LET even though it
currently has different meanings in certain implementations.  I suggested
renaming the current forms to make way for the new meaning.  Jinx replied:

  Your solution assumes that you can reach all code that used FLUID-LET.
  That is unlikely in a wide-spread implementation.

But surely a wide-spread implementation has some social mechanism by which
the changes in the supported language are communicated to the users.  Let
your release notes mention prominently that the name of the form has
changed.  The fix to user code is easy for each user to apply.

  A second objection is purely based on the name.  I don't think that
  FLUID-LET is a very appropriate name for your form, since it is (in my
  mind, where all you are doing is data structure manipulation)
  unrelated to LET.  I'd much rather have your form be called ISOLATE,
  TEMPORARILY, or something like that.

As noted above, I disagree strongly with this conception of what's going on
in these forms.  Can we find some middle ground that lets both of us retain
our models?

Hopefully,

	Pavel

∂21-Jul-89  0812	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	last call: changes for R4RS    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  08:11:28 PDT
Received: from Score.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB01839; Fri, 21 Jul 89 10:48:18 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa14471;
          21 Jul 89 6:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 06:07:53 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa14438;
          21 Jul 89 6:00 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA28950; Fri, 21 Jul 89 06:00:10 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 05:57:06 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA09171; Fri, 21 Jul 89 02:59:50 pdt
Message-Id: <8907210959.AA09171@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 02:58:57 pdt
Date: Fri, 21 Jul 89 02:58:57 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 10:59:23 PDT <890720-105857-125@Xerox>
Subject: last call: changes for R4RS
Reply-To: jinx%hpesogg@sde.hp.com


    I believe that I agree with GLS on this one.  I do not see MAX as an
    operation that computes a result in the same sense as addition.  Rather, it
    is a convenient packaging of a common use of the <= function.  It seems to
    me inconsistent that MAX should behave differently than the obvious
    rewriting in terms of <=.  Once <= establishes a total order on the numbers
    in any given implementation, MAX should perform the simple operation
    implied by its name; that is, it should return the largest element in the
    set of its arguments.  Just as <= does not return an ``inexact'' boolean,
    MAX should not be affected by the exactness of its arguments.

I don't understand people's desire for MAX/SUP and MIN/INF to return a
result EQV? to one of the inputs.  

Perhaps there is still confusion about the issues, so let's consider
the consequences in a typical implementation (all inexact reals are
represented as floating point, exact integers have unlimited range):

- max/sup is given a set of exact reals.  The result will be an exact
real both = and eqv? to one of the inputs.  No surprises here.

- max/sup is given a set of inexact numbers.  The result will be an
inexact number both = and eqv? to one of the inputs.  No surprises here.

- max/sup is given a mixture of exact numbers and inexact numbers:

The first observation is that the fact that the result is inexact
should cause no problems in code, since after all, the inputs were of
mixed exactness and thus the "largest input" might easily have been
inexact.  In particular doing (vector-ref v (max ...)) where the
arguments to max are of mixed exactness is clearly foolish.  Thus the
only problem is the fact that the result may not be eqv? or even = to
one of the inputs.

The possibilities are as follows:

1) The "largest" input happens to be inexact.  No surprises here.

2) The "largest" input is exact, and its value can be represented as
an inexact number without any loss of precision.  The result will be =
to one of the inputs, although not eqv?

3) The "largest" input is exact, but its value is too large be
represented as an inexact number.  It seems to me that under these
circumstances a good implementation should signal an implementation
error because of an out of range coercion.

4) The "largest" input is exact, but its value cannot be represented
as an inexact number without loss of precision (the bignum has more
significant bits than the length of the mantissa in the floating point
representation).  A good implementation would coerce to floating point
rounding towards infinity (ie. add 1 at the least significant mantissa
bit after truncating the bits) in order to return a value >= than all
the inputs.

Thus the "surprises" arise from cases 2, 3, and 4 above.

I think that cases 3 and 4 are rare, since mixed bignum/inexact
computation is not common (in my experience).  The level of surprise
here is pretty low.  Case 3 in particular would probably be less
surprising, although more annoying.  Note also that cases 3 and 4 can
be "fixed" if the implementation includes an exactness bit for
bignums, since the result would then be = to one of the inputs.

Case 2 is the only really surprising case.  This arises from max/sup'ing
2 and 1.5, for example.  How surprising is it really?  The result is =
to the largest input, and depending on eqv? of the result is at best
obscure, so the only surprise would come in output, where the inexact
value would have a decimal digit and the exact would not.
Is this really so worrisome to everyone?  It seems to me that the
people worried about the surprise factor are worrying too much about
exactly one case, namely what their interactive system will print when
they call max/sup or min/inf from top level, but that is not very
interesting, or worth worrying much about.

PS:

(define (max/sup a b)
  (/ (+ (+ a b) (abs (- a b)))
     2))

[Modulo overflow or roundoff]

Inexact contagion implies that the result should be inexact if either
input is inexact.

∂21-Jul-89  1019	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	legion
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  10:19:25 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03373; Fri, 21 Jul 89 12:54:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15136;
          21 Jul 89 7:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 07:44:31 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15117;
          21 Jul 89 7:40 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29723; Fri, 21 Jul 89 07:40:12 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 07:37:08 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA10355; Fri, 21 Jul 89 04:39:56 pdt
Message-Id: <8907211139.AA10355@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 04:39:05 pdt
Date: Fri, 21 Jul 89 04:39:05 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 11:11:17 PDT <890720-111044-128@Xerox>
Subject: legion
Reply-To: jinx%hpesogg@sde.hp.com

    Unfortunately, DYNAMIC-WIND is not enough.  There appears to be a great
    deal of confusion between the capabilities offered by DYNAMIC-WIND and
    fluid binding; the two are completely orthogonal in general.  In
    particular, on a shared-memory multiprocessor (I feel like a broken
    record...), DYNAMIC-WIND cannot be used to implement fluid binding.  It can
    only be used for shallow-binding implementations and, as I've described
    twice already, shallow-binding cannot work correctly on a shared-memory
    multiprocessor.

I agree that dynamic-wind is not enough, but it is not independent of
fluid-binding.  The multiprocessor implementation of fluid binding can
still be based on dynamic-wind:

(fluid-let ((<cell> <value>))
  <code>)

expands into

(with-new-fluid-value <cell> <value> (lambda () <code>))

with

(define (with-new-fluid-value fluid-cell new-value thunk)
  (with-fluid-bindings-list
    (cons (cons fluid-cell new-value)
	  (get-fluid-bindings-list))
    thunk))

(define (with-fluid-bindings-list inside)
  (let ((outside (get-fluid-bindings-list)))
    (dynamic-wind	
     (lambda ()
       (set-fluid-bindings-list! inside))
     thunk
     (lambda ()
       (set-fluid-bindings-list! outside)))))

(define (user-cwcc receiver)
  (with-fluid-bindings-list
    (get-fluid-bindings-list)
    (lambda ()
      (primitive-cwcc-that-knows-about-dynamic-wind
       receiver))))

Where set/get-fluids-bindings-list operate on the process/processor state.

Dynamic-wind still offers the correct isolation between the region
with the new binding and the region with the original binding.  The
difference is how the entry and exit thunks swap bindings.

∂21-Jul-89  1220	cph@zurich.ai.mit.edu 	test   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  12:20:36 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA04573; Fri, 21 Jul 89 14:29:07 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 21 Jul 89 14:26:04 edt
Date: Fri, 21 Jul 89 14:26:04 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8907211826.AA04776@zurich.ai.mit.edu>
To: scheme-inbox@ai.mit.edu
Subject: test

Another test message, please ignore.

∂21-Jul-89  1449	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Regularization of list, vector, and string procedures   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  14:49:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06938; Fri, 21 Jul 89 17:27:35 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15291;
          21 Jul 89 8:04 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 08:04:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15232;
          21 Jul 89 7:57 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29809; Fri, 21 Jul 89 07:56:58 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 07:53:42 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA10576; Fri, 21 Jul 89 04:56:29 pdt
Message-Id: <8907211156.AA10576@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 04:55:30 pdt
Date: Fri, 21 Jul 89 04:55:30 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 11:32:07 PDT <890720-114006-139@Xerox>
Subject: Regularization of list, vector, and string procedures
Reply-To: jinx%hpesogg@sde.hp.com


    I thought this as well (the function is called ``proper-list?'' in Cedar
    Scheme) and almost said so in my response to Morry.  First, however, I
    looked up the definition of lists in R3RS.  In contrast to CLtL, which
    explicitly allows ``list'' to refer both to ``true lists''
    (null-terminated) and ``dotted lists'', R3RS is fairly strict on the point.
    It says,

	``A chain of pairs not ending in the empty list is called
	an IMPROPER LIST.  Note that an improper list is not a list.''

    I thus concluded that ``proper-list?'' was a redundant name and that
    ``list?'' was more appropriate.  I don't feel very strongly about this,
    though.

I feel relatively strongly about it.  At the original r2rs meeting I
suggested calling it list? since I had always felt that the concept of
a "proper list" was funny.  I don't remember whether it made it into
r2rs and was then flushed, or what happened, but I would not like it
to be called proper-list?.

      I'd prefer to avoid generic procedures at the lowest levels of Scheme.
      Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
      LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?

    Assuming that ``apply'' is initially bound to the same value as
    ``list-apply'', I don't object to this proposal.  It will be amusing to see
    if I ever find a use for either of ``vector-apply'' or ``string-apply''.

I don't see a point to STRING-APPLY or VECTOR-APPLY (except to be used
with STRING or VECTOR to copy a string or vector).  I think we should
leave APPLY alone for the following reasons:

- Apply is not really an operation on lists.  It is a hook into the
procedure calling mechanism of the language so that procedures with
arbitrary arity can be called with arbitrary numbers of arguments.
Applying to lists is traditional, although funny in the same way that
arbitrary arity procedures (procedures with dotted lambda lists) build
lists.  

The right way to fix APPLY is not to generalize it along its spurious
direction, but to devise some way by which we can drop user data
structures altogether from this hook into the system, for example, by
designing an alternative based on procedures.

- The kind of manipulation where apply is used is more conveniently
done on lists than on any other data structures.  It is also natural
to think of argument lists as lists, rather than vectors or strings.

I agree that MAP and FOR-EACH should be left alone for the time
being.

∂21-Jul-89  1642	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	last call: changes for R4RS
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  16:41:48 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB08183; Fri, 21 Jul 89 19:28:15 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17889;
          21 Jul 89 12:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 12:24:51 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17868;
          21 Jul 89 12:22 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02981; Fri, 21 Jul 89 12:22:33 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Fri, 21 Jul 89 12:19:18 edt
Received: from fafnir.think.com by Think.COM; Fri, 21 Jul 89 12:20:52 EDT
Received: from verdi.think.com by fafnir.think.com; Fri, 21 Jul 89 12:18:59 EDT
Received: by verdi.think.com; Fri, 21 Jul 89 12:18:56 EDT
Date: Fri, 21 Jul 89 12:18:56 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907211618.AA19787@verdi.think.com>
To: jinx%hpesogg@sde.hp.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Fri, 21 Jul 89 02:58:57 pdt <8907210959.AA09171@sde.hp.com>
Subject: last call: changes for R4RS

   Date: Fri, 21 Jul 89 02:58:57 pdt
   From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
   ...
   Case 2 is the only really surprising case.  This arises from max/sup'ing
   2 and 1.5, for example.  How surprising is it really?  The result is =
   to the largest input, and depending on eqv? of the result is at best
   obscure, so the only surprise would come in output, where the inexact
   value would have a decimal digit and the exact would not.
   Is this really so worrisome to everyone?  It seems to me that the
   people worried about the surprise factor are worrying too much about
   exactly one case, namely what their interactive system will print when
   they call max/sup or min/inf from top level, but that is not very
   interesting, or worth worrying much about.

Well, I think it is worth worrying about.

   PS:

   (define (max/sup a b)
     (/ (+ (+ a b) (abs (- a b)))
	2))

   [Modulo overflow or roundoff]

Actually, I had considered including this very definition in my initial
message as a joke.  But it muddies the issue.  Completely aside from
questions of overflow, I think this is not the model of MAX that most
programmers carry around in their heads.

   Inexact contagion implies that the result should be inexact if either
   input is inexact.

(1) I see no reason why the rules of inexact contagion should
apply to MAX.  As Pavel has observed, >= does not return an
inexact boolean.  (If >= were to be three-valued (yes/no/maybe)
then it would be more consistent.)

(2) The requirement of contagion is particularly onerous in the
case where it results in an implementation producing a range error
when simply returning the exact argument would have been fine.
(N.B. With IEEE 754 floating-point arithmetic there is at least
an explicit representation of infinity.  Maybe non-754 floating-point
should be declared broken and therefore forbidden by the Scheme standard.)

--Guy


∂21-Jul-89  1649	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	ELSE in Scheme 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  16:49:01 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08328; Fri, 21 Jul 89 19:35:44 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17991;
          21 Jul 89 12:37 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 12:37:09 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17966;
          21 Jul 89 12:34 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02730; Fri, 21 Jul 89 12:05:01 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Fri, 21 Jul 89 12:01:51 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA09018; Fri, 21 Jul 89 09:03:59 PDT
Date: Fri, 21 Jul 89 09:03:59 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907211603.AA09018@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 12:05:04 PDT <890720-200757-1264@Xerox>
Subject: ELSE in Scheme

   Date: Thu, 20 Jul 89 12:05:04 PDT
   From: Pavel.pa@xerox.com

   I would rather see ELSE remain in the language.  The old LISP idiom of
   using T as the predicate in the final COND-clause always struck me as a
   hack that sort of ``happens'' to work.  In my mind ELSE is more abstract
   and thus easier to read.  I remember, as a Common Lisp programmer, first
   reading about Scheme and being pleased with ELSE's presence.  I always used
   OTHERWISE at the end of my Common Lisp CASE expressions, too.

	   Pavel

My proposal does not prevent you from using else within CONDs in your programs.
As stated in my original message, all you have to do is put the definition 
(define else #t) in your program.  Furthermore, if you prefer the term
OTHERWISE you could use this instead and include the definition
(define otherwise #t) in your programs.  All I wanted was to remove ELSE from
the list of syntactic keywords so that other people, myself included, can use
the identifier ELSE for other purposes if we so choose.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂21-Jul-89  1854	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	last call: changes for R4RS  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  18:53:57 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09344; Fri, 21 Jul 89 21:39:56 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19581;
          21 Jul 89 14:45 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 14:45:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19451;
          21 Jul 89 14:41 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA04753; Fri, 21 Jul 89 14:41:08 EDT
Received: from localhost by zurich.ai.mit.edu; Fri, 21 Jul 89 14:38:05 edt
Date: Fri, 21 Jul 89 14:38:05 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907211838.AA04787@zurich.ai.mit.edu>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 10:59:23 PDT <890720-105857-125@Xerox>
Subject: last call: changes for R4RS

   Date: Thu, 20 Jul 89 10:59:23 PDT
   From: Pavel.pa@xerox.com

       Noncontroversial changes that will be adopted in the R4RS unless the
       authors object:

       ...

       Section 6.2.
       EQV?-ness is preserved when storing into and fetching from the standard
       data structures (pairs, vectors, strings).  [Note: EQ?-ness isn't
       necessarily preserved.  Preservation of EQV?-ness implies preservation
       of exactness, which is the context in which P1178 requested this
       change.]

   I would be unhappy with any statement that distinguished between the
   behavior of, for example, the car cell of a pair and the contents of a
   lexical variable; EQ?-ness should not be guaranteed for one but not the
   other.  Thus, I support this change only if it is extended to include
   variables.  Pragmatically, the storage for a variable is just as likely to
   be type-specialized as that for a pair or vector.

I agree, though I would go slightly further, if the wording can be
worked out: since we have a definition of the "store" in the report,
can we say that EQV?-ness is preserved when storing and fetching from
these locations?  If worded correctly I think that can capture the
essence of what we need to say here.

∂21-Jul-89  1856	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Bitwise logical operations  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  18:56:48 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB09360; Fri, 21 Jul 89 21:41:14 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19173;
          21 Jul 89 14:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 14:15:00 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19144;
          21 Jul 89 14:10 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04362; Fri, 21 Jul 89 14:10:45 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 14:07:40 edt
Received: from Semillon.ms by ArpaGateway.ms ; 21 JUL 89 10:45:20 PDT
Date: Fri, 21 Jul 89 10:47:14 PDT
From: Pavel.pa@xerox.com
Subject: Re: Bitwise logical operations
In-Reply-To: <8907202301.AA23454@mojave.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890721-104520-3334@Xerox>

I strongly support Jonathan's bitwise logical operations proposal.  I've
missed having these more than once.

	Pavel

∂21-Jul-89  2101	@mc.lcs.mit.edu,@life.ai.mit.edu:jmiller@crl.dec.com 	Regularization of list, vector, and string procedures   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  21:01:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10197; Fri, 21 Jul 89 23:47:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20822;
          21 Jul 89 16:33 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 16:16:16 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20419;
          21 Jul 89 16:10 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05746; Fri, 21 Jul 89 16:09:43 EDT
Received: from decwrl.dec.com ([16.1.0.1]) by zurich.ai.mit.edu; Fri, 21 Jul 89 16:06:27 edt
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	id AA12047; Fri, 21 Jul 89 07:08:04 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	for rrrs-authors@zurich.ai.mit.edu; id AA12047; Fri, 21 Jul 89 07:08:04 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
	id AA13877; Fri, 21 Jul 89 09:38:41 EDT
Date: Fri, 21 Jul 89 09:30:45 EDT
From: jmiller@crl.dec.com
Message-Id: <8907211330.AA00412@peanut.DEC.COM>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: 20-Jul-89 1132 PDT's message of Fri, 21 Jul 89 06:47:31 EDT <8907211047.AA13726@crl.crl.dec.com>
Subject: Regularization of list, vector, and string procedures
Reply-To: JMiller@crl.enet.dec.com

	COMMENTS PRIMARILY TO THE RRRS-AUTHORS LIST

I prefer to remain relatively silent on this mailing list, and send
mail only when it is something I feel strongly about, or is something
that I feel I should handle wearing my IEEE co-editor hat.  (Someone
asked why there wasn't more comment on the content of the list; that's
my justification.)

As co-editor of the IEEE draft standard, I'd like to mention a
discussion that occurred earlier this week among the editors:

For virtually every data type mentioned in a procedure header line in
R4RS there is either an existing predicate in the language (string?
for string, vector? for vector, rational? for q_{n}, etc.) or a
trivial piece of code (like (lambda (k) (and (integer? k) (exact? k)
(positive? k))) for k_{n}).  Not so for (proper) lists referred to as
"list" in the header line.  It was our intention to have P1178 make
this connection explicit, whether or not R4RS chooses to do so, and
the missing predicate for proper lists causes a problem.

We had not planned to ask RNRS to change to add such a test.  But
someone else has, so I'd like to support the addition of the predicate
LIST? that tests for proper lists.  I don't mind if you call it
PROPER-LIST?, but I prefer the other name, especially since the
language of the report is very clear about the definition of a list,
and it excludes both cdr-circularity and dotted tails.  Another
predicate might be of interest to RnRS (NOT-TAIL-CIRCULAR?  or some
such) but you won't hear me agitating to have that added to the IEEE
proposal.

On another point, but still wearing my co-editor hat: I can't agree
with Pavel about keeping R4RS open.  Let's simply take John Ramsdell's
list and agree that the Snowbird issues constitute R4RS (that's what
the meeting was for, anyway) and start NOW on R5RS issues, too: those
in John's Post Snowbird and (I don't like the name) Post R4RS list.
Let's aim for R5RS in about one year or so, and try to keep the
language alive by agreeing on changes and issuing reports frequently.

	COMMENT TO BOTH RRRS-AUTHORS and SCHEME-STANDARD LISTS

Finally, as co-editor, I'd like to poll both mailing lists about one
of the many items that appeared in the GLS/Alan/cph mail about
numbers.  Guy did a wonderful job restating my qualms (expressed at
the last IEEE meeting) about max/min.  His observation explains my
objection to Will's assertion that their omission from the version of
Scheme used in his class last year was a trivial issue.  There are
two, equally reasonable (in my opinion), interpretations of the MAX
and MIN operations.

	(a) They are selectors from a set of numbers and thus there is
            a legitimate expectation that (memq (max <set>) <set>) ==>
            #t.  (Yes, I DO mean memq not memv.)

        (b) MAX and MIN are well-defined mathematical operations on a
            set of numbers and hence the "contagious inexactness" rule
            applies.  In this case, (memv (max <set>) <set>) need not
            be true due to implementation restrictions that make it
            impossible to represent the (inexact) result with
            sufficient accuracy for the result to be = to the (exact)
            element from which it was derived.

Using the former concept, our definition of the Scheme functions would
need to be modified, but the argument in favor of the name change to
SUP/INF is inappropriate.  Using the latter concept, there is an
argument that SUP/INF are superior names for what is actually
happening (based on the observation that SUP and INF of a set may
return limit elements that are not members of the set).

Can I have an informal show of hands?   Please vote:
(1) Keep the names MAX and MIN, and make the semantics be
    selector-like.
(2) Change the names to SUP and INF, and leave the semantics.
(3) Provide all 4 names and both semantics.
(4) Other.
If your answer depends on whether you are voting on a change to
R3.95RS or to P1178, please indicate.

--Jim Miller

P.S. -- In writing the above, I discovered a question I should be able
to answer but can't.  First, notice that (max <set>) under
interpretation (b) (the current one) may signal an error even when all
elements of the set are real numbers -- due to the same implementation
restrictions. Question: are there real numbers that cause errors when
compared using < and so forth?  I can't quite tell from reading
R3.95RS or P1178.  Perhaps it is related to the requirement for
transitivity?

∂21-Jul-89  2104	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Fluid binding   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  21:03:54 PDT
Received: from gang-of-four.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB10203; Fri, 21 Jul 89 23:50:32 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22110;
          21 Jul 89 18:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 18:23:18 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22103;
          21 Jul 89 18:21 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07629; Fri, 21 Jul 89 18:21:07 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 18:18:00 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA22658; Fri, 21 Jul 89 15:20:44 pdt
Message-Id: <8907212220.AA22658@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 13:58:04 pdt
Date: Fri, 21 Jul 89 13:58:04 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: Pavel.pa@xerox.com
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Thu, 20 Jul 89 12:01:25 PDT <890720-200715-1255@Xerox>
Subject: Fluid binding
Reply-To: jinx%hpesogg@sde.hp.com

    Fascinating; your perspective is completely opposite to mine.  You ask,
    ``In the absence of FLUID-LET, what is the difference between your fluids
    and 1-slot records?''  The answer, clearly, is ``nothing''.  But FLUID-LET
    is the whole issue, isn't it?  You perceive my interpretation in terms of a
    fluid environment as ``a lot of hair'', but it seems to me this idea os
    ``temporary/isolated contents'' is considerably hairier.  In particular,
    FLUID-LET in your interpretation is a side-effect that must carefully be
    un-done or re-done whenever control leaves or re-enters the body of the
    form.  This seems very messy to me, conceptually; I shudder to think how it
    would look when added to the formal semantics.  A fluid environment, on the
    other hand, is another instance of a well-understood concept.  It is
    essentially trivial to add it to the formal semantics, and under that
    conception, FLUID-LET is no more a side-effect than LET.

Your argument is like saying that COND is "bad" because it is hard to
implement in the semantics.  I don't care about writing directly in
the semantics when the construct can be provided conveniently by user
code. 

Your model conceptually needs modification of the formal semantics,
while mine can be implemented trivially in a page of code.  Which is
simpler?

I don't believe in cluttering up the semantics when the same
functionality can be provided as efficiently by user code.

∂21-Jul-89  2316	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  23:16:32 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12005; Sat, 22 Jul 89 02:07:57 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21114;
          21 Jul 89 16:57 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 21 Jul 89 16:57:46 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 239123; Fri 21-Jul-89 16:57:26 EDT
Date: Fri, 21 Jul 89 16:57 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907181522.AA29642@verdi.think.com>
Message-Id: <19890721205725.0.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Tue, 18 Jul 89 11:22:03 EDT
    From: gls@Think.COM (Guy Steele)

       If, whenever someone doesn't like the consequences of the exactness rules,
       we introduce a new procedure whose behavior he likes better, giving it the
       old name and giving a new name to the old procedure, then ultimately what
       good is exactness?  In order to reap the benefits of exactness the user has
       to write his program using a bunch of unfamiliar names (unfamiliar to
       computer weenies) like INF and SUP.

    The issue is not reaping the benefits of exactness; it is reaping the
    benefits of inexactness.  Let us not confuse the two.

Well actually, I expect that the tension between the benefits of exactness
and the benefits of inexactness is the root of most disagreements about
(in)exactness.  The benefits of exactness are error checking.  When I write

  (vector-ref v (/ (* n (+ 1 n)) 2))

I know that, independent of the characteristics of arithmetic in my Scheme
implementation, I will be referencing the same element of the vector as
long as VECTOR-REF doesn't signal an error.  If the multiplication
overflows the range of exact integers in some implementation and returns an
inexact, then the division will return an inexact as well, and then
VECTOR-REF will signal an error.  Of course I give up this benefit of
exactness whenever I call a numeric predicate (and the manual takes pains
to warn me about this).  The proposal is to abandon this benefit for MAX
and MIN as well.

(If I was being a real purist trouble maker, I would propose that the
predicates should behave just like VECTOR-REF, and signal an error when
given an inexact argument; then I would propose a parallel family of
"inexact numeric predicates" (PROBABLY-<, PROBABLY-=, PROBABLY-INTEGER?,
PROBABLY-ODD?, etc.) that would compare both exact and inexact numbers.)

The benefits of inexactness are that certain numerical questions can be
answered that would be very difficult to answer otherwise.  (Although it
sometimes takes a numerical analyst to demonstrate that the answer really
is -correct-.)  I don't see that the benefits of inexactness are enhanced
(or degraded) by making MIN and MIX unsafe.

    ..., then let me point out that Scheme weenies are vastly outnumbered
    by C weenies, and every C weenie has the formula

	    #define max(x,y) ((x) > (y)) ? (x) : (y)

    engraved in his little weenie brain.  See?  MAX really is a conditional.

Sure is.  So much of a conditional that it even evaluates the expression
that returns the larger result -twice-!  So I guess to a C weenie, MAX is
more like IF than +.

    [About FLOOR, etc.:]
    ...  if the inexactness is down at the level that you can be sure that
    the integer result is exact (say you know the argument to within .001
    and it is well away from being an integer or half-integer, as the case
    may be), then return an exact result; otherwise return an inexact
    result (but note that the uncertainty of the result may be relatively
    much, much larger than the uncertainty of the input).

Right.  Of course in the usual floating point implementation of inexact
numbers, the precision isn't represented explicitly (it exists only in the
mind of the numerical analyst who wrote the program), so FLOOR can't do
this.  But certainly for other kinds of inexact implementations, such as
intervals or continued fractions, having FLOOR perform this kind of
analysis is perfectly reasonable, and does allow you to sometimes return an
exact result given inexact arguments.

       ...  It seems to me that the assumption that users will be naive is
       the foundation of the art of programming language design....

    IBM has touted ACRITH as a system that, by using high precision and
    interval arithmetic, will save you from all possible ills.  See issues of
    ACM SIGNUM for descriptions of why it actually loses horribly in many
    cases.  I suspect that inexactness as currently treated by Scheme is
    no panacea.

Yeah, every time I mention interval arithmetic as an alternate
implementation for inexact numbers, someone volunteers to educate me about
what a lose intervals can be.  Fortunately, I don't care how bad they can
be.  I'm only interested in them as a "model" of something that obeys the
"axioms" of inexact numbers that -isn't- floating point.

But I don't see what the merits of interval arithmetic has to do with my
position on programmer naivete.  I wasn't proposing interval arithmetic as
something that can help naive programmers.  I was suggesting that
programmers will naively choose a function named "MIN" instead of a
function named "INF" in situations where they don't see that it can
possibly make any difference.  And I claim that in situations where you
don't think it makes any difference, you probably want the function that
properly propogates inexactness.

Quick, without thinking hard, decide whether would you write

 A.  (vector-ref v (min max-index (/ (* n (+ 1 n)) 2)))

or

 B.  (vector-ref v (inf max-index (/ (* n (+ 1 n)) 2))) ?

I'll bet that most people would answer A.  After all, MIN is the familiar
sounding name.  You probably don't think you have to look MIN up in the
manual to remember what it does.  You've always used MIN.  MIN is what you
would have used in any other programming language.  You probably don't even
-remember- INF unless you just happened to look at the manual.

Now suppose you have an implementation with 32-bit integers for exacts and
floating point inexacts.  If MAX-INDEX is 2148565200 (your implementation
supports very big vectors!) and N is 65552, then

  (* n (+ 1 n)) ==> 4297130256

which doesn't fit in 32 bits.  The closest floating point approximation
(assuming a 24-bit mantissa) happens to be 4297130496.0, which is -larger-
than the correct value.  Thus

  (/ (* n (+ 1 n)) 2) ==> 2148565248.0

And so (assuming MIN and INF behave as proposed):

 A.  (min max-index (/ (* n (+ 1 n)) 2)) ==> 2148565200

while

 B.  (inf max-index (/ (* n (+ 1 n)) 2)) ==> <some inexact>

yet the correct exact answer (obtained in an implementation where the * did
not overflow) would be 2148565128.  Thus people who chose A will blindly
access the wrong element of the vector, while people who chose B will have
an error signaled by VECTOR-REF.  People who chose A have a bug in their
code, while people who chose B do not.

    Gee, Alan, this is fun!  Best flame I've had this year.

!

∂21-Jul-89  2322	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Fluid binding
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  23:22:40 PDT
Received: from gang-of-four.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB12020; Sat, 22 Jul 89 02:11:36 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22325;
          21 Jul 89 18:47 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 18:47:20 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22291;
          21 Jul 89 18:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07856; Fri, 21 Jul 89 18:41:56 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 18:38:53 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 89 15:34:16 PDT
Date: Fri, 21 Jul 89 15:33:13 PDT
From: Pavel.pa@xerox.com
Subject: Re: Fluid binding
In-Reply-To: <8907212220.AA22658@sde.hp.com>
To: rrrs-authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890721-153416-4384@Xerox>

    Your argument is like saying that COND is "bad" because it is hard to
    implement in the semantics.  I don't care about writing directly in
    the semantics when the construct can be provided conveniently by user
    code.

COND isn't at all hard to describe in the formal semantics.

    Your model conceptually needs modification of the formal semantics,
    while mine can be implemented trivially in a page of code.  Which is
    simpler?

Huh?  Even your last example, written using dynamic-wind, wasn't entirely
in user code; it relied upon two mysterious primitives whose semantics I'm
still not sure of.  That ain't user code by my definition.  If you can't
write an implementation in R4RS Scheme, without reference to mysterious
primitives with implementation-specific semantics, then I claim it has to
go into the formal semantics.

	Pavel

∂21-Jul-89  2331	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Regularization of list, vector, and string procedures   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Jul 89  23:31:39 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12043; Sat, 22 Jul 89 02:17:13 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25362;
          21 Jul 89 23:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Jul 89 23:23:30 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25308;
          21 Jul 89 23:19 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10079; Fri, 21 Jul 89 23:19:33 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Fri, 21 Jul 89 23:16:27 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA28419; Fri, 21 Jul 89 20:19:07 pdt
Message-Id: <8907220319.AA28419@sde.hp.com>
Received: by hpesogg; Fri, 21 Jul 89 20:11:21 pdt
Date: Fri, 21 Jul 89 20:11:21 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: JMiller@crl.enet.dec.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu,
        Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Fri, 21 Jul 89 09:30:45 EDT <8907211330.AA00412@peanut.DEC.COM>
Subject: Regularization of list, vector, and string procedures
Reply-To: jinx%hpesogg@sde.hp.com

    Using the former concept, our definition of the Scheme functions would
    need to be modified, but the argument in favor of the name change to
    SUP/INF is inappropriate.  Using the latter concept, there is an
    argument that SUP/INF are superior names for what is actually
    happening (based on the observation that SUP and INF of a set may
    return limit elements that are not members of the set).

    Can I have an informal show of hands?   Please vote:
    (1) Keep the names MAX and MIN, and make the semantics be
	selector-like.
    (2) Change the names to SUP and INF, and leave the semantics.
    (3) Provide all 4 names and both semantics.
    (4) Other.
    If your answer depends on whether you are voting on a change to
    R3.95RS or to P1178, please indicate.


I assume that 2 means that only SUP and INF are to be provided, and
that they are not guaranteed to return an eqv? element of the set.

If so, my preferences (in this order) are

2
3
1


    P.S. -- In writing the above, I discovered a question I should be able
    to answer but can't.  First, notice that (max <set>) under
    interpretation (b) (the current one) may signal an error even when all
    elements of the set are real numbers -- due to the same implementation
    restrictions. Question: are there real numbers that cause errors when
    compared using < and so forth?  I can't quite tell from reading
    R3.95RS or P1178.  Perhaps it is related to the requirement for
    transitivity?

It obviously depends on the implementation.  An important thing to
notice (for implementors), however, is that it is not hard to compare
a bignum and a flonum without coercing one to the other.  Thus the
comparison predicates need not error out when either argument can't be
cast to the form of the other, they just have to be clever.

∂23-Jul-89  0001	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #167 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Jul 89  00:01:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA18719; Sun, 23 Jul 89 02:20:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07035;
          23 Jul 89 0:08 EDT
Date: 23 JUL 89  00:06:13 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #167 
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id:  <8907230008.aa07035@mintaka.lcs.mit.edu>

Scheme Digest #167                             23 JUL 89  00:06:13 EDT

Today's Topics:

        Cscheme posting

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

Date: 19 Jul 89 13:54:30 GMT
From: Ross Judson <jarvis.csri.toronto.edu!utgpu!utzoo!dciem!nrcaer!sce!cognos!rossj@rutgers.edu>
Subject: Cscheme posting
Message-Id: <6592@cognos.UUCP>


	As I understand it, Cscheme is a free (I hope!) implementation of
the scheme language.  A month or two ago I read that somebody planned on
posting the most recent version.  Has this been done?  What's the status?
Unfortunately, I am unable to ftp, and, due to mailer screwups, unable to
mail out of this site at all.  So posting is the only way I'll see it.

	Does anybody from Ottawa or the region have it?  I'd like to get in
touch if you do.

-- 
uucp          - uunet!mitel!sce!cognos!rossj   |people hate the generator
arpa/internet - rossj%cognos.uucp@uunet.uu.net |but love to light up the sky

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

End of Scheme Digest
********************

∂24-Jul-89  0904	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89  09:04:45 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29460; Mon, 24 Jul 89 11:54:48 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22178;
          24 Jul 89 11:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 11:45:39 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa22154;
          24 Jul 89 11:44 EDT
Received: from fafnir.think.com by Think.COM; Mon, 24 Jul 89 11:44:57 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 24 Jul 89 11:42:54 EDT
Received: by verdi.think.com; Mon, 24 Jul 89 11:42:50 EDT
Date: Mon, 24 Jul 89 11:42:50 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907241542.AA09125@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Fri, 21 Jul 89 16:57 EDT <19890721205725.0.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers

   Date: Fri, 21 Jul 89 16:57 EDT
   From: Alan Bawden <Alan@reagan.ai.mit.edu>

   Quick, without thinking hard, decide whether would you write

    A.  (vector-ref v (min max-index (/ (* n (+ 1 n)) 2)))

   or

    B.  (vector-ref v (inf max-index (/ (* n (+ 1 n)) 2))) ?

   I'll bet that most people would answer A.  After all, MIN is the familiar
   sounding name.  You probably don't think you have to look MIN up in the
   manual to remember what it does.  You've always used MIN.  MIN is what you
   would have used in any other programming language.  You probably don't even
   -remember- INF unless you just happened to look at the manual.

   Now suppose you have an implementation with 32-bit integers for exacts and
   floating point inexacts.  If MAX-INDEX is 2148565200 (your implementation
   supports very big vectors!) and N is 65552, then

     (* n (+ 1 n)) ==> 4297130256

   which doesn't fit in 32 bits.  The closest floating point approximation
   (assuming a 24-bit mantissa) happens to be 4297130496.0, which is -larger-
   than the correct value.  Thus

     (/ (* n (+ 1 n)) 2) ==> 2148565248.0

   And so (assuming MIN and INF behave as proposed):

    A.  (min max-index (/ (* n (+ 1 n)) 2)) ==> 2148565200

   while

    B.  (inf max-index (/ (* n (+ 1 n)) 2)) ==> <some inexact>

   yet the correct exact answer (obtained in an implementation where the * did
   not overflow) would be 2148565128.  Thus people who chose A will blindly
   access the wrong element of the vector, while people who chose B will have
   an error signaled by VECTOR-REF.  People who chose A have a bug in their
   code, while people who chose B do not.

Depends on why I put the MIN in there.  If I put it in precisely to
guard against indexing off the end of the vector when running in
broken implementations that think 32 bits is enough to count anything
interesting at all, then the program is doing its job, and MIN is
exactly what I wanted.  (Then again, I might have written

(vector-ref v (if (odd? n) (* n (/ (+ 1 n) 2)) (* (/ n 2) (+ 1 n))))

to be really safe.)

--Guy

∂24-Jul-89  0945	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	Regularization of list, vector, and string procedures  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89  09:45:09 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29912; Mon, 24 Jul 89 12:27:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22525;
          24 Jul 89 12:18 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 12:18:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22506;
          24 Jul 89 12:15 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29684; Mon, 24 Jul 89 12:15:28 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Mon, 24 Jul 89 12:11:47 edt
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA29246; Mon, 24 Jul 89 11:33:28 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA22748; Mon, 24 Jul 89 08:29:18 PDT
Date: Mon, 24 Jul 89 08:29:18 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907241529.AA22748@sesame.Stanford.EDU>
To: jinx%hpesogg@sde.hp.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: "Guillermo J. Rozas"'s message of Fri, 21 Jul 89 04:55:30 pdt <8907211156.AA10576@sde.hp.com>
Subject: Regularization of list, vector, and string procedures

   Date: Fri, 21 Jul 89 04:55:30 pdt
   From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
   Reply-To: jinx%hpesogg@sde.hp.com


	 I'd prefer to avoid generic procedures at the lowest levels of Scheme.
	 Why not have LIST-APPLY, VECTOR-APPLY, and STRING-APPLY, by analogy with
	 LIST-LENGTH, VECTOR-LENGTH, and STRING-LENGTH etc?

       Assuming that ``apply'' is initially bound to the same value as
       ``list-apply'', I don't object to this proposal.  It will be amusing to see
       if I ever find a use for either of ``vector-apply'' or ``string-apply''.

   I don't see a point to STRING-APPLY or VECTOR-APPLY (except to be used
   with STRING or VECTOR to copy a string or vector).  I think we should
   leave APPLY alone for the following reasons:

   - Apply is not really an operation on lists.  It is a hook into the
   procedure calling mechanism of the language so that procedures with
   arbitrary arity can be called with arbitrary numbers of arguments.
   Applying to lists is traditional, although funny in the same way that
   arbitrary arity procedures (procedures with dotted lambda lists) build
   lists.  

   The right way to fix APPLY is not to generalize it along its spurious
   direction, but to devise some way by which we can drop user data
   structures altogether from this hook into the system, for example, by
   designing an alternative based on procedures.

This solution would be fine with me.  What is not acceptable from a symmetry
point of view is to leave things unchanged.  Either apply must work using some
new form or there must be versions for each of the reasonable data types.

   - The kind of manipulation where apply is used is more conveniently
   done on lists than on any other data structures.  

Is this claim that it is more convenient from the user's perspective or the
language implementors?  Some evidence of either would be greatly appreciated.

   It is also natural
   to think of argument lists as lists, rather than vectors or strings.

Maybe to some people.  I find this argument far from persuasive.

-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂24-Jul-89  0948	@mc.lcs.mit.edu:mkatz@sesame.stanford.edu 	Regularization of list, vector, and string procedures    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89  09:47:49 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29941; Mon, 24 Jul 89 12:30:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22653;
          24 Jul 89 12:23 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 12:24:00 EDT
Received: from [128.52.32.80] by mintaka.lcs.mit.edu id aa22553;
          24 Jul 89 12:19 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA29736; Mon, 24 Jul 89 12:19:01 EDT
Received: from life.ai.mit.edu (ai.mit.edu) by zurich.ai.mit.edu; Mon, 24 Jul 89 12:15:47 edt
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA29075; Mon, 24 Jul 89 11:25:10 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA22683; Mon, 24 Jul 89 08:18:30 PDT
Date: Mon, 24 Jul 89 08:18:30 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8907241518.AA22683@sesame.Stanford.EDU>
To: JMiller@crl.enet.dec.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu,
        Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Fri, 21 Jul 89 09:30:45 EDT <8907211330.AA00412@peanut.DEC.COM>
Subject: Regularization of list, vector, and string procedures

  Can I have an informal show of hands?   Please vote:

I do not care about the semantics nearly so much as the names.  (Yes, I know
this is a wierd position.)  I feel that the names MAX and MIN should be bound
to functions with some reasonable semantics.  Whether RNRS has SUP and INF in
addition due to nuances in the definitions is not very important to me.  I
would like the niave user who does not care about these nuances to be able to
find the functions he/she needs (i.e., MAX and MIN) with the greatest ease
possible.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂24-Jul-89  1216	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@mrloog.la.tek.com 	Re: Regularization of apply; Show of hands    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89  12:16:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01776; Mon, 24 Jul 89 15:03:07 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24635;
          24 Jul 89 14:52 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 14:45:17 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24476;
          24 Jul 89 14:43 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA01423; Mon, 24 Jul 89 14:43:08 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Mon, 24 Jul 89 14:39:56 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa27237; 24 Jul 89 14:36 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
	id AA07628; Mon, 24 Jul 89 11:38:03 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA08842; Mon, 24 Jul 89 11:32:05 PDT
Received: by mrloog.la.tek.com (1.2/7.1)
	id AA14325; Mon, 24 Jul 89 11:37:00 pdt
Message-Id: <8907241837.AA14325@mrloog.la.tek.com>
To: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
Subject: Re: Regularization of apply; Show of hands
In-Reply-To: Your message of Mon, 24 Jul 89 08:18:30 PDT.
	     <8907241518.AA22683@sesame.Stanford.EDU>
Date: 24 Jul 89 11:36:56 PDT (Mon)
From: kend%mrloog.la.tek.com@relay.cs.net


>   The right way to fix APPLY is not to generalize it along its spurious
>   direction, but to devise some way by which we can drop user data
>   structures altogether from this hook into the system, for example, by
>   designing an alternative based on procedures.

I would prefer that APPLY be applicable only to multiple values.  For
that matter, I favor multiple value rest arguments--dropping rest *lists*
altogether.


> --Jim Miller
>  Can I have an informal show of hands?   Please vote:
>  (1) Keep the names MAX and MIN, and make the semantics be
>      selector-like.
>  (2) Change the names to SUP and INF, and leave the semantics.
>  (3) Provide all 4 names and both semantics.
>  (4) Other.
>  If your answer depends on whether you are voting on a change to
>  R3.95RS or to P1178, please indicate.

For both R3.95RS and P1178, I prefer SUP and INF.  Max and Min should be
defined in the Yellow Pages as macros (when we get macros).  I would not
object to adding definition (as selectors) MAN and MIN to R3.95RS.  MAX
and MIN are obviously too radical for P1178 [and--assuming macros--can be
trivially implemented].

-Ken Dickey		kend@mrloog.LA.TEK.COM

∂24-Jul-89  1255	@mc.lcs.mit.edu,@life.ai.mit.edu:Alan@REAGAN.ai.mit.edu 	Regularization of list, vector, and string procedures
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89  12:55:42 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02213; Mon, 24 Jul 89 15:39:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25075;
          24 Jul 89 15:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 24 Jul 89 15:29:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25065;
          24 Jul 89 15:26 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02076; Mon, 24 Jul 89 15:26:47 EDT
Received: from REAGAN.AI.MIT.EDU (reagan.ai.mit.edu) by zurich.ai.mit.edu; Mon, 24 Jul 89 15:23:25 edt
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 239933; Mon 24-Jul-89 15:26:31 EDT
Date: Mon, 24 Jul 89 15:26 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Regularization of list, vector, and string procedures
To: JMiller@crl.enet.dec.com
Cc: Pavel.pa@xerox.com, rrrs-authors@zurich.ai.mit.edu,
        Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: <8907211330.AA00412@peanut.DEC.COM>
Message-Id: <19890724192626.3.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Fri, 21 Jul 89 09:30:45 EDT
    From: jmiller@crl.dec.com
    ...
    Can I have an informal show of hands?   Please vote:
    (1) Keep the names MAX and MIN, and make the semantics be
	selector-like.
    (2) Change the names to SUP and INF, and leave the semantics.
    (3) Provide all 4 names and both semantics.
    (4) Other.

I vote 4.  There should be no procedures named SUP and INF.  We should
have procedures named MIN and MAX that only return exact numbers given
exact arguments.

I guess that the fact that my opinion didn't even make your list of options
means that I'm not making myself clear.

    If your answer depends on whether you are voting on a change to
    R3.95RS or to P1178, please indicate.

My opinion applies to RnRS only.

∂24-Jul-89  1549	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 24 Jul 89  15:49:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04267; Mon, 24 Jul 89 18:33:54 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26955;
          24 Jul 89 18:31 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 24 Jul 89 18:32:10 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 240033; Mon 24-Jul-89 18:31:20 EDT
Date: Mon, 24 Jul 89 18:31 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907241542.AA09125@verdi.think.com>
Message-Id: <19890724223118.4.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Mon, 24 Jul 89 11:42:50 EDT
    From: Guy Steele <gls@think.com>

       Date: Fri, 21 Jul 89 16:57 EDT
       From: Alan Bawden <Alan@reagan.ai.mit.edu>
       ...
       And so (assuming MIN and INF behave as proposed):

	A.  (min max-index (/ (* n (+ 1 n)) 2)) ==> 2148565200

       while

	B.  (inf max-index (/ (* n (+ 1 n)) 2)) ==> <some inexact>

       yet the correct exact answer (obtained in an implementation where
       the * did not overflow) would be 2148565128.  Thus people who chose
       A will blindly access the wrong element of the vector, while people
       who chose B will have an error signaled by VECTOR-REF.  People who
       chose A have a bug in their code, while people who chose B do not.

    Depends on why I put the MIN in there.  If I put it in precisely to
    guard against indexing off the end of the vector when running in broken
    implementations that think 32 bits is enough to count anything
    interesting at all, then the program is doing its job, and MIN is
    exactly what I wanted....

No matter what gonzo behavior is proposed for MIN, you can -always- defend
the resulting behavior by saying "well, perhaps that's what I wanted".

Well, suppose it wasn't what I wanted.  Suppose I was computing a histogram
of some sort.  I might be pretty puzzled by the fact that bucket 2148565200
had so many entries.  Or perhaps I wouldn't notice at all.  Perhaps I
publish my results, and then someday somebody gets a lethal dose of
radiation as a result.  See?  I can make up stories too.

Out of frustration, I will now change my position.
  
  1.  I now propose that all the numeric predicates should signal an error
  when given any inexact arguments.  I propose a parallel family of numeric
  predicates with names like "%=" and "%ODD?" that behave unsafely, as the
  current numeric predicates do.
  
  2.  I propose that numeric functions, such as LOG and /, that can signal
  errors at certain points in the domain of one of their arguments, -must-
  signal an error if that argument is inexact.  I propose to add a parallel
  family of numeric functions with names like "%LOG" and "%/" that behave
  unsafely, as the current numeric functions do.  (For uniformity, we might
  have both + and %+, even thought they behave identically.)
  
  3.  I propose to change the names of EXACT? and INEXACT? to be "%EXACT?"
  and "%INEXACT?".
  
  4.  Finally, I propose we add %MIN and %MAX to compute the unsafe minimum
  and maximum that seems so popular.

With these changes in place, Scheme would have the following property:

  A program that does not contain a "%", will compute the same exact
  numeric result in all Scheme implementations in which it doesn't signal
  an error or return an inexact result.

(My proposal is actually stronger than necessary to insure this property.
In an implementations that use representations other than floating point
for inexacts, it may be possible to reliably answer questions such as 
(< X Y) reliably, so an error need not be signaled in that case.  I could
have simply proposed that implementations can do whatever they want, as
long as they don't violate that property.)   

I realize that nobody will take me seriously on this.  But nobody was
taking me seriously anyway.

∂25-Jul-89  1259	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89  12:58:07 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16380; Tue, 25 Jul 89 15:41:12 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa11442;
          25 Jul 89 15:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 15:27:19 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa11396;
          25 Jul 89 15:21 EDT
Received: from fafnir.think.com by Think.COM; Tue, 25 Jul 89 15:21:40 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 25 Jul 89 15:19:30 EDT
Received: by verdi.think.com; Tue, 25 Jul 89 14:23:01 EDT
Date: Tue, 25 Jul 89 14:23:01 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907251823.AA27924@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Mon, 24 Jul 89 18:31 EDT <19890724223118.4.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers

   Date: Mon, 24 Jul 89 18:31 EDT
   From: Alan Bawden <Alan@reagan.ai.mit.edu>

       Date: Mon, 24 Jul 89 11:42:50 EDT
       From: Guy Steele <gls@think.com>

	  Date: Fri, 21 Jul 89 16:57 EDT
	  From: Alan Bawden <Alan@reagan.ai.mit.edu>
	  ...
	  And so (assuming MIN and INF behave as proposed):

	   A.  (min max-index (/ (* n (+ 1 n)) 2)) ==> 2148565200

	  while

	   B.  (inf max-index (/ (* n (+ 1 n)) 2)) ==> <some inexact>

	  yet the correct exact answer (obtained in an implementation where
	  the * did not overflow) would be 2148565128.  Thus people who chose
	  A will blindly access the wrong element of the vector, while people
	  who chose B will have an error signaled by VECTOR-REF.  People who
	  chose A have a bug in their code, while people who chose B do not.

       Depends on why I put the MIN in there.  If I put it in precisely to
       guard against indexing off the end of the vector when running in broken
       implementations that think 32 bits is enough to count anything
       interesting at all, then the program is doing its job, and MIN is
       exactly what I wanted....

   No matter what gonzo behavior is proposed for MIN, you can -always- defend
   the resulting behavior by saying "well, perhaps that's what I wanted".

No matter for what sensible reason I wrote "MIN" in my code instead
of "INF", you can -always- attack my claim that this example supports a
general rationale by saying, "No matter what gonzo behavior...."

:-)  :-)  :-)  :-)  :-)  :-)  :-)  :-)  :-)  :-)  :-)  :-)  :-)  :-)  :-)

   Well, suppose it wasn't what I wanted.  Suppose I was computing a histogram
   of some sort.  I might be pretty puzzled by the fact that bucket 2148565200
   had so many entries.  Or perhaps I wouldn't notice at all.  Perhaps I
   publish my results, and then someday somebody gets a lethal dose of
   radiation as a result.  See?  I can make up stories too.

Well, if I were to examine the code and spot -either- a MIN or INF
that clipped the bucket number to 2148565200, I think I would be
led to reason about that code a little more closely...

--Guy

P.S.  This is fun.

∂25-Jul-89  1454	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Regularization of apply; Show of hands   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89  14:54:03 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA17769; Tue, 25 Jul 89 17:33:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13066;
          25 Jul 89 17:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 17:23:24 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa12984;
          25 Jul 89 17:20 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA17539; Tue, 25 Jul 89 17:20:23 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Tue, 25 Jul 89 17:17:06 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA05849; Tue, 25 Jul 89 14:20:02 pdt
Message-Id: <8907252120.AA05849@sde.hp.com>
Received: by hpesogg; Tue, 25 Jul 89 14:19:10 pdt
Date: Tue, 25 Jul 89 14:19:10 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: kend%mrloog.la.tek.com@relay.cs.net
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: kend%mrloog.la.tek.com@relay.cs.net's message of 24 Jul 89 11:36:56 PDT (Mon) <8907241837.AA14325@mrloog.la.tek.com>
Subject: Regularization of apply; Show of hands
Reply-To: jinx%hpesogg@sde.hp.com

   Date: 24 Jul 89 11:36:56 PDT (Mon)
   From: kend%mrloog.la.tek.com@relay.cs.net


   >   The right way to fix APPLY is not to generalize it along its spurious
   >   direction, but to devise some way by which we can drop user data
   >   structures altogether from this hook into the system, for example, by
   >   designing an alternative based on procedures.

   I would prefer that APPLY be applicable only to multiple values.  For
   that matter, I favor multiple value rest arguments--dropping rest *lists*
   altogether.

What do you mean by multiple values?  
Do you mean something like LAMBDA*'s & pseudo-objects?  
If you mean something along the more traditional lines, you have just
pushed the problem one level deeper, since your multiple value
receivers are also expressed in lambda notation and therefore you need
to have dotted lists.

∂25-Jul-89  1524	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	Regularization of apply; Show of hands    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89  15:24:09 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA18275; Tue, 25 Jul 89 18:09:33 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa13466;
          25 Jul 89 17:56 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 17:56:25 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa13445;
          25 Jul 89 17:52 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA18030; Tue, 25 Jul 89 17:52:06 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Tue, 25 Jul 89 17:48:51 edt
Received: from fafnir.think.com by Think.COM; Tue, 25 Jul 89 17:45:04 EDT
Received: from verdi.think.com by fafnir.think.com; Tue, 25 Jul 89 17:42:58 EDT
Received: by verdi.think.com; Tue, 25 Jul 89 17:42:53 EDT
Date: Tue, 25 Jul 89 17:42:53 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907252142.AA04994@verdi.think.com>
To: jinx%hpesogg@sde.hp.com
Cc: kend%mrloog.la.tek.com@relay.cs.net, rrrs-authors@zurich.ai.mit.edu,
        Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Tue, 25 Jul 89 14:19:10 pdt <8907252120.AA05849@sde.hp.com>
Subject: Regularization of apply; Show of hands

   Date: Tue, 25 Jul 89 14:19:10 pdt
   From: Guillermo J. Rozas <jinx@hpesogg.hp.com>

      Date: 24 Jul 89 11:36:56 PDT (Mon)
      From: kend%mrloog.la.tek.com@relay.cs.net


      >   The right way to fix APPLY is not to generalize it along its spurious
      >   direction, but to devise some way by which we can drop user data
      >   structures altogether from this hook into the system, for example, by
      >   designing an alternative based on procedures.

      I would prefer that APPLY be applicable only to multiple values.  For
      that matter, I favor multiple value rest arguments--dropping rest *lists*
      altogether.

   What do you mean by multiple values?  
   Do you mean something like LAMBDA*'s & pseudo-objects?  
   If you mean something along the more traditional lines, you have just
   pushed the problem one level deeper, since your multiple value
   receivers are also expressed in lambda notation and therefore you need
   to have dotted lists.

This strikes me as almost certainly a reference to the "rest values"
described by Dybvig and Hieb in Proc. 1988 ACM Conf. Lisp and Functional
Programming.  Note that while that paper speaks of rest variables,
it does not state in so many words that the collection of values
associated with such a variables constitutes any sort of object,
pseudo- or otherwise.

By the way, I think that this idea in lambda* has much to recommend it.
(Then again, the ever-mythical "sufficiently smart compiler" ought to
be able to use data flow analysis to eliminate many, though not all,
uses of rest-lists...)
--Guy



∂25-Jul-89  1909	@mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com 	INF/SUP/MIN/MAX, LIST?/PROPER-LIST?, APPLY    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89  19:08:48 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA20223; Tue, 25 Jul 89 21:39:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15563;
          25 Jul 89 21:08 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 20:55:21 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa14514;
          25 Jul 89 19:36 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19155; Tue, 25 Jul 89 19:36:01 EDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (stony-brook.scrc.symbolics.com) by zurich.ai.mit.edu; Tue, 25 Jul 89 19:32:47 edt
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 631474; 25 Jul 89 19:06:48 EDT
Date: Tue, 25 Jul 89 19:06 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: INF/SUP/MIN/MAX, LIST?/PROPER-LIST?, APPLY
To: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <8907211330.AA00412@peanut.DEC.COM>
Message-Id: <19890725230639.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

As most of you know, I don't use Scheme regularly. But I have in the
past and might again, and I do care about it. I offer my advice as that
of an informed observer and potential future user...

 - I have advocated a PROPER-LIST? function in T ever since
   its creation. It was there for a while, and perhaps later
   removed. I have no idea what its current state is. I
   definitely feel strongly that writing a circularity-checker
   is easy to do but not everyone knows how to do it.   It's
   easy to interleave circularity checking with the atom/null
   check that PROPER-LIST? will do, to give a nice overall effect.
   I strongly favor the introduction of PROPER-LIST?

   If the name LIST? were introduced, I feel quite strongly
   that it should parallel what LISTP does in Lisp because there
   are too many people who've gone back and forth and it was
   just too confusing going from Maclisp's LISTP to CL's LISTP
   without having that incompatibility hassle introduced all over
   again.  I think that for people who go to care to construct
   only proper lists, CL's LISTP is the right cross between 
   efficiency and reliability.

   If everyone will not agree to put LIST? in as a synonym for
   (LAMBDA (X) (OR (NULL? X) (PAIR? X))), then everyone should
   agree to leave it out and go for PROPER-LIST? (on which I think
   we can agree about the definition) so that implementations that
   want to put LIST? in compatibly can do so.

   As a -complete- aside, I would be quite happy to also see a
   library function which would be described in CL notation by
     CIRCULAR? list &KEY (path #'CDR) (end-test #'NULL?)
   [and which you could set up argument-wise however you liked
   in Scheme], but I don't expect there to be a enough support
   for that to bother pursuing it at this late date.

 - With regard to MAX/MIN and INF/SUP, let me just say that there
   are two approaches to designing a language: you can figure out
   what you can understand/implement and then provide that, or you
   can figure out what users want/need and try to figure a way to
   provide that.

   If users were crying out for INF/SUP, then I think you should
   consider providing it, but I've never heard anyone ask for it.
   I have heard them ask for MAX/MIN and just plain think they
   should be provided.  The importance of returning an EQV? value
   is that I may be doing selection from a list of items, and I may
   be planning to later try to use MEMBER? or ASSOC? some such to
   later find the element again in the list.  If MAX/MIN `destroys'
   the identity of the argument and gives me back something which
   isn't really the same, then my algorithms may fail.  I'm big on
   object identity and <<uh, what's the opposite-- little??>> on 
   things that casually disregard it.

   In my opinion, the whole INF/SUP debate comes down to a haughty
   disregard on the part of some designers for a clearly expressed
   need on the part of users.  I've not been convinced by any discussion
   I've seen that the MAX/MIN users are calling for is impossible to
   provide. What it sounds like to me is that the implementors are
   busy building a wall that is going to impede entry into the Scheme
   community because potential users are going to have to be even
   more mathematically anal than they already have to be in order to
   feel comfortable with what's provided. When people talk about max
   in English, they say "give me the maximum of" not "a maximum of".
   I think most "normal people" (like my mom or J. random programmer
   who hasn't got a doctorate in advanced degree in math) expect a
   uniquely determined result which is IN the initial set.   
   I think we should offer that. If we offer something else, that's fine.
   But don't do it on MAX. And don't be so stubborn that you can't provide
   the MAX that 99.9% of your users are clearly asking for.

   Note: I personally wouldn't mind if MAX -failed- (reliably signalled 
   an error or however you scheme guys say that) in the case where there was
   a potential problem due to exactness. I wouldn't mind if it was required
   that all arguments be exact or that all be inexact. I only care that if
   I do get back a result, it's described by the rules that I intuitively use.
   But I suspect others would find this too tedious, and anyway, it's 
   inconsistent with the idea that <, etc. can compare exact and inexact numbers.
   After all, there's a fundamental problem underlying all inexact comparisons 
   that depending on -how- inexact two numbers are, the one which -appears- less
   may not really be. Once you've opened that door, it's not clear where to
   start drawing the line.  So given all that, I think the right thing is just
   to assume every number is correct locally within the operation, and then
   to just return the `biggest' number with its original exactness and leave
   it at that.

 - I think APPLY should be left alone. It should do the job needed in order
   to describe how to apply functions in forms. Since lists are all that's
   needed to express forms, I think they're all that's needed in order to
   describe applcication.

   APPLY definitely should not be extended to vecotrs unless you make
   it so that vectors are valid forms for evaluation (i guess with the
   operator in slot 0 and the args in successive slots), but i don't
   see any point to that either. It just reduces error checking.

   I don't think extending apply to deal with multiple values is a good
   idea for pretty much the same reason. Also because I think the idea
   of turning APPLY (currently a normal function) into something that
   could grok multiple values is a good change.  If you want a new special
   form (or keyword, i guess you call them), call it something other than
   APPLY so as not to confuse the whole universe.  If you call it something
   else, I don't mind having it around--but then I don't think it should
   bother hacking lists... and I'd still keep APPLY, both for historical
   reasons and because it's useful even now.

   Do not undervalue the importance of leaving holes in your syntactic
   space.  The more things you make "defined", the less robust your 
   language becomes because everything means something.  The problem is
   that the only chance you have to catch a programmer babbling is when
   he says something so obviously wrong that you can flag it without
   knowing the context.  Unless you have a compelling reason to make 
   things that are currently "obviously wrong" into "meaningful", then 
   you should think twice about giving up your freedom to recognize
   problems.  This is -especially- true in a language like Scheme which
   has such an underdeveloped notion of error handling and where users can
   (at least, if the spec is all they have to go on) really rely on nothing
   much to catch them if they venture beyond the clearly specified range
   of what they're -supposed to- have done.

I hope these comments are of help in resolving the latest flurry of
conflicts.

By the way, one thing the CL community has done well which the Scheme community
has done poorly, is to document in a modular fashion all the design rationales
for ongoing changes to the language so that they aren't doomed to repeat the
same arguments over and over again.  It would be nice if the Scheme community
started to move toward a similar bookkeeping strategy.  Many of these arguments
hit me with a real sense of deja vu which it seems to me could have been
avoided.

∂25-Jul-89  1915	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Regularization of apply (long) 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89  19:15:23 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA20399; Tue, 25 Jul 89 22:02:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa15872;
          25 Jul 89 21:24 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 25 Jul 89 20:56:38 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa14805;
          25 Jul 89 20:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19331; Tue, 25 Jul 89 20:03:31 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Tue, 25 Jul 89 20:00:16 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA10241; Tue, 25 Jul 89 17:02:58 pdt
Message-Id: <8907260002.AA10241@sde.hp.com>
Received: by hpesogg; Tue, 25 Jul 89 17:02:14 pdt
Date: Tue, 25 Jul 89 17:02:14 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: gls@think.com
Cc: kend%mrloog.la.tek.com@relay.cs.net, rrrs-authors@zurich.ai.mit.edu,
        Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: Guy Steele's message of Tue, 25 Jul 89 17:42:53 EDT <8907252142.AA04994@verdi.think.com>
Subject: Regularization of apply (long)
Reply-To: jinx%hpesogg@sde.hp.com

       What do you mean by multiple values?  
       Do you mean something like LAMBDA*'s & pseudo-objects?  
       If you mean something along the more traditional lines, you have just
       pushed the problem one level deeper, since your multiple value
       receivers are also expressed in lambda notation and therefore you need
       to have dotted lists.

    This strikes me as almost certainly a reference to the "rest values"
    described by Dybvig and Hieb in Proc. 1988 ACM Conf. Lisp and Functional
    Programming.  Note that while that paper speaks of rest variables,
    it does not state in so many words that the collection of values
    associated with such a variables constitutes any sort of object,
    pseudo- or otherwise.

kend's comment may well have been a reference to Dybvig and Hieb's
"rest values", which is precisely what I was asking.

Although I agree that there are interesting issues in lambda*, I think
that lambda* mixes up too many concepts and imposes implementation
restrictions that I'm not sure I like.

I envision something more primitive, and completely different.  I
think that using lists, vectors, or special values to collect and pass
arbitrary numbers of arguments is spurious.  Specific data structures
should be introduced by the user according to convenience or intent.
The arbitrary arity mechanism in the language should not be based on
arbitrary data aggragates at all, but on something more primitive, and
procedures (I think) are a good choice.

As a "proof of concept" I will present an example, which in no way
should be taken as a proposal for RnRs, but merely as a hint of what I
would like to see.

Consider the two "primitives" SUPPLY-ARGUMENTS and
MAKE-ARGUMENTS-COLLECTOR.  Sample implementations are provided below
in terms of APPLY and "dot notation".

SUPPLY-ARGUMENTS is analogous to APPLY.  It is a mechanism for
suppliying arguments to a procedure without knowing at programming
time exactly how many arguments are being supplied.  SUPPLY-ARGUMENTS
coroutines with the argument supplier, which provides one argument at
a time.  SUPPLY-ARGUMENTS calls all of them, and eventually invokes
the procedure on all the arguments collected.

MAKE-ARGUMENTS-COLLECTOR is analogous in intent to "dot notation".  It
is a mechanism for constructing a procedure that accepts any number of
arguments.  The essential idea is that collecting any number of arguments
is a reduction process with a null-value (the terminator) and a "combiner"
which combines the current argument with the combination of the remaining
arguments.  There is also a "wrapper" which allows some further processing
after all the arguments have been processed.

These "primitives" are somewhat clumsy and I have not thought about
their native implementation carefully, but are a relatively good way
to describe procedures of arbitrary arity without reference to
individual data structures.

Sample implementation in terms of apply and "dot notation":

;;; New "primitives"

(define (supply-arguments procedure supplier)
  (define (collect-loop l supplier)
    (supplier
     (lambda (next new-supplier)
       (collect-loop (cons next l)
		     new-supplier))
     (lambda ()
       (APPLY procedure (reverse l)))))

  (collect-loop '() supplier))

(define (make-arguments-collector wrapper combiner terminator)
  (lambda ARG-LIST
    (define (process l)
      (if (null? l)
	  (terminator)
	  (combiner (car l)
		    (process (cdr l)))))
    (wrapper (process ARG-LIST))))

Examples of their use:

;; This is the traditional 2-argument apply.

(define (invoke-on-list procedure l)
  (define (supply l collect-next end)
    (if (null? l)
	(end)
	(collect-next (car l)
		      (lambda (next-collector next-end)
			(supply (cdr l) next-collector next-end)))))

  (supply-arguments
   procedure
   (lambda (collect end)
     (supply l collect end))))
		    
(define (invoke-on-vector procedure v)
  (define (supply i collect-next end)
    (if (>= i (vector-length v))
	(end)
	(collect-next (vector-ref v i)
		      (lambda (next-collector next-end)
			(supply (1+ i) next-collector next-end)))))
  (supply-arguments
   procedure
   (lambda (collect end)
     (supply 0 collect end))))

(define nary-+
  (make-arguments-collector (lambda (x) x)
			    +
			    (lambda () 0)))

(define count-args
  (make-arguments-collector (lambda (x) x)
			    (lambda (x rest)
			      (1+ rest))
			    (lambda () 0)))

(define list
  (make-arguments-collector (lambda (x) x)
			    cons
			    (lambda () '())))

(define vector
  (make-arguments-collector list->vector
			    cons
			    (lambda () '())))

(define cons*
  (let ((tag (cons 'cons*-tag '())))
    (make-arguments-collector
     (lambda (result)
       (if (eq? result tag)
	   (error "cons*: No arguments supplied")
	   result))
     (lambda (new tail)
       (if (eq? tail tag)
	   new
	   (cons new tail)))
     (lambda () tag))))

;; This is the full-fledged apply.

(define apply
  (make-arguments-collector
   (lambda (result)
     (case (car result)
       ((none-provided)
	(error "apply: No arguments supplied"))
       ((one-provided)
	((cdr result)))
       (else
	(invoke-on-list (cadr result)
			(cddr result)))))
   (lambda (new tail)
     (case (car tail)
       ((none-provided)
	(cons 'one-provided new))
       (else
	(cons 'normal
	      (cons new (cdr tail))))))
   (lambda ()
     (cons 'none-provided '()))))

∂25-Jul-89  2003	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 25 Jul 89  20:03:33 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA20760; Tue, 25 Jul 89 22:53:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16904;
          25 Jul 89 22:41 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 25 Jul 89 22:42:08 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 240964; Tue 25-Jul-89 22:41:20 EDT
Date: Tue, 25 Jul 89 22:41 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907251823.AA27924@verdi.think.com>
Message-Id: <19890726024117.0.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Tue, 25 Jul 89 14:23:01 EDT
    From: gls@Think.COM (Guy Steele)
    ...
    Well, if I were to examine the code and spot -either- a MIN or INF
    that clipped the bucket number to 2148565200, I think I would be
    led to reason about that code a little more closely...

But INF will -never- clip to the wrong bucket!  That's the whole point of
the example!  INF doesn't shaft you by returning an exact number when it
doesn't know the answer exactly, it return an inexact number, and then
VECTOR-REF signals an error.  With INF, you learn of a limitation in the
arithmetic of your Scheme implementation (so that perhaps you can rewrite
your code in the clever way you suggested the other day).  With MIN, your
program just references the wrong element of the vector.

(No need to point out that I have again returned to assuming that
2148565200 is the "wrong" bucket.  Again, if what MIN does just happens to
do what you really wanted, whatever that may be, then of course you will
have no cause to complain about its behavior.  But assuming that you put
that call to MIN/INF in there because you thought you were computing a
histogram, and you wanted to count all the huge values in the -last-
bucket, then 2148565200 is an error.)

∂26-Jul-89  0359	@mc.lcs.mit.edu,@life.ai.mit.edu:Alan@reagan.ai.mit.edu 	INF/SUP/MIN/MAX   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89  03:59:19 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AB24395; Wed, 26 Jul 89 06:48:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20216;
          26 Jul 89 3:43 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 03:43:29 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20187;
          26 Jul 89 3:37 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA23380; Wed, 26 Jul 89 03:37:29 EDT
Received: from REAGAN.AI.MIT.EDU (reagan.ai.mit.edu) by zurich.ai.mit.edu; Wed, 26 Jul 89 03:34:15 edt
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 240992; Wed 26-Jul-89 01:15:19 EDT
Date: Wed, 26 Jul 89 01:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: INF/SUP/MIN/MAX
To: KMP@stony-brook.scrc.symbolics.com
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <19890725230639.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Tue, 25 Jul 89 19:06 EDT
    From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
    ...
    If users were crying out for INF/SUP, then I think you should consider
    providing it, but I've never heard anyone ask for it.

    I have heard them ask for MAX/MIN and just plain think they should be
    provided.

I've never heard users asking for the notion of exactness/inexactness at
all.  Ask them what they want, and they will probably tell you that they
want IEEE floating point.  As I have said before, I think it would be 100%
reasonable for Scheme to do what every other language does, and adopt some
reasonable set of rules for the behavior of floating point.  Unfortunately,
Scheme decided to go in a different direction.  Inexact numbers are not
just another name for floating point, so we have -already- decided to give
users something other than what they would ask for.  What we are arguing
about here, are the -consequences- of that decision for the function MIN.
I was under the impression that the consistency of the language mattered,
not just what the users think they want before you have a chance to explain
the issues to them.

	       The importance of returning an EQV? value is that I may be
    doing selection from a list of items, and I may be planning to later
    try to use MEMBER? or ASSOC? some such to later find the element again
    in the list.  If MAX/MIN `destroys' the identity of the argument and
    gives me back something which isn't really the same, then my algorithms
    may fail.  I'm big on object identity and <<uh, what's the opposite--
    little??>> on things that casually disregard it.

I'd be interested in seeing examples of code that depends on the identity
of the value returned by MAX or MIN.  I just checked through all of my
Scheme code, and I didn't find any instances in which it mattered.
Typically I found that the result was fed into a function like +, - or *.
Once the result was passed as the first argument to MAKE-STRING.  In the
case of MAKE-STRING, having MAX return an inexact number when any argument
was inexact provides the kind of error checking I've been flaming to Steele
about.  I'm a fan of object identity too, but not at the expense of
returning a incorrect result.

    In my opinion, the whole INF/SUP debate comes down to a haughty
    disregard on the part of some designers for a clearly expressed need on
    the part of users.

I don't see anybody else here defending this point of view, so it must be
me who is being "haughty".  Below, I apparently become "anal" and
"stubborn".  I must say, it's more fun arguing with Steele.

			I've not been convinced by any discussion I've seen
    that the MAX/MIN users are calling for is impossible to provide. What
    it sounds like to me is that the implementors are busy building a wall
    that is going to impede entry into the Scheme community because
    potential users are going to have to be even more mathematically anal
    than they already have to be in order to feel comfortable with what's
    provided. When people talk about max in English, they say "give me the
    maximum of" not "a maximum of".  I think most "normal people" (like my
    mom or J. random programmer who hasn't got a doctorate in advanced
    degree in math) expect a uniquely determined result which is IN the
    initial set.  I think we should offer that. If we offer something
    else, that's fine.  But don't do it on MAX. And don't be so stubborn
    that you can't provide the MAX that 99.9% of your users are clearly
    asking for.

Most "normal people" expect the distributive law to be true too, but with
inexact numbers, it won't necessarily be.  In English we can certainly say
that + returns "the sum" of two numbers, but once inexact numbers are
involved any given Scheme implementation can only claim to compute a
representation of that sum.

  (+ 1.0 1e20)  ==>  1.0

Having added something non-zero to an inexact 1, should I be concerned that
the result is EQV? to the argument?  My mom would probably complain that
the answer should be -different-, yet here Scheme might even return
something that is EQ?.  Suppose I was planning on feeding this result to
MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?

Inexact numbers simply do not behave like numbers.  Abstractly MAX computes
the maximum of a set of numbers just as much as + computes the sum, but
unfortunately we can only represent numbers imperfectly in our computers

∂26-Jul-89  0408	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #169 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89  04:08:41 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA24385; Wed, 26 Jul 89 06:42:22 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17897;
          26 Jul 89 0:07 EDT
Date: 26 JUL 89  00:07:12 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #169 
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id:  <8907260007.aa17897@mintaka.lcs.mit.edu>

Scheme Digest #169                             26 JUL 89  00:07:12 EDT

Today's Topics:

        equal? Bug in PC Scheme

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

Date: 25 Jul 89 19:10 GMT+0100
From: Guenther Goerz <goerz@rz.informatik.uni-hamburg.dbp.de>
Message-ID: <44:goerz@rz.informatik.uni-hamburg.dbp.de>
Subject: equal? Bug in PC Scheme

There seems to be a bug in PC Scheme's (ver. 3.03) EQUAL?: If you ask
whether the empty vector equals the empty vector, it says false.
 
 (equal? #() #())  =>  ()
 
Vector is the only datatype where this happens.
 
---Guenther

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

End of Scheme Digest
********************

∂26-Jul-89  0617	ramsdell@linus.mitre.org 	INF/SUP/MIN/MAX    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89  06:17:26 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA25417; Wed, 26 Jul 89 08:59:55 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA27863; Wed, 26 Jul 89 08:55:02 EDT
Posted-Date: Wed, 26 Jul 89 08:54:59 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA01126; Wed, 26 Jul 89 08:55:00 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8907261255.AA01126@huxley.mitre.org>
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@life.ai.mit.edu
Subject: INF/SUP/MIN/MAX
In-Reply-To: Your message of Fri, 21 Jul 89 09:30:45 -0400.
             <8907211330.AA00412@peanut.DEC.COM> 
Date: Wed, 26 Jul 89 08:54:59 EDT

I vote for excluding procedures named INF and SUP, and including 
procedures named MIN and MAX having the semantics as documented in
R3.95RS.  I encourage the editors to add a note describing the
"suprizing" behavior of MIN and MAX.
John

∂26-Jul-89  0745	wand@corwin.ccs.northeastern.edu 	INF/SUP/MIN/MAX 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89  07:45:46 PDT
Received: from helios.northeastern.edu by life.ai.mit.edu (4.1/AI-4.10) id AA26157; Wed, 26 Jul 89 10:33:25 EDT
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
          id aa01420; 26 Jul 89 15:30 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.6)
	id AA00386; Wed, 26 Jul 89 10:00:19 ADT
Date: Wed, 26 Jul 89 10:00:19 ADT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Message-Id: <8907261300.AA00386@corwin.CCS.Northeastern.EDU>
To: ramsdell@linus.mitre.org
Cc: JMiller@crl.enet.dec.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Wed, 26 Jul 89 08:54:59 EDT <8907261255.AA01126@huxley.mitre.org>
Subject: INF/SUP/MIN/MAX

   Posted-From: The MITRE Corp., Bedford, MA
   X-Alternate-Route: user%node@mbunix.mitre.org
   Posted-Date: Wed, 26 Jul 89 08:54:59 EDT
   From: ramsdell@linus.mitre.org
   To: JMiller@crl.enet.dec.com
   Cc: rrrs-authors@life.ai.mit.edu
   Subject: INF/SUP/MIN/MAX
   Date: Wed, 26 Jul 89 08:54:59 EDT

   I vote for excluding procedures named INF and SUP, and including 
   procedures named MIN and MAX having the semantics as documented in
   R3.95RS.  I encourage the editors to add a note describing the
   "suprizing" behavior of MIN and MAX.
   John

This is my vote, also.  As Alan Bawden said, "inexact numbers just don't
behave like numbers", so all we can do is make the language as consistent as
possible.  I don't see that changing the names will help very much, except to
make the language harder to use.

--Mitch

∂26-Jul-89  1103	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	INF/SUP/MIN/MAX  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89  11:01:41 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28157; Wed, 26 Jul 89 13:41:27 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24940;
          26 Jul 89 13:14 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 13:07:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24717;
          26 Jul 89 13:00 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27708; Wed, 26 Jul 89 13:00:19 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Wed, 26 Jul 89 12:56:55 edt
Received: from fafnir.think.com by Think.COM; Wed, 26 Jul 89 13:00:30 EDT
Received: from verdi.think.com by fafnir.think.com; Wed, 26 Jul 89 12:58:19 EDT
Received: by verdi.think.com; Wed, 26 Jul 89 12:58:15 EDT
Date: Wed, 26 Jul 89 12:58:15 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907261658.AA07734@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Alan Bawden's message of Wed, 26 Jul 89 01:15 EDT <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Subject: INF/SUP/MIN/MAX

   Date: Wed, 26 Jul 89 01:15 EDT
   From: Alan Bawden <Alan@reagan.ai.mit.edu>

		... I must say, it's more fun arguing with Steele.

Thank you.  I guess.

   Most "normal people" expect the distributive law to be true too, but with
   inexact numbers, it won't necessarily be.  In English we can certainly say
   that + returns "the sum" of two numbers, but once inexact numbers are
   involved any given Scheme implementation can only claim to compute a
   representation of that sum.

     (+ 1.0 1e20)  ==>  1.0

   Having added something non-zero to an inexact 1, should I be concerned that
   the result is EQV? to the argument?  My mom would probably complain that
   the answer should be -different-, yet here Scheme might even return
   something that is EQ?.

Hm.  My mom might complain about this one too.  Maybe you meant "1e-20"?
Or else you got ripped off if you paid more than $2 for that implementation.

			   Suppose I was planning on feeding this result to
   MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?

No, it isn't, Alan, and here's why.  Your example takes what we might expect
to be two things and makes them one.  This happens all the time in real life.
The morning star turns out to be the evening star also.  Your mom turns out to
be the one who makes those yummy chocolate-chip cookies that are sold
nation-wide.  Your car turns out to be eqv? to your cdr.  You have two pennies
and put one on the railroad track, and the other one gets squished.  [This
last example does not outrage intuition if pointers are used: "Last week I
heard that Weinreb had acquired a rare 1903 Quux-head penny.  Yesterday at the
party Steele was showing off a penny just like it, and he put it on the
railroad track and it got squished.  Today I asked Weinreb if I could see his
penny, and he sadly showed me that it had been squished."  This story rendered
into Scheme is:
	(penny? Weinreb) => #t
	(set! Steele (+ Weinreb 1e-20))
	(penny? Steele) => #t
	(squish Steele)
	(squished? Weinreb) => #t
]  You thought + would give you a different number, but because of
machine limitations it gave you the same one back.

It is a much more egregious error to take what you thought you knew to be
one object and make it two.  You thought there was only one Venus, but it
turns out that in August it takes a vacation and some asteroid fills in for
a month.  You discover that your mom has a twin sister who baked all the
chocolate-chip cookies you used to love when you were a kid (and all these
years you just thought she was absent-minded when she was baking!).  Your
car turns out not to be eqv? to your car.  Weinreb and Steele jointly
invest in a rare Quux-head penny; then Weinreb tells his insurance company
that his penny got squished, while Steele sells his, in mint condition, to
a collector.

Discovering that two objects are really one is a lot of what computation is
all about: it means you have discovered an interesting cycle in a graph of
relationships.  But discovering that one object is really two is a subversion
of naming and the entire notion of object identity.  This is why people get
upset over MAX not returning one of its arguments.  Suppose you took bids from
three carpenters and asked me to select the best one, and I replied that the
best of the three was some fourth carpenter you never heard of.  Yes, his bid
and reputation are, as close as one can tell, at least as good as the best
actually submitted, but such shenanigans would be enough to get me thrown out
of public office.  (That's what I get for accepting bids from inexact carpenters.)

--Guy

P.S. Isn't it nice to be arguing this issue on clear-cut technical grounds
instead of just flaming away at each other?  :-)

∂26-Jul-89  1119	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	INF/SUP/MIN/MAX    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89  11:19:16 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28320; Wed, 26 Jul 89 13:52:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25417;
          26 Jul 89 13:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 13:38:15 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25407;
          26 Jul 89 13:36 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA28048; Wed, 26 Jul 89 13:36:31 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 26 Jul 89 13:33:14 edt
Date: Wed, 26 Jul 89 13:33:14 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907261733.AA22254@zurich.ai.mit.edu>
To: Alan@reagan.ai.mit.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Alan Bawden's message of Wed, 26 Jul 89 01:15 EDT <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Subject: INF/SUP/MIN/MAX

   Date: Wed, 26 Jul 89 01:15 EDT
   From: Alan Bawden <Alan@reagan.ai.mit.edu>

       Date: Tue, 25 Jul 89 19:06 EDT
       From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
       ...
       In my opinion, the whole INF/SUP debate comes down to a haughty
       disregard on the part of some designers for a clearly expressed need on
       the part of users.

   I don't see anybody else here defending this point of view, so it must be
   me who is being "haughty".  Below, I apparently become "anal" and
   "stubborn".  I must say, it's more fun arguing with Steele.

Just for the record, so far I agree with you Alan.  I've been
following the discussion but haven't said anything because I felt you
have been making arguments at least as good as any I could.

∂26-Jul-89  1122	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	INF/SUP/MIN/MAX follow-up  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89  11:21:43 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA28238; Wed, 26 Jul 89 13:45:03 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa24989;
          26 Jul 89 13:15 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 13:13:48 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa24778;
          26 Jul 89 13:07 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27775; Wed, 26 Jul 89 13:07:28 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Wed, 26 Jul 89 13:04:15 edt
Received: from fafnir.think.com by Think.COM; Wed, 26 Jul 89 13:07:52 EDT
Received: from verdi.think.com by fafnir.think.com; Wed, 26 Jul 89 13:05:37 EDT
Received: by verdi.think.com; Wed, 26 Jul 89 13:05:35 EDT
Date: Wed, 26 Jul 89 13:05:35 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907261705.AA08756@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Alan Bawden's message of Wed, 26 Jul 89 01:15 EDT <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Subject: INF/SUP/MIN/MAX follow-up


Warning: serious message follows.  :-|

Actually, the remark that "inexact numbers just't don't behave like numbers"
prompts me to ask "are inexact numbers expected to behave like objects"?
Maybe inexact numbers should be totally excused from the requirements of object
identity.  (They don't know just who they are, so why should anyone else?)
This also provides a loophole big enough to drive a pdl-number through.

--Guy

∂26-Jul-89  1215	@mc.lcs.mit.edu,@life.ai.mit.edu:KMP@stony-brook.scrc.symbolics.com 	INF/SUP/MIN/MAX 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89  12:13:56 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA29060; Wed, 26 Jul 89 14:54:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26105;
          26 Jul 89 14:48 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 14:48:08 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa26031;
          26 Jul 89 14:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA28880; Wed, 26 Jul 89 14:40:57 EDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (stony-brook.scrc.symbolics.com) by zurich.ai.mit.edu; Wed, 26 Jul 89 14:37:43 edt
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 631902; 26 Jul 89 14:41:59 EDT
Date: Wed, 26 Jul 89 14:41 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: INF/SUP/MIN/MAX
To: Alan@reagan.ai.mit.edu
Cc: KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: <19890726051514.2.ALAN@PIGPEN.AI.MIT.EDU>
Message-Id: <19890726184151.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Wed, 26 Jul 89 01:15 EDT
    From: Alan Bawden <Alan@reagan.ai.mit.edu>

    I've never heard users asking for the notion of exactness/inexactness at
    all.  Ask them what they want, and they will probably tell you that they
    want IEEE floating point.  As I have said before, I think it would be 100%
    reasonable for Scheme to do what every other language does, and adopt some
    reasonable set of rules for the behavior of floating point.  Unfortunately,
    Scheme decided to go in a different direction.  Inexact numbers are not
    just another name for floating point, so we have -already- decided to give
    users something other than what they would ask for.  What we are arguing
    about here, are the -consequences- of that decision for the function MIN.
    I was under the impression that the consistency of the language mattered,
    not just what the users think they want before you have a chance to explain
    the issues to them.

Well, it's funny because I agree with you on the language design
consistency issue, so I guess the fact I still feel bugged by this
issue exposes the fact that I really think that the decision of Scheme
(an otherwise serious language) to go with this baroque (albeit
mathematically elegant) theory of numbers is like asking the computer
community not to take it seriously.  It would be one thing if it -also-
provided floats, so that people could get real work done while they
waited for the other stuff to get field tested, but my own cynical
viewpoint is that--for quite a while yet, anyway-- implementations are
likely to be either correct or efficient, but not both.  At least with
floats the fact that games are being played is above board, and you
don't have to fail to conform in order to use standard hardware.

It reminds me of something I saw in the MGLA (Massachusetts General Law
Annotated) about stop light laws. It goes into elaborate detail about
how a city should compute how long a red light should be and it's
careful to point out that if you make the light too long, you encourage
disrespect for the law.  I think the point about inconvenience breeding
disrespect is an important one:  We have created a theory of numbers so
strange that it's likely that a noticeable fraction of would-be
implementors will implement all of the spec except for numbers.  That's
a shame because it encourages the idea that it's ok to deviate from the
spec.  I'd personally rather see something that people could implement
usefully, efficiently, straightforwardly and adhere so that there could
be lots of sparklingly conforming implementations.  If there's one
thing we've learned from Common Lisp --for whatever you may think of
the particular `semantics' it has--it's that there's tremendous value
in just having agreed on something and made it widely available.

I would also go farther and say that these days I am starting to
believe that what is more important than language standards is datatype
standards.  We always speak as if the different languages are just
different syntaxes for saying essentially the same thing.  That is,
whether I choose to write FORTRAN
 X=A*B
or Lisp
 (SETQ X (* A B))
is really an issue of my preferred syntax.  But if the primitive
operators themselves compute differing quantities, or if the data types
being passed around do not have a common significance to the different
languages, then the choice of language has an unreasonably elevated
importance because it brings with it an entire philosophy that the
other language much match up to, or must simulate.  Someone needs to
start agreeing on a common set of interchange terminology for two
languages to talk to one another.  I see most other languages involved
in trying to be able to talk to one another.  But I see Scheme crawling
into a corner and refusing to acknowledge the metaphors that those
other languages have chosen.  I am not sure this is a good thing.

I agree that advancement must always involve some degree of going
against the grain, but perhaps what I'm saying is that the world is not
exactly knocking at the door of the Scheme community asking where it
should go next.  If Scheme wants to affect what is going on, its users
need to start to offer some success stories about what you can do with
its stylized view of numbers that you can't do with `ordinary' numbers,
and start to convince other communities that this is worth paying
attention to.  For example, I think that Scheme has credibly done with
`continuations' -- not everyone thinks that first class continuations
are the right thing for every language (some don't even think they're
right for Scheme) but no one can deny that they are -seriously-
interesting, and have led to interesting successes/insights that might
not have been gotten via other means.  If Scheme numbers are to persist
in their current form, I would like to be able to speak as confidently
about their demonstrated usefulness, and I don't now feel that I have
the ammunition to do so.

		... I must say, it's more fun arguing with Steele.

Good of you to point this out.  I'll have to make a point of keeping him
in my camp on arguments so he can guest host my disputes with you when
my overnight ratings start to dip and my sponsors are getting nervous
about me.

Seriously though, I apologize if I seemed a little on the accusing side.
But I am able to contribute precious little time to the Scheme community
these days--much less than I'd like to anyway.  So it was more important
to me to make my opinions apparent than to spend a lot of time figuring
out how to present them in the most palatable light.

I certainly didn't mean that anyone should take what I had to say
personally, but I do stand by my overall sense that the Scheme community
spends is traditionally so far to the `right' (language design
politics-wise) that it risks alienating a fair fraction of the tiny
little part of the marketplace (i'm thinking usage-wise, not money-wise,
btw) that is likely to have otherwise appealed to.

T did this in its early days, too, by the way, and while there was clearly
some good effects of that, there have also been good effects due to just
catering to the expressed wants of the actual users.

∂26-Jul-89  1334	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	INF/SUP/MIN/MAX    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89  13:34:01 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00185; Wed, 26 Jul 89 16:13:37 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26967;
          26 Jul 89 15:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 15:58:30 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa26908;
          26 Jul 89 15:53 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA29807; Wed, 26 Jul 89 15:52:46 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 26 Jul 89 15:49:33 edt
Date: Wed, 26 Jul 89 15:49:33 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907261949.AA22282@zurich.ai.mit.edu>
To: gls@think.com
Cc: Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
        RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Wed, 26 Jul 89 12:58:15 EDT <8907261658.AA07734@verdi.think.com>
Subject: INF/SUP/MIN/MAX

   Date: Wed, 26 Jul 89 12:58:15 EDT
   From: Guy Steele <gls@think.com>

			      Suppose I was planning on feeding this result to
      MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?

   No, it isn't, Alan, and here's why.  Your example takes what we might expect
   to be two things and makes them one.  This happens all the time in real life.
   The morning star turns out to be the evening star also.  Your mom turns out to
   be the one who makes those yummy chocolate-chip cookies that are sold
   nation-wide.  Your car turns out to be eqv? to your cdr.  You have two pennies
   and put one on the railroad track, and the other one gets squished.  [This
   last example does not outrage intuition if pointers are used: "Last week I
   heard that Weinreb had acquired a rare 1903 Quux-head penny.  Yesterday at the
   party Steele was showing off a penny just like it, and he put it on the
   railroad track and it got squished.  Today I asked Weinreb if I could see his
   penny, and he sadly showed me that it had been squished."  This story rendered
   into Scheme is:
	   (penny? Weinreb) => #t
	   (set! Steele (+ Weinreb 1e-20))
	   (penny? Steele) => #t
	   (squish Steele)
	   (squished? Weinreb) => #t
   ]  You thought + would give you a different number, but because of
   machine limitations it gave you the same one back.

   It is a much more egregious error to take what you thought you knew to be
   one object and make it two.  You thought there was only one Venus, but it
   turns out that in August it takes a vacation and some asteroid fills in for
   a month.  You discover that your mom has a twin sister who baked all the
   chocolate-chip cookies you used to love when you were a kid (and all these
   years you just thought she was absent-minded when she was baking!).  Your
   car turns out not to be eqv? to your car.  Weinreb and Steele jointly
   invest in a rare Quux-head penny; then Weinreb tells his insurance company
   that his penny got squished, while Steele sells his, in mint condition, to
   a collector.

   Discovering that two objects are really one is a lot of what computation is
   all about: it means you have discovered an interesting cycle in a graph of
   relationships.  But discovering that one object is really two is a subversion
   of naming and the entire notion of object identity.  This is why people get
   upset over MAX not returning one of its arguments.  Suppose you took bids from
   three carpenters and asked me to select the best one, and I replied that the
   best of the three was some fourth carpenter you never heard of.  Yes, his bid
   and reputation are, as close as one can tell, at least as good as the best
   actually submitted, but such shenanigans would be enough to get me thrown out
   of public office.  (That's what I get for accepting bids from inexact carpenters.)

   --Guy

   P.S. Isn't it nice to be arguing this issue on clear-cut technical grounds
   instead of just flaming away at each other?  :-)

I don't buy these arguments: many of them have to do with side
effects, and since when are there any side effects on numbers?  So
they don't apply.

The rest, such as whether or not your car is eqv? to your car, don't
seem to contribute much to the discussion, except their obvious
entertainment value.  Perhaps I'm making a mistake in taking any part
of your message seriously.

Maybe the problem isn't the action of max or min, but eqv?  If we
considered equality as defined by = this question wouldn't come up.
Maybe eqv? is making too fine a distinction.

∂26-Jul-89  1405	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	INF/SUP/MIN/MAX  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89  14:04:50 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00594; Wed, 26 Jul 89 16:46:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27244;
          26 Jul 89 16:31 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 16:31:31 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa27180;
          26 Jul 89 16:26 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00258; Wed, 26 Jul 89 16:26:14 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Wed, 26 Jul 89 16:23:01 edt
Received: from fafnir.think.com by Think.COM; Wed, 26 Jul 89 16:26:42 EDT
Received: from verdi.think.com by fafnir.think.com; Wed, 26 Jul 89 16:24:27 EDT
Received: by verdi.think.com; Wed, 26 Jul 89 16:24:25 EDT
Date: Wed, 26 Jul 89 16:24:25 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907262024.AA06827@verdi.think.com>
To: cph@zurich.ai.mit.edu
Cc: gls@think.com, Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
        RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Wed, 26 Jul 89 15:49:33 edt <8907261949.AA22282@zurich.ai.mit.edu>
Subject: INF/SUP/MIN/MAX

   Date: Wed, 26 Jul 89 15:49:33 edt
   From: cph@zurich.ai.mit.edu (Chris Hanson)

      Date: Wed, 26 Jul 89 12:58:15 EDT
      From: Guy Steele <gls@think.com>

				 Suppose I was planning on feeding this result to
	 MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?

      No, it isn't, Alan, and here's why.  Your example takes what we might expect
      to be two things and makes them one.  This happens all the time in real life.
      The morning star turns out to be the evening star also.  Your mom turns out to
      be the one who makes those yummy chocolate-chip cookies that are sold
      nation-wide.  Your car turns out to be eqv? to your cdr.  You have two pennies
      and put one on the railroad track, and the other one gets squished.  [This
      last example does not outrage intuition if pointers are used: "Last week I
      heard that Weinreb had acquired a rare 1903 Quux-head penny.  Yesterday at the
      party Steele was showing off a penny just like it, and he put it on the
      railroad track and it got squished.  Today I asked Weinreb if I could see his
      penny, and he sadly showed me that it had been squished."  This story rendered
      into Scheme is:
	      (penny? Weinreb) => #t
	      (set! Steele (+ Weinreb 1e-20))
	      (penny? Steele) => #t
	      (squish Steele)
	      (squished? Weinreb) => #t
      ]  You thought + would give you a different number, but because of
      machine limitations it gave you the same one back.

      It is a much more egregious error to take what you thought you knew to be
      one object and make it two.  You thought there was only one Venus, but it
      turns out that in August it takes a vacation and some asteroid fills in for
      a month.  You discover that your mom has a twin sister who baked all the
      chocolate-chip cookies you used to love when you were a kid (and all these
      years you just thought she was absent-minded when she was baking!).  Your
      car turns out not to be eqv? to your car.  Weinreb and Steele jointly
      invest in a rare Quux-head penny; then Weinreb tells his insurance company
      that his penny got squished, while Steele sells his, in mint condition, to
      a collector.

      Discovering that two objects are really one is a lot of what computation is
      all about: it means you have discovered an interesting cycle in a graph of
      relationships.  But discovering that one object is really two is a subversion
      of naming and the entire notion of object identity.  This is why people get
      upset over MAX not returning one of its arguments.  Suppose you took bids from
      three carpenters and asked me to select the best one, and I replied that the
      best of the three was some fourth carpenter you never heard of.  Yes, his bid
      and reputation are, as close as one can tell, at least as good as the best
      actually submitted, but such shenanigans would be enough to get me thrown out
      of public office.  (That's what I get for accepting bids from inexact carpenters.)

      --Guy

      P.S. Isn't it nice to be arguing this issue on clear-cut technical grounds
      instead of just flaming away at each other?  :-)

   I don't buy these arguments: many of them have to do with side
   effects, and since when are there any side effects on numbers?  So
   they don't apply.

Granted.  "Plus ca change, plus c'est la meme chose", as Sussman and I
quoted in "The Art of the Interpreter".  The more things change, the more
they remain the same; that is, the notion of object identity may be linked
to the notion of side effect.  And yet, if numbers are not subject to
side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
I think that when we say 1 = 1, we are temporarily entertaining the
possibility that the two instances of "1" represent *different* things,
precisely so that we may then make the assertion that they are the same
after all.  If one of the 1's were not 1 after all, then things would be
different, including the truth of the equality.  This subjunctive
hypothesis amounts to a side effect, for we are considering, hypothetically
and however evanescently, a world altered from our own (whether by SETQ
or by adding an entry to the head of an a-list).

   The rest, such as whether or not your car is eqv? to your car, don't
   seem to contribute much to the discussion, except their obvious
   entertainment value.  Perhaps I'm making a mistake in taking any part
   of your message seriously.

On the contrary, I am trying (admittedly by entertaining means) to get at
the root of our intuitions about object identity, as I and many of us have
been doing for years now.  The entire point is that it is hardly surprising
to discover that (eqv? (car x) (cdr x)) is true; but it is horrifying to
discover that (eqv? (car x) (car x)) is false, and we go scurrying for
possible explanations (a parallel process maybe did a side effect between
the two calls to car ?).  The two cases are quite different.

   Maybe the problem isn't the action of max or min, but eqv?  If we
   considered equality as defined by = this question wouldn't come up.
   Maybe eqv? is making too fine a distinction.

Indeed, and this is essentially the subject of the message I sent
after this one (the one you replied to): maybe inexact numbers
should not possess object identity.  Please take this seriously.
(Maybe it's the wrong idea, but it's not a frivolous idea, I think.)

--Guy

∂26-Jul-89  1437	@mc.lcs.mit.edu,@life.ai.mit.edu:gjs@hpesogg.hp.com 	INF/SUP/MIN/MAX  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89  14:37:39 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00957; Wed, 26 Jul 89 17:25:05 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa27603;
          26 Jul 89 17:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 17:09:11 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa27573;
          26 Jul 89 17:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00771; Wed, 26 Jul 89 17:03:19 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Wed, 26 Jul 89 17:00:05 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.6b/SES42.42) id AA11348; Wed, 26 Jul 89 14:02:53 pdt
Message-Id: <8907262102.AA11348@sde.hp.com>
Received: by hpesogg; Wed, 26 Jul 89 14:01:54 pdt
Date: Wed, 26 Jul 89 14:01:54 pdt
From: Gerald Jay Sussman <gjs@hpesogg.hp.com>
To: Alan@reagan.ai.mit.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
Subject: INF/SUP/MIN/MAX


   I don't see anybody else here defending this point of view, so it must be
   me who is being "haughty".  Below, I apparently become "anal" and
   "stubborn".  I must say, it's more fun arguing with Steele.

Keep up the good work, I keep my mouth shut when I watch a master in
action.  And don't let the nasty things some people say get to you.
Steele is indeed fun, we need more of his time!

∂26-Jul-89  1952	@mc.lcs.mit.edu,@life.ai.mit.edu:kempf@sun.com 	Please Remove    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 26 Jul 89  19:52:28 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03711; Wed, 26 Jul 89 22:37:02 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00828;
          26 Jul 89 22:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 Jul 89 22:25:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00818;
          26 Jul 89 22:22 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03668; Wed, 26 Jul 89 22:22:45 EDT
Received: from Sun.COM ([192.9.9.1]) by zurich.ai.mit.edu; Wed, 26 Jul 89 22:19:32 edt
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
	id AA25442; Wed, 26 Jul 89 19:22:26 PDT
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA22947; Wed, 26 Jul 89 12:46:45 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA01346; Wed, 26 Jul 89 12:47:25 PDT
Message-Id: <8907261947.AA01346@suntana.sun.com>
To: rrrs-authors@zurich.ai.mit.edu
Subject: Please Remove
Date: Wed, 26 Jul 89 12:47:23 PDT
From: kempf@sun.com

I tried rrrs-authors-request, but that didn't work, so, risking flamage,
here is a request to remove me from this list. Thanx.

		jak

∂27-Jul-89  0855	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	INF/SUP/MIN/MAX  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89  08:54:51 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09751; Thu, 27 Jul 89 11:31:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09635;
          27 Jul 89 11:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 11:26:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09599;
          27 Jul 89 11:20 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09544; Thu, 27 Jul 89 11:20:02 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 27 Jul 89 11:16:45 edt
Received: from fafnir.think.com by Think.COM; Thu, 27 Jul 89 11:19:39 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 27 Jul 89 11:17:23 EDT
Received: by verdi.think.com; Thu, 27 Jul 89 11:17:20 EDT
Date: Thu, 27 Jul 89 11:17:20 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907271517.AA11786@verdi.think.com>
To: wand@corwin.ccs.northeastern.edu
Cc: gls@think.com, cph@zurich.ai.mit.edu, gls@think.com,
        Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
        RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Mitchell Wand's message of Thu, 27 Jul 89 09:30:53 ADT <8907271230.AA08188@corwin.CCS.Northeastern.EDU>
Subject: INF/SUP/MIN/MAX

   Date: Thu, 27 Jul 89 09:30:53 ADT
   From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>

      Date: Wed, 26 Jul 89 16:24:25 EDT
      From: Guy Steele <gls@think.com>

	 Date: Wed, 26 Jul 89 15:49:33 edt
	 From: cph@zurich.ai.mit.edu (Chris Hanson)
         ...
	 I don't buy these arguments: many of them have to do with side
	 effects, and since when are there any side effects on numbers?  So
	 they don't apply.

      Granted.  "Plus ca change, plus c'est la meme chose", as Sussman and I
      quoted in "The Art of the Interpreter".  The more things change, the more
      they remain the same; that is, the notion of object identity may be linked
      to the notion of side effect.  And yet, if numbers are not subject to
      side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
      I think that when we say 1 = 1, we are temporarily entertaining the
      possibility that the two instances of "1" represent *different* things,
      precisely so that we may then make the assertion that they are the same
      after all.  If one of the 1's were not 1 after all, then things would be
      different, including the truth of the equality.  This subjunctive
      hypothesis amounts to a side effect, for we are considering, hypothetically
      and however evanescently, a world altered from our own (whether by SETQ
      or by adding an entry to the head of an a-list).

   I'm not convinced by this argument.  While it is surely true that object
   identity is linked to the notion of side-effect, it does not follow that the
   truth or falsity of the proposition "1=1" has some subjunctive hypothesis that
   amounts to a side effect.  If there were a subjunctive hypothesis in "1=1", it
   would range over the class of propositions, ie those questions of the form 
   `M = N', as M and N range over some class of expressions.  The proposition
   asks whether M and N denote the same thing.  So "1 = 1" is true, but "1 = 2"
   is false.

Let me recapitulate the form of my entire argument.  I claimed:

A property that many programmers expect of MAX is that
	if  (MAX a b c ...) => x  then  x=a or x=b or x=c or ...
where I use infix "=" to mean object identity.  I complained
that the MAX in R3.95 fails to have this property.

Alan then compared this situation to that of +, remarking that
+ also fails, by returning something the same as an argument
when you expected it to be different.

I then countered that these were two different types of failure:
MAX fails to preserve object identity (given that one's model
of its behavior or implementation is that it ought to), whereas
+ fails to preserve object distinctness (given that a model
of the algebraic properties of + says they ought to be distinct.

Chris then objected that many of my informal examples revolved around the
notion of side effect, but because numbers as such are not subject to side
effects in Scheme those arguments were therefore irrelevant.

My reply was an attempt to restate my point about object identity
more clearly, but it is hard to discuss object identity without
dragging in side effects to some extent.

The failure of + to preserve object distinctness--that is, the failure
to obey the law
	if  x /= 0  then  x+y /= x
may be regarded as a bad definition or implementation of +.
On the other hand, a failure to preserve object identity in MAX,
while it may also be regarded as a bad definition or implementation
of MAX, also looks suspiciously like a breakdown of the naming or
equality mechanisms in the language, and is therefore much more disturbing.

I believe that "1 = 1" does entail a subjunctive hypothesis at some
stage if its interpretation process, because I regard the mark "1"
on the paper as a numeral and not a number; it's just another name,
one I have agreed not to alter capriciously most of the time.
(But you know what I mean when I say "He has fourteen cats--for some
value of fourteen.")  Until I have interpreted that mark and evaluated
it to the Platonic number one, there is the possibility that the
equality fails to hold.  Or I could regard the equality algebraically
instead of numerically, noting that the two sides are symbolically
identical; but then in deducing the truth of the equality I assume
that no side effect would take place during the hypothetical eventual
evaluation of the expressions.  It is not so much, I guess, that
the hypothesis *is* a side effect, as that it temporarily entertains
the possibility that one might occur.

--Guy

∂27-Jul-89  1106	@mc.lcs.mit.edu,@life.ai.mit.edu:gls@think.com 	INF/SUP/MIN/MAX and correct use of time   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89  11:05:58 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11699; Thu, 27 Jul 89 13:50:57 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09793;
          27 Jul 89 11:33 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 11:33:15 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09622;
          27 Jul 89 11:24 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09615; Thu, 27 Jul 89 11:24:50 EDT
Received: from Think.COM ([131.239.2.1]) by zurich.ai.mit.edu; Thu, 27 Jul 89 10:33:47 edt
Received: from fafnir.think.com by Think.COM; Thu, 27 Jul 89 10:35:49 EDT
Received: from verdi.think.com by fafnir.think.com; Thu, 27 Jul 89 10:33:30 EDT
Received: by verdi.think.com; Thu, 27 Jul 89 10:33:25 EDT
Date: Thu, 27 Jul 89 10:33:25 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8907271433.AA07821@verdi.think.com>
To: gjs@hpesogg.hp.com
Cc: Alan@reagan.ai.mit.edu, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Gerald Jay Sussman's message of Wed, 26 Jul 89 14:01:54 pdt <8907262102.AA11348@sde.hp.com>
Subject: INF/SUP/MIN/MAX and correct use of time

   Date: Wed, 26 Jul 89 14:01:54 pdt
   From: Gerald Jay Sussman <gjs@hpesogg.hp.com>


      I don't see anybody else here defending this point of view, so it must be
      me who is being "haughty".  Below, I apparently become "anal" and
      "stubborn".  I must say, it's more fun arguing with Steele.

   Keep up the good work, I keep my mouth shut when I watch a master in
   action.  And don't let the nasty things some people say get to you.
   Steele is indeed fun, we need more of his time!

Lest anyone think Alan and I have become bitter adversaries,
or that we are not spending our time appropriately, let me report
(forgive me, Alan) that we coincidentally ended up at the same
movie showing yesterday afternoon and when we met we grinned
at each other and shook hands.  We know how to spend our time.

Incidentally, "The Brave Little Toaster" is pretty fair animation, great
storytelling for the age level it is nominally pitched at, good
characterization (given that the heroes are household appliances), and has
some fine parody sequences for us so-called grown-ups.  (Maybe Alan will
have some differing opinion, and we can discuss *that* for a while. :-)

∂27-Jul-89  1116	@mc.lcs.mit.edu,@life.ai.mit.edu:wand@corwin.ccs.northeastern.edu 	INF/SUP/MIN/MAX   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89  11:16:38 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11722; Thu, 27 Jul 89 13:52:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09801;
          27 Jul 89 11:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 11:33:41 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa09627;
          27 Jul 89 11:26 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09628; Thu, 27 Jul 89 11:25:28 EDT
Received: from helios.northeastern.edu (helios.northeastern.edu) by zurich.ai.mit.edu; Thu, 27 Jul 89 10:02:21 edt
Received: from corwin.ccs.northeastern.edu by helios.northeastern.edu
          id aa17480; 27 Jul 89 15:00 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/SMI-3.2+CCS-main-2.6)
	id AA08188; Thu, 27 Jul 89 09:30:53 ADT
Date: Thu, 27 Jul 89 09:30:53 ADT
From: Mitchell Wand <wand@corwin.ccs.northeastern.edu>
Message-Id: <8907271230.AA08188@corwin.CCS.Northeastern.EDU>
To: gls@think.com
Cc: cph@zurich.ai.mit.edu, gls@think.com, Alan@reagan.ai.mit.edu,
        KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Guy Steele's message of Wed, 26 Jul 89 16:24:25 EDT <8907262024.AA06827@verdi.think.com>
Subject: INF/SUP/MIN/MAX

[Just to make sure that everyone's archive's continue to grow quadratically, I
will follow the usual protocol of inserting an indented copy of the
correspondence up to this point.]

   Date: Wed, 26 Jul 89 16:24:25 EDT
   From: Guy Steele <gls@think.com>
   To: cph@zurich.ai.mit.edu
   Cc: gls@think.com, Alan@reagan.ai.mit.edu,
	KMP@stony-brook.scrc.symbolics.com, RRRS-Authors@zurich.ai.mit.edu
   Subject: INF/SUP/MIN/MAX

      Date: Wed, 26 Jul 89 15:49:33 edt
      From: cph@zurich.ai.mit.edu (Chris Hanson)

	 Date: Wed, 26 Jul 89 12:58:15 EDT
	 From: Guy Steele <gls@think.com>

				    Suppose I was planning on feeding this result to
	    MEMBER? or ASSOC? -- isn't this just as bad as what MAX does?

	 No, it isn't, Alan, and here's why.  Your example takes what we might expect
	 to be two things and makes them one.  This happens all the time in real life.
	 The morning star turns out to be the evening star also.  Your mom turns out to
	 be the one who makes those yummy chocolate-chip cookies that are sold
	 nation-wide.  Your car turns out to be eqv? to your cdr.  You have two pennies
	 and put one on the railroad track, and the other one gets squished.  [This
	 last example does not outrage intuition if pointers are used: "Last week I
	 heard that Weinreb had acquired a rare 1903 Quux-head penny.  Yesterday at the
	 party Steele was showing off a penny just like it, and he put it on the
	 railroad track and it got squished.  Today I asked Weinreb if I could see his
	 penny, and he sadly showed me that it had been squished."  This story rendered
	 into Scheme is:
		 (penny? Weinreb) => #t
		 (set! Steele (+ Weinreb 1e-20))
		 (penny? Steele) => #t
		 (squish Steele)
		 (squished? Weinreb) => #t
	 ]  You thought + would give you a different number, but because of
	 machine limitations it gave you the same one back.

	 It is a much more egregious error to take what you thought you knew to be
	 one object and make it two.  You thought there was only one Venus, but it
	 turns out that in August it takes a vacation and some asteroid fills in for
	 a month.  You discover that your mom has a twin sister who baked all the
	 chocolate-chip cookies you used to love when you were a kid (and all these
	 years you just thought she was absent-minded when she was baking!).  Your
	 car turns out not to be eqv? to your car.  Weinreb and Steele jointly
	 invest in a rare Quux-head penny; then Weinreb tells his insurance company
	 that his penny got squished, while Steele sells his, in mint condition, to
	 a collector.

	 Discovering that two objects are really one is a lot of what computation is
	 all about: it means you have discovered an interesting cycle in a graph of
	 relationships.  But discovering that one object is really two is a subversion
	 of naming and the entire notion of object identity.  This is why people get
	 upset over MAX not returning one of its arguments.  Suppose you took bids from
	 three carpenters and asked me to select the best one, and I replied that the
	 best of the three was some fourth carpenter you never heard of.  Yes, his bid
	 and reputation are, as close as one can tell, at least as good as the best
	 actually submitted, but such shenanigans would be enough to get me thrown out
	 of public office.  (That's what I get for accepting bids from inexact carpenters.)

	 --Guy

	 P.S. Isn't it nice to be arguing this issue on clear-cut technical grounds
	 instead of just flaming away at each other?  :-)

      I don't buy these arguments: many of them have to do with side
      effects, and since when are there any side effects on numbers?  So
      they don't apply.

   Granted.  "Plus ca change, plus c'est la meme chose", as Sussman and I
   quoted in "The Art of the Interpreter".  The more things change, the more
   they remain the same; that is, the notion of object identity may be linked
   to the notion of side effect.  And yet, if numbers are not subject to
   side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?
   I think that when we say 1 = 1, we are temporarily entertaining the
   possibility that the two instances of "1" represent *different* things,
   precisely so that we may then make the assertion that they are the same
   after all.  If one of the 1's were not 1 after all, then things would be
   different, including the truth of the equality.  This subjunctive
   hypothesis amounts to a side effect, for we are considering, hypothetically
   and however evanescently, a world altered from our own (whether by SETQ
   or by adding an entry to the head of an a-list).

I'm not convinced by this argument.  While it is surely true that object
identity is linked to the notion of side-effect, it does not follow that the
truth or falsity of the proposition "1=1" has some subjunctive hypothesis that
amounts to a side effect.  If there were a subjunctive hypothesis in "1=1", it
would range over the class of propositions, ie those questions of the form 
`M = N', as M and N range over some class of expressions.  The proposition
asks whether M and N denote the same thing.  So "1 = 1" is true, but "1 = 2"
is false.  If we embed these in a programming language, then we can get
confused in two ways:

1.  The value denoted by the expression M may be implementation-dependent.
Therefore the truth or falsity of "M = N" may be implementation-dependent.

2.  The computation of M and N may cause side-effects which change the objects
that M and N compute.  Thus (eqv? (car x) (car x)) may fail because there is
some parallel process interfering with the calculation.

It seems to me that (1) is the major source of problems here, because we have
been very careful to NOT completely specify the semantics of numbers (exact OR
inexact).  Unless we want to go the whole way and talk about "inexact
booleans" (which I do not recommend), at some point we have to make a cut and
admit implementation-dependence rather than inexactness.  [My guess is that
we've done a pretty good job of choosing where to make this cut, judging by
the arcana in the discussion so far].  We probably shouldn't get distracted by
(2), which seems largely independent.

      The rest, such as whether or not your car is eqv? to your car, don't
      seem to contribute much to the discussion, except their obvious
      entertainment value.  Perhaps I'm making a mistake in taking any part
      of your message seriously.

   On the contrary, I am trying (admittedly by entertaining means) to get at
   the root of our intuitions about object identity, as I and many of us have
   been doing for years now.  The entire point is that it is hardly surprising
   to discover that (eqv? (car x) (cdr x)) is true; but it is horrifying to
   discover that (eqv? (car x) (car x)) is false, and we go scurrying for
   possible explanations (a parallel process maybe did a side effect between
   the two calls to car ?).  The two cases are quite different.

      Maybe the problem isn't the action of max or min, but eqv?  If we
      considered equality as defined by = this question wouldn't come up.
      Maybe eqv? is making too fine a distinction.

   Indeed, and this is essentially the subject of the message I sent
   after this one (the one you replied to): maybe inexact numbers
   should not possess object identity.  Please take this seriously.
   (Maybe it's the wrong idea, but it's not a frivolous idea, I think.)

   --Guy

--Mitch


∂27-Jul-89  1122	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:kend@mrloog.la.tek.com 	Re: Regularization of apply (long)  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89  11:22:19 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA11909; Thu, 27 Jul 89 14:06:16 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa10786;
          27 Jul 89 12:49 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 12:49:06 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa10746;
          27 Jul 89 12:44 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10663; Thu, 27 Jul 89 12:44:05 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Thu, 27 Jul 89 12:40:49 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa03574; 27 Jul 89 12:40 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
	id AA05947; Thu, 27 Jul 89 09:41:35 PDT
Received: by dadla.LA.TEK.COM (5.51/6.24)
	id AA06439; Thu, 27 Jul 89 09:22:54 PDT
Received: by mrloog.la.tek.com (1.2/7.1)
	id AA08823; Thu, 27 Jul 89 09:27:42 pdt
Message-Id: <8907271627.AA08823@mrloog.la.tek.com>
To: jinx%hpesogg@sde.hp.com
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu,
        gls@think.com
Subject: Re: Regularization of apply (long)
Date: 27 Jul 89 09:27:35 PDT (Thu)
From: kend%mrloog.la.tek.com@relay.cs.net

>[Ken Dickey]
>   I would prefer that APPLY be applicable only to multiple values.  For
>   that matter, I favor multiple value rest arguments--dropping rest *lists*
>   altogether.

>[Jinx]
>What do you mean by multiple values?  
>Do you mean something like LAMBDA*'s & pseudo-objects?  
>If you mean something along the more traditional lines, you have just
>pushed the problem one level deeper, since your multiple value
>receivers are also expressed in lambda notation and therefore you need
>to have dotted lists.

Yes, I will say it.  I like LAMBDA* [with some restrictions: single-value
assignments only, single rest argument, I prefer VALUES to #\& for multiple
value returns].  I use T's RETURN/RECEIVE and find multiple values quite
handy.  LAMBDA* provides a convenient way to bind/spread multiple values.
There it is, out of the closet.

I happen to think that LAMBDA* can be compiled to add significant
performance (over rest lists), particularly in the presence of early
binding.  I happen to be working in an environment where this matters
(semi-realtime embedded systems).  Having the user do a case dispatch on
the number of arguments (particularly using rest lists) usually looses in
the speed department.  I also think that errors are fewer when the
compiler can check them--and possibly optimize away the checks.

Your coroutines are pretty neat, but don't help me out much for
variable-arity proceedures.

  (define PPRINT
     (lambda* 
	[(<value> <port> <line-length>)
	  (%pprint <value> <port> <line-length>)]
	[(<value> <port>)
	  (%pprint <value> <port> default-line-length)]
	[(<value>)
	  (%pprint <value> (standard-output) default-line-length)]
  )  )

I know that you can construct code to handle such cases, but question
whether this can be compiled as efficently (given comparitive
implementation effort).  Personally, I would rather have the
opportunities for optimization using multiple values and lambda* because
I think that we could do some really winning code generation.

-Ken Dickey		kend@mrloog.LA.TEK.COM


∂27-Jul-89  1209	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	Multiple Values for R5RS (VERY LONG)    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jul 89  12:09:40 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA12542; Thu, 27 Jul 89 14:54:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa12121;
          27 Jul 89 14:37 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 14:33:38 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa11974;
          27 Jul 89 14:28 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12213; Thu, 27 Jul 89 14:27:08 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Thu, 27 Jul 89 14:23:39 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA08835; Thu, 27 Jul 89 11:26:00 PDT
Date: Thu, 27 Jul 89 11:26:00 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8907271826.AA08835@sesame.Stanford.EDU>
To: RRRS-Authors@zurich.ai.mit.edu
Subject: Multiple Values for R5RS (VERY LONG)


The following proposal is for R5RS ****NOT**** R4RS.

It is our impression that the discussions at Snowbird on multiple values
broke down mostly due to misunderstandings.  At this time, we would like to
make a proposal which we feel addresses all of the concerns expressed during
those and subsequent discussions.  We would appreciate responses to this
proposal, both pro and con, so as to ensure continued discussion of this
issue, and its eventual (we hope) resolution.

This proposal contains the following components:
        1.  A description of the introduced procedures.
        2.  A discussion of a number of the design decisions.
        3.  A presentation of several 'higher' level constructs which can be
            built using the introduced primitives.

Our proposal calls for the introduction of three new procedures, only one of
which does not have a naive implementation in R4RS.  The functions and their
semantics are as follows (we suggest these names only to protect the
innocent):


(values obj ...)                                        essential procedure

Returns 0 or more values to an accepting form.

        (values)        =>              returns zero (no) values

        (values 1)      =>              returns a single value, 1

        (values 1 'a) 	=>              returns two values, 1 and the symbol a


(apply-values receiver generator)                       essential procedure

Applies the procedure 'receiver' to the values generated by thawing the
thunk, 'generator'.  The arity of 'receiver' must be compatible with the
return-arity of 'generator' (i.e., the number of values returned by
'generator').  In the absence of a rest argument, the arity of 'receiver'
must be identical to the return-arity of 'generator'.  The formals of
'receiver' will be bound to fresh locations and the values returned by
'generator' will be stored in the respective locations.  When a rest
argument is present, the return-arity of 'generator' must be greater than or
equal to the number of required arguments to 'receiver'.  The required
actuals will be handled as above; the rest argument will be bound to a fresh
location in which a newly created list, composed of the remaining actuals
returned by 'generator', will be stored.  It is an error for the arity of
'receiver' and the return-arity of 'generator' to be incompatible.  [This
will be discussed later in the proposal.]

        (apply-values cons
               (lambda ()
                 (values 1 2)))         =>              (1 . 2)


(arity applicable)                                      essential procedure

The argument to arity must be an applicable object (i.e., objects for which
procedure? returns #t).  Arity returns three values:  the minimum number of
actuals accepted by 'applicable', the maximum number of actuals accepted by
'applicable' (excluding, if present, a rest argument, and including optional
arguments, for those implementations that support optionals), and a boolean
representing the presence of a rest argument.

        (arity car)             =>              1, 1, #f

        (arity +)               =>              1, 1, #t

In an implementation that supports optional arguments (which we will denote
using &optional)...

        (arity (lambda (x &optional y)
          <body>))                             =>              1, 2, #f

        (arity (lambda (x &optional y . rest)
          <body>))                             =>              1, 2, #t

        (car (call/cc
	      (lambda (k)
		(arity k)		; arity would return 1, 1, #f
		<body>)))

        (apply-values cons
		      (lambda ()
			(call/cc
			 (lambda (k)
			   (arity k)	; arity would return 2, 2, #f
			   <body>))))

        (apply-values (lambda (. args)
			<body>)
		      (lambda ()
			(call/cc
			 (lambda (k)
			   (arity k)	; arity would return 0, 0, #t
			   <body>))))
 
        (begin
	  <expression>
	  ...
	  (call/cc
	   (lambda (k)
	     (arity k)			; arity would return 0, 0, #t
	     <body>))
	  ...
	  <expression>)

If a continuation is captured in a tail-recursive position, the
continuation's arity is determined by the accepting stack frame.

        (cons <expression>
	      (begin
		<expression>
		...
		(call/cc
		 (lambda (k)
		   (arity k)		; arity would return 1, 1, #f
		   <body>))))

        (apply-values +
		      (lambda ()
			<expression>
			...
			(call/cc
			 (lambda (k)
			   (arity k)	; arity would return 0, 0, #t
			   <body>))))


A point of contention at Snowbird was the issue of incompatibility of arity
between generators and receivers.  In our proposal returning to few values
is an error to maintain symmetry with procedure application.  While there
seemed to be virtually universal agreement on the former point, the
appropriate manner of handling the return of more values than expected was
not agreed upon.  Based on the following three considerations, we propose
that returning excessive values be considered an error:

        1.  Currently the application of a procedure to excessive arguments is
            an error in RNRS; similarly, multiple value application of a
            procedure to too many actuals should also be an error.

        2.  It is sometimes desirable to create upwardly compatible versions of
            procedures by increasing their return-arity.  This can be
            accomplished through the use of 'call/cc' and 'arity'.  For
            example, the standard definition of 'quotient' could be extended to
            return both the quotient and remainder, as follows:

            (define quotient
	      (let ((original-quotient quotient))
		(lambda (n1 n2)
		  (call/cc		;Capture the implicit continuation
		   (lambda (k)
		     (if (apply-values	;If k accepts more than one actual
			  (lambda (min max rest?)
			    (or rest?
				(>= max 2)))
			  (lambda ()
			    (arity k)))
			 (values (original-quotient n1 n2)
				 (remainder n1 n2))
			 (original-quotient n1 n2)))))))

        3.  Some individuals at Snowbird desired CLtL semantics for the return
            of multiple values to a form which expecting a single value (i.e.,
            stripping).  This functionality can be achieved using a
            'first-value' procedure which can be written in standard RNRS.

            (define first-value
	      (lambda (thunk)
		(apply-values (lambda (return-me . rest)
				return-me)
			      thunk)))

            Further, a generalized values referencing procedure can be defined
            as shown below:

            (define values-ref
	      (lambda (thunk n)
		(apply-values (lambda (. args)
				(list-ref args n))
			      thunk)))

            One of the advantages of this approach is that some programming
            errors could be recognized at compile time; otherwise, these errors
            would not be detectable until runtime.


NOTES:

1.  In our proposal multiple return values are not a first class data type.

2.  This proposal does NOT specify the return-arity of the current RNRS
    procedures; but, this must be done as part of any eventually agreed upon
    semantics for multiple values.

3.  We would like (values <arg>) and <arg> to be operationally equivalent.
    However in deference to implementors who want to minimize the number of
    modifications needed to support multiple values, we have required only one
    modification, the addition of the primitive arity.  To get the semantics we
    desire, it would appear that modification to an implementation's procedure
    application mechanism would be required.  If implementors are agreeable,
    we advise that the above semantics be added to our working proposal.
    Procedure application could then be viewed as syntactic sugar for a
    multiple values application as shown below:

    (f x y ...)     =     (apply-values f (lambda () (values x y ...)))
                  alpha


EXTRA FOR EXPERTS:

(define make-values->
  (lambda (constructor)
    (lambda (thunk)
      (apply-values constructor
		    thunk))))

(define values->vector
  (make-values-> vector))


Given a macro package (e.g., Extend Syntax) one can define:

(extend-syntax (multiple-value-let)
	       ((multiple-value-let formals generator body ...)
		(apply-values (lambda formals
				body ...)
			      generator)))

(peace chance)

	Morry & mas

∂28-Jul-89  1154	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	Regularization of apply (long) 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89  11:54:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00597; Fri, 28 Jul 89 14:37:17 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16292;
          27 Jul 89 19:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 19:46:42 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16200;
          27 Jul 89 19:39 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03289; Thu, 27 Jul 89 19:39:25 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 27 Jul 89 19:36:13 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA18897; Thu, 27 Jul 89 16:39:07 pdt
Message-Id: <8907272339.AA18897@sde.hp.com>
Received: by hpesogg; Thu, 27 Jul 89 16:38:10 pdt
Date: Thu, 27 Jul 89 16:38:10 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: kend%mrloog.la.tek.com@relay.cs.net
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu,
        gls@think.com
In-Reply-To: kend%mrloog.la.tek.com@relay.cs.net's message of 27 Jul 89 09:27:35 PDT (Thu) <8907271627.AA08823@mrloog.la.tek.com>
Subject: Regularization of apply (long)
Reply-To: jinx%hpesogg@sde.hp.com

    Your coroutines are pretty neat, but don't help me out much for
    variable-arity proceedures.

      (define PPRINT
	 (lambda* 
	    [(<value> <port> <line-length>)
	      (%pprint <value> <port> <line-length>)]
	    [(<value> <port>)
	      (%pprint <value> <port> default-line-length)]
	    [(<value>)
	      (%pprint <value> (standard-output) default-line-length)]
      )  )

    I know that you can construct code to handle such cases, but question
    whether this can be compiled as efficently (given comparitive
    implementation effort).  Personally, I would rather have the
    opportunities for optimization using multiple values and lambda* because
    I think that we could do some really winning code generation.

I'm not advocating the particular details of the code that I
submitted.  They were just a hint of what I would like to see.

I also feel quite strongly that the following three issues are
separable.  Lambda* jumbles them up, and that is my main problem with
it:

1) Multiple values.
2) Dispatch on variable arity.
3) Acceptance of "unbounded" numbers of arguments.

I think many people agree that the current "dot notation" and apply
have some problems, but I don't think that replacing them with lambda*
solves them.  The three issues above are (I think) independent, and
should be solved by independent mechanisms.

A second point is that I don't like special forms when procedures can
do the job, and all the three issues above can be solved as
efficiently by adding procedures as by adding special forms.
Special forms are syntactic cuteness that people who so desire can add
on top.  Real men don't use macros :-)


∂28-Jul-89  1219	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	INF/SUP/MIN/MAX 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89  12:18:18 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01152; Fri, 28 Jul 89 15:00:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16296;
          27 Jul 89 19:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 27 Jul 89 19:46:55 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16208;
          27 Jul 89 19:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03324; Thu, 27 Jul 89 19:40:55 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Thu, 27 Jul 89 19:37:42 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA18924; Thu, 27 Jul 89 16:40:34 pdt
Message-Id: <8907272340.AA18924@sde.hp.com>
Received: by hpesogg; Thu, 27 Jul 89 16:39:54 pdt
Date: Thu, 27 Jul 89 16:39:54 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: wand@corwin.ccs.northeastern.edu
Cc: gls@think.com, cph@zurich.ai.mit.edu, gls@think.com,
        Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
        RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Mitchell Wand's message of Thu, 27 Jul 89 09:30:53 ADT <8907271230.AA08188@corwin.CCS.Northeastern.EDU>
Subject: INF/SUP/MIN/MAX
Reply-To: jinx%hpesogg@sde.hp.com


    [Just to make sure that everyone's archive's continue to grow quadratically, I
    will follow the usual protocol of inserting an indented copy of the
    correspondence up to this point.]

There are two incompatible mail file GC algorithms. :-)

The reason I copy the incoming message is that I get paranoid whenever
my mail file has more than 10 messages, therefore I flush all incoming
message.  If messages did not include the message they were answering,
I would be lost, since I could not go back (conveniently) to read the
source of confusion.

∂28-Jul-89  1401	@mc.lcs.mit.edu:Alan@REAGAN.ai.mit.edu 	Numbers   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89  14:01:30 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02863; Fri, 28 Jul 89 16:47:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17485;
          27 Jul 89 21:16 EDT
Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 27 Jul 89 21:16:48 EDT
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 241995; Thu 27-Jul-89 21:15:30 EDT
Date: Thu, 27 Jul 89 21:15 EDT
From: Alan Bawden <Alan@reagan.ai.mit.edu>
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8907261612.AA01435@verdi.think.com>,
             <8907261658.AA07734@verdi.think.com>,
             <8907261705.AA08756@verdi.think.com>,
             <19890726184151.4.KMP@BOBOLINK.SCRC.Symbolics.COM>,
             <8907271433.AA07821@verdi.think.com>
Message-Id: <19890728011525.2.ALAN@PIGPEN.AI.MIT.EDU>

    Date: Wed, 26 Jul 89 12:12:27 EDT
    From: gls@Think.COM (Guy Steele)
    ...
    So the main advantage of INF is that it signals an error telling me
    that INF was the wrong thing, so that I can rewrite my code to use MIN
    instead, right?  :->

No, INF returns a result that causes an error to be signaled, so that you
can rewrite your code to avoid the overflow.  You should still use INF so
that future bugs of a similar nature will be caught too!

    But bucket 2148565200 *is* the last bucket.  You have forgotten your
    original premise:...

Quite right, I got my 10-digit numbers mixed up.  I knew that the incorrect
bucket index had to be divisible by a moderate power of two (due to the
construction of the example) and then I momentarily forgot that Lisp
programmers no longer use octal all the time...

    Date: Wed, 26 Jul 89 12:58:15 EDT
    From: gls@Think.COM (Guy Steele)

	 (+ 1.0 1e20)  ==>  1.0

    Hm.  My mom might complain about this one too.  Maybe you meant
    "1e-20"?  Or else you got ripped off if you paid more than $2 for that
    implementation.

*Cough*  A typo.  I hope everybody understood what I meant.

       Suppose I was planning on feeding this result to  MEMBER? or
       ASSOC? -- isn't this just as bad as what MAX does?

    No, it isn't, Alan, and here's why.  Your example takes what we might
    expect to be two things and makes them one....

OK, so it isn't -exactly- the same effect, but the parallel that I was
trying to draw is that you can write a piece of code that depends on the
ideal properties of the abstract function +, and you can write a program
that depends on the ideal properties of the abstract function MAX, and in
both cases you can be suprised.

I wonder, by the way, what those of you who insist that MAX must return
something EQV? to one of its arguments because "MAX computes -the- maximum
of a set of numbers", think should be the answer in the case of (MAX 1 1.0)? 

    Date: Wed, 26 Jul 89 13:05:35 EDT
    From: gls@Think.COM (Guy Steele)
    Actually, the remark that "inexact numbers just't don't behave like
    numbers" prompts me to ask "are inexact numbers expected to behave like
    objects"?  Maybe inexact numbers should be totally excused from the
    requirements of object identity.  (They don't know just who they are,
    so why should anyone else?)  This also provides a loophole big enough
    to drive a pdl-number through.

Indeed quite a large loophole.  I want everyone to keep it clear that I am
-not- advocating anything like this.  I am a believer in object identity
even for inexact numbers.  Inexact numbers may not be "numbers" in some
sense of the word, but inexact numbers -are- objects.  (They are objects
that -represent- numbers.  Or perhaps more precisely, they are objects that
represent our knowledge of about certain numbers.)  What we are arguing
about here is the contract of MIN and MAX, nothing more.
[ This paragraph is not addressed to Steele or any of the other current
participants in this discussion, but to casual readers of RRRS-Authors who
might read Steele's remarks here and jump to the conclusion that I am
advocating something radical that I am not. ]

    Date: Wed, 26 Jul 89 14:41 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    ...  At least with floats the fact that games are being played is above
    board, and you don't have to fail to conform in order to use standard
    hardware.

    ... We have created a theory of numbers so strange that it's likely
    that a noticeable fraction of would-be implementors will implement all
    of the spec except for numbers.

I am not aware of any reasons why inexact numbers cannot be implemented
efficiently using standard floating point as the representation.  The fact
that we have complicated arguments about the behavior of inexact numbers
does -not- imply that implementation of those behaviors needs to be
complicated.

    Date: Thu, 27 Jul 89 10:33:25 EDT
    From: gls@Think.COM (Guy Steele)
    ...
    Incidentally, "The Brave Little Toaster" is pretty fair animation, great
    storytelling for the age level it is nominally pitched at, good
    characterization (given that the heroes are household appliances), and has
    some fine parody sequences for us so-called grown-ups.  (Maybe Alan will
    have some differing opinion, and we can discuss *that* for a while. :-)

I'll agree with you on most of this.  The animation did seem pretty
uninspired, but the producers clearly weren't aiming for great technical or
artistic achievement.  I especially enjoyed the appliances-from-hell.
I'd give it a mild thumbs up.

∂28-Jul-89  1635	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #170 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89  16:35:08 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04585; Fri, 28 Jul 89 18:48:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28077;
          28 Jul 89 17:49 EDT
Date: 28 JUL 89  17:21:59 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #170 
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id:  <8907281749.aa28077@mintaka.lcs.mit.edu>

Scheme Digest #170                             28 JUL 89  17:21:59 EDT

Today's Topics:

        Scheme Release 7 Beta Test
        Scheme Release 7 Beta Test
        Elk (Extension Language Kit) submitted to comp.sources.unix

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

Date: Thu, 27 Jul 89 00:52:27 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907270452.AA26278@zurich.ai.mit.edu>
Subject: Scheme Release 7 Beta Test

MIT Scheme release 7 is now available for beta test.  This release
contains many notable changes:

    * Liar, the native code compiler, is supported for 68020 and Vax
    computers.  Rough performance measurements indicate that it
    produces code that is competitive with Orbit and Lucid Common Lisp
    (although there's still some work left to beat them consistently).
    High-quality debugging support is standard -- the debugger
    provides nearly the same information for compiled and interpreted
    code.

    * Edwin, the Emacs-like text editor, is supported under curses and
    X version 11.  Unlike the stripped-down version supplied with TI
    PC-Scheme, this is a fully-extensible editor with most of the GNU
    Emacs features.  Due to performance considerations it is likely to
    be useful only on machines that have compiler support.

    * A reference manual, written in Texinfo, is supplied.  The manual
    is still incomplete but even so documents a substantial part of
    the system.  Because it is written in Texinfo, it can be either
    printed or browsed on-line with the Edwin (or GNU Emacs) info
    subsystem.

    * Two-dimensional line and point graphics support for X version 11
    is standard.  Color, border, size, and position controls are
    provided.

Because this is a beta test, users should expect the installation to
be less than completely smooth.  Although we have done extensive
debugging here at MIT, you should expect bugs as well.  We solicit
your bug reports, criticisms, and any other comments about the
release.

A few important things are still missing, including: (1) detailed
documentation for using the compiler and editor, and (2) a
compatibility mode for S&ICP classes.  We hope to remedy these, and
many other defects, by the end of August when the full release will
occur.

We've tested installation on the following machines, and would greatly
appreciate any efforts that you could make getting things running on
any other machines:

    HP 9000 series 300 and 800 running HP-UX
    Sun3 running SunOS
    Vax running Ultrix
    DS3100 running Ultrix

This release may be obtained by anonymous ftp to "zurich.ai.mit.edu"
(internet address 18.26.0.176), from the directory "pub/scheme-7.0/".
See the README file in that directory for further directions.

Because a number of people have had trouble using ftp to that machine,
we plan to distribute from a second host.  When we have an alternate
host, it will be announced.

We will not be mailing tapes of this release until the beta test has
finished and the full release is out; however if you show up at MIT
with a 9-track magtape we'll be happy to put the software on it.

As usual, report bugs to

    bug-cscheme@zurich.ai.mit.edu

If you receive this message from another source, and would like to be
included on the MIT Scheme mailing list, please send a request to

    info-cscheme-request@zurich.ai.mit.edu

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

Date: Thu, 27 Jul 89 01:29:10 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8907270529.AA26430@zurich.ai.mit.edu>
Subject: Scheme Release 7 Beta Test

The secondary host for distribution of Scheme Release 7 is the host
"prep.ai.mit.edu" (internet address 18.71.0.38).  Use anonymous ftp
and look in the directory "pub/gnu/scheme-7.0/".

At present, due to space restrictions, this secondary site carries
only the minimum required installation files.  None of the optional
files for source, documentation, etc. will fit there.  If feasible, we
will make the rest of the distribution available there in the future.

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

Date: 26 Jul 89 13:19:26 GMT
From: Oliver Laumann <mcvax!unido!tub!net@uunet.uu.net>
Subject: Elk (Extension Language Kit) submitted to comp.sources.unix
Message-Id: <883@tub.UUCP>

I would like to announce the posting of Elk (the Extension Language
Kit) to comp.sources.unix.  Elk is a Scheme interpreter intended to be
used as a general extension language interpreter.  Interfaces to the
X11R3 Xlib and the Athena and HP widget sets are part of the distribution.

This might also be of interest to the readers of comp.soft-sys.andrew
because of the recent discussion about extension languages.

Attached to this article you will find a copy of the release notes.

Regards,
--
Oliver Laumann              net@TUB.BITNET              net@tub.UUCP

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

Elk Release Notes
-----------------

This is release 1.0 of Elk (The Extension Language Kit).
This is a production release.

Elk is a Scheme interpreter intended to be used as a general extension
language; it is also useful as a stand-alone implementation of Scheme.

One purpose of the Elk project is to end the recent proliferation of
mutually incompatible Lisp-like extension languages.  Instead of
inventing and implementing yet another extension language, application
programmers can link the Scheme interpreter into their application
in order to make it extensible and highly customizable.

The Elk project was started in 1987 to support ISOTEXT, an ODA-based
document system (a WYSIWYG editor) that is being developed at the
Technical University of Berlin.  Elk has been successfully demonstrated
as the extension language kernel of ISOTEXT, e.g. at the Hanover Fair 1989.

We feel that Scheme is better suited as a general extension language
than other Lisp dialects:  it is sufficiently small to not dwarf the
application it serves and to be fully understood with acceptable
effort; it is orthogonal and well-defined.  In addition, Scheme has
been recognized to be mature enough for national and international
standardization (IEEE P1178, ISO/IEC JTC1/SC22/WG16).

The Elk Scheme interpreter is R↑3RS compatible (with some minor exceptions
listed in a separate document); future releases will conform to the R↑4RS
and/or P1178 as soon as the respective standards become available.

Non-standard features of the Scheme implementation include:

      o  dynamic loading of object files
      o  creation of an executable image from the running
         interpreter (``unexec'')
      o  a macro facility
      o  environments as first-class objects
      o  dynamic-wind, fluid-let
      o  autoloading, provide/require

The Scheme interpreter can easily be extended by application-specific
new types and primitive procedures.  Such extensions are typically
written in C or C++ and dynamically loaded into the running interpreter.

The current release of Elk includes several such extensions, e.g.
interfaces to the X11 Xlib and to the application programmer interface
of the Xt intrinsics, and interfaces to the Athena widget set and the
HP widget set.

The software currently runs on Sun-3s with SunOS, ISI 680x0 with 4.2BSD
or 4.3BSD, Vax with 4.3BSD or Ultrix, and Intel 80386 with System V
Release 3.  Porting instructions are included.  Dynamic loading of
object modules is not supported under System V.

--
Oliver Laumann, Technical University of Berlin, Germany
Communications and Operating Systems Research Group

net@tub.BITNET     Europe: unido!tub!net    World: pyramid!tub!net

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

End of Scheme Digest
********************

∂28-Jul-89  1839	@mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu 	INF/SUP/MIN/MAX
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89  18:39:14 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06202; Fri, 28 Jul 89 21:28:40 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01127;
          28 Jul 89 21:06 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 28 Jul 89 19:20:27 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa23294;
          28 Jul 89 11:15 EDT
Received: from zurich.ai.mit.edu ([18.26.0.176]) by life.ai.mit.edu (4.1/AI-4.10) id AA05753; Fri, 28 Jul 89 02:04:13 EDT
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by zurich.ai.mit.edu; Fri, 28 Jul 89 01:59:21 edt
Received: from Edusa.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA07578; Thu, 27 Jul 89 21:25:18 PDT
Message-Id: <8907280425.AA07578@mojave.Stanford.EDU>
Received: by sid; Thu, 27 Jul 89 21:27:48 pdt
Date: Thu, 27 Jul 89 21:27:48 pdt
To: Alan@reagan.ai.mit.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Chris Hanson's message of Wed, 26 Jul 89 13:33:14 edt <8907261733.AA22254@zurich.ai.mit.edu>
Subject: INF/SUP/MIN/MAX
From: Jonathan Rees <jar%sid.stanford.edu@polya.stanford.edu>
Sender: jar@sid.stanford.edu

   Date: Wed, 26 Jul 89 13:33:14 edt
   From: Chris Hanson <cph@zurich.ai.mit.edu>

   Just for the record, so far I agree with you Alan.  I've been
   following the discussion but haven't said anything because I felt you
   have been making arguments at least as good as any I could.

Ditto.

∂28-Jul-89  2243	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #171 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 28 Jul 89  22:43:41 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08719; Sat, 29 Jul 89 01:08:03 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa03596;
          29 Jul 89 0:40 EDT
Date: 29 JUL 89  00:06:57 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #171 
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id:  <8907290040.aa03596@mintaka.lcs.mit.edu>

Scheme Digest #171                             29 JUL 89  00:06:57 EDT

Today's Topics:

        Equivalence predicates
        Inquiry about functional command shells

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

Date: Fri, 28 Jul 89 15:09:46 +0200
From: Oliver Laumann <unido!tub!net@uunet.uu.net>
Message-Id: <8907281309.AA26250@tub.UUCP>
Subject: Equivalence predicates

The Revised↑n Report on Scheme does not specify the result of
eq?, eqv?, and equal? applied to ports and end-of-file objects.
Is this intentional?  E.g. what is the result of

       (equal? (read) (read))

provided that both reads return an end-of-file object?

Regards,
--
Oliver Laumann              net@TUB.BITNET              net@tub.UUCP

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

Date: 28 Jul 89 18:15:47 GMT
From: John Lacey <lacey@tcgould.tn.cornell.edu>
Subject: Inquiry about functional command shells
Message-Id: <8512@batcomputer.tn.cornell.edu>

This coming fall I am going to embark on a programming project to build a
UNIX shell based on a functional programming paradigm.  My initial
inclination is to build the shell from a Lisp interpreter/compiler---options
so far include MIT Scheme, Yale T, and perhaps XScheme or the recently
mentioned ELK embedded Scheme.

The main purpose is to combine the command and programming languages of the
environment into a single system.  That is, the shell language would not
only be similar to the programming language, it would _be_ the programming
language.

So far, I have found several references to similar projects, and I would
like to find further references, as well as any comments about the project
or the language that anyone might have.

The most promising reference that I have is

	_fsh - A Functional UNIX Command Interpreter_, 
	by Chris S. McDonald
	Univ. of Western Australia

It appeared in Software: Practice and Experience, 17 (10) 685-700 (1987).
If anyone knows more about this project, or has used a similar shell, I
would greatly appreciate hearing from you.

Thanks,

-- 
John Lacey                      |     cornell!batcomputer!lacey
lacey@tcgould.tn.cornell.edu    |     lacey@crnlthry.bitnet

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

End of Scheme Digest
********************

∂30-Jul-89  1023	@mc.lcs.mit.edu,@life.ai.mit.edu:jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk 	Re: INF/SUP/MIN/MAX  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Jul 89  10:23:25 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA18884; Sun, 30 Jul 89 13:09:48 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19972;
          30 Jul 89 12:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 30 Jul 89 12:53:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa19892;
          30 Jul 89 12:48 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA18799; Sun, 30 Jul 89 12:48:52 EDT
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Sun, 30 Jul 89 12:44:57 edt
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK   via Janet with NIFTP
           id aa00343; 30 Jul 89 17:34 BST
Date: Sun, 30 Jul 89 17:36:25 BST
Message-Id: <11536.8907301636@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: Re: INF/SUP/MIN/MAX
To: Guy Steele <gls@think.com>, cph@zurich.ai.mit.edu
Cc: Alan@reagan.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com,
        RRRS-Authors@zurich.ai.mit.edu

From: Guy Steele <gls@think.com>
>    Date: Wed, 26 Jul 89 15:49:33 edt
>    From: cph@zurich.ai.mit.edu (Chris Hanson)
> 
>    [quotes Steele's arguments about Quux-head pennies, etc.]
>    I don't buy these arguments: many of them have to do with side
>    effects, and since when are there any side effects on numbers?  So
>    they don't apply.
> 
> Granted.  "Plus ca change, plus c'est la meme chose", as Sussman and I
> quoted in "The Art of the Interpreter".  The more things change, the more
> they remain the same; that is, the notion of object identity may be linked
> to the notion of side effect.  And yet, if numbers are not subject to
> side effects, in what sense can we say that 1 = 1, or that 1 /= 2 ?

I think this observation of numeric identity shows that identity can
be linked to side-effects, but also that identity doesn't require this
link.  Indeed, I don't find the argument that there's some sort of
implicit potential side-effect involved in asking 1 = 1 very
convincing.

> I think that when we say 1 = 1, we are temporarily entertaining the
> possibility that the two instances of "1" represent *different* things,
> precisely so that we may then make the assertion that they are the same
> after all.

When I say "Nixon is the author of Six Crises", do this mean I'm
temporarily entertaining the possibliity that someone else wrote it?
Well, perhaps I'm at least entertaining the possibility that the
person I'm speaking to thinks so.  But what if I say just "Nixon is
Nixon"?  It may seem that I must have some possibility in mind that I
am trying to deny.  But I don't think it's clear what this possibility
is unless I say something more.  For example, I might say: "The person
you call 'Nixon' is the same person I know as 'Nixon', the author of
Six Crises, etc., and not two different people as we had once
supposed."  But it's hard to see how there could be this kind of
confusion about "'1' as defined by Scheme".  Indeed, it seems to me
that once we agree about what "Nixon" refers to, we can say "Nixon is
Nixon" without necessarily entertaining any possibility that Nixon
isn't Nixon.

So I don't think it's straightforward to conclude that when we
say 1 = 1, etc.

> If one of the 1's were not 1 after all, then things would be
> different, including the truth of the equality.  This subjunctive
> hypothesis amounts to a side effect, for we are considering, hypothetically
> and however evanescently, a world altered from our own (whether by SETQ
> or by adding an entry to the head of an a-list).

But is every difference the result of a side-effect?  Perhaps we're
just entertaining the possibility that "=" doesn't mean what we
thought it meant or that tokens like "1" refer to something different
each time.

So, I'm not sure we can take the side-effect reasoning this far.
But then I think it makes sense to talk of object identity even
when side effects are not involved, so I'm still inclined to
agree with Guy's earlier arguments.

Perhaps it would be better to use the more general notion of
"operational equivalence", though I don't know what the results
would be.

>    Maybe the problem isn't the action of max or min, but eqv?  If we
>    considered equality as defined by = this question wouldn't come up.
>    Maybe eqv? is making too fine a distinction.
> 
> Indeed, and this is essentially the subject of the message I sent
> after this one (the one you replied to): maybe inexact numbers
> should not possess object identity.  Please take this seriously.
> (Maybe it's the wrong idea, but it's not a frivolous idea, I think.)

I agree that we should take this suggestion seriously.

∂01-Aug-89  1716	@mc.lcs.mit.edu:hieb@iuvax.cs.indiana.edu 	revisiting lambda*    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Aug 89  17:16:40 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16083; Tue, 1 Aug 89 20:07:48 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18025;
          1 Aug 89 18:46 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  1 Aug 89 17:38:27 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa14839;
          1 Aug 89 14:46 EDT
Received: by iuvax.cs.indiana.edu 
Date: Tue, 1 Aug 89 13:46:13 -0500
From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
To: rrrs-authors@mc.lcs.mit.edu
Subject: revisiting lambda*
Message-Id:  <8908011446.aa14839@mintaka.lcs.mit.edu>

I am of course pleased to see interest in lambda* among R*S readers.  At this
point lambda* has yet to see enough use---"proof of principle"---to justify its
inclusion in an established language, which is what R* Scheme has become.
However, the concepts behind it have great potential and I would like to see
them more widely experimented with.  At least part of it---the dispatch on
optional arguments---is already mature enough to warrant serious consideration
as a means for handling optional arguments in R* Scheme.

I think I should respond to the ongoing critique by Rozas to make sure
budding interest is not prematurely squashed!  Some interesting language design
isues which have broad applications to ongoing R*S work arise.

A summary of the relevant notes:

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

   From: Guillermo J. Rozas <jinx@hpesogg.hp.com> Tue Jul 25 19:39:34 1989

   Although I agree that there are interesting issues in lambda*, I think
   that lambda* mixes up too many concepts and imposes implementation
   restrictions that I'm not sure I like.

   I envision something more primitive, and completely different.  I
   think that using lists, vectors, or special values to collect and pass
   arbitrary numbers of arguments is spurious.  Specific data structures
   should be introduced by the user according to convenience or intent.
   The arbitrary arity mechanism in the language should not be based on
   arbitrary data aggragates at all, but on something more primitive, and
   procedures (I think) are a good choice.

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

   From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com> Fri Jul 28 13:44:50 1989

   I also feel quite strongly that the following three issues are
   separable.  Lambda* jumbles them up, and that is my main problem with it:
   
   1) Multiple values.
   2) Dispatch on variable arity.
   3) Acceptance of "unbounded" numbers of arguments.
   
   I think many people agree that the current "dot notation" and apply
   have some problems, but I don't think that replacing them with lambda*
   solves them.  The three issues above are (I think) independent, and
   should be solved by independent mechanisms.

   A second point is that I don't like special forms when procedures can
   do the job, and all the three issues above can be solved as
   efficiently by adding procedures as by adding special forms.
   Special forms are syntactic cuteness that people who so desire can add
   on top.  Real men don't use macros :-)

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

Clearly Rozas agrees with the primary premise of the lamda* paper, that "using
lists, vectors, or special values to collect and pass arbitrary numbers of
arguments is spurious.  Specific data structures should be introduced by the
user according to convenience or intent."  However, he seems to imply that
lambda* uses "special values" to pass arbitrary numbers of values.  In fact,
lambda* uses special VARIABLES to pass arbitrary numbers of values---variables
which refer to multiple values.  No new sort of data structure or value was
implied.

Of more general interest is Rozas' claim that lambda* "jumbles" independent
issues which would be better handled separately.  I found it notable that his
alternative approach was based on Scheme procedures in all their glory, which
"jumble" many language features which could be treated separately.  Consider
some of things achieved by procedures in Scheme:

   * Passing parameters.
   * Returning results.
   * Binding and assignment of variables.
   * Scoping of variables.
   * Capture of free variables (lexical scoping and indefinite extent).
   * Freezing of action (procedures are a form of "potential energy").
   * Passing varying numbers of parameters.
   * Access to primitive data structures (the magic of cons, car, etc).
   * Access to continuations (call/cc).
   * Converting lists to parameters (apply).
   * Converting parameters to lists (dot interface).

Yet it is certainly this "lambda jumble" that makes Scheme what it is.  I think
few Schemers would want to lose any of at least the first 6 of the above
properties of Scheme procedures.  The others are more debatable, but are
certainly useful in practice.

Although lambda* adds to the jumble, I think it is the best means to date for
handling procedures which accept variable numbers of arguments.  Perhaps
allowing procedures with variable numbers of arguments was our first mistake,
but we must make the best of it, which was the primary goal of lambda*.  The
further issue of lambda* and multiple return values is orthogonal, but once
multiple return values are added to a language it becomes necessary to
integrate them smoothly with existing features.  lambda* provides solid base
for adding multiple return values, but in no way depends upon their existence.	

Finally, I think there is little justification for "proceduralizing"
everything.  I for one am glad that I can write (if test then else) instead
of (ef test (lambda () then) (lambda () else)).  Sometimes procedures are an
appropriate way to introduce language features.  cons and call/c are examples
of such procedures.  But not always.  I like if and I don't think procedures
like SUPPLY-ARGUMENTS and MAKE-ARGUMENTS-COLLECTOR are an improvement to the
dot interface.  (I realize Rozas was not submitting them for serious
consideration, but they are the only examples of what a "procedural" solution
might look like.)

Bob


∂01-Aug-89  1731	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #172 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Aug 89  17:30:50 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16077; Tue, 1 Aug 89 20:04:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16823;
          1 Aug 89 17:39 EDT
Date: 1 AUG 89  17:10:53 EDT
From: Automatic Scheme Digestifier <Scheme-Request@mc.lcs.mit.edu>
Subject: Scheme Digest #172 
To: Scheme@mc.lcs.mit.edu
Reply-To: Scheme@mc.lcs.mit.edu
Message-Id:  <8908011739.aa16823@mintaka.lcs.mit.edu>

Scheme Digest #172                              1 AUG 89  17:10:53 EDT

Today's Topics:

        Scheme Digest #171

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

From: adams@daisy.cge.fr
Date: Mon, 31 Jul 89 09:39:42 +0200
Message-Id: <8907310739.AA06479@zephir.cge.fr>
Subject: Re:  Scheme Digest #171

I would be quite interested in your project to write a shell etc. based
on a functional framework.  I would also be interested in more info on 
FSH (I remember reading the Software: Pract. & Exp. paper when it came 
out).  Would you please keep me posted.  

Regards,
Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherches de la Compagnie
            Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE
            Tel. +33 (1) 64.49.11.54, adams@crcge1.cge.fr ["one", not "ell"]

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

End of Scheme Digest
********************

∂01-Aug-89  1806	@mc.lcs.mit.edu,@life.ai.mit.edu:hal@zurich.ai.mit.edu 	Take Two 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Aug 89  18:06:10 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16436; Tue, 1 Aug 89 20:57:07 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa18965;
          1 Aug 89 20:12 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  1 Aug 89 19:49:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa15430;
          1 Aug 89 15:44 EDT
Received: from zurich.ai.mit.edu ([18.43.0.179]) by life.ai.mit.edu (4.1/AI-4.10) id AA12829; Tue, 1 Aug 89 15:44:12 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 1 Aug 89 15:40:53 edt
Date: Tue, 1 Aug 89 15:40:53 edt
From: Hal Abelson <hal@zurich.ai.mit.edu>
Message-Id: <8908011940.AA10031@zurich.ai.mit.edu>
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Tue, 1 Aug 89 10:54:37 EDT <8908011454.AA01758@peanut.DEC.COM>
Subject: Take Two
Reply-To: hal@zurich.ai.mit.edu


I vote (c) -- selector semantics.


∂01-Aug-89  1810	@mc.lcs.mit.edu,@life.ai.mit.edu:jar@sid.stanford.edu 	Take Two  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 1 Aug 89  18:09:53 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA16449; Tue, 1 Aug 89 20:58:42 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa19094;
          1 Aug 89 20:26 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  1 Aug 89 19:53:42 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa18399;
          1 Aug 89 19:30 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA15705; Tue, 1 Aug 89 19:30:44 EDT
Received: from mojave.Stanford.EDU (mojave.stanford.edu) by zurich.ai.mit.edu; Tue, 1 Aug 89 19:26:58 edt
Received: from sid.Stanford.EDU by mojave.Stanford.EDU (5.59/inc-1.0)
	id AA00928; Tue, 1 Aug 89 16:27:13 PDT
Message-Id: <8908012327.AA00928@mojave.Stanford.EDU>
Received: by sid; Tue, 1 Aug 89 15:56:37 pdt
Date: Tue, 1 Aug 89 15:56:37 pdt
From: Jonathan Rees <jar@sid.stanford.edu>
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@zurich.ai.mit.edu, Scheme-Standard@wheaties.ai.mit.edu
In-Reply-To: jmiller@crl.dec.com's message of Tue, 1 Aug 89 10:54:37 EDT <8908011454.AA01758@peanut.DEC.COM>
Subject: Take Two

   Date: Tue, 1 Aug 89 10:54:37 EDT
   From: jmiller@crl.dec.com

   P.S. -- It's long past time that things got submitted to the librarian
   (jar@zurich.ai.mit.edu?).  I plan to kick the ball off shortly by
   taking code from MIT Scheme that is portable and submitting that.  Can
   others do likewise?

   I'd particularly like to see a fully portable string->number that
   "blows up" only when it hits an implementation restriction -- i.e. one
   that will reliably produce an exact integer 3 when given "#e6/2" even
   in an implementation without ratnums.....I'm not even fully convinced
   that this can be done correctly without assumptions about underlying
   representations.

The librarian can be reached, as always, as
scheme-librarian@zurich.ai.mit.edu. 

The librarian will not be active until some time after August 20.  At
that time he intends to become more active, and it is hoped that the
library wil grow in size and popularity.

∂02-Aug-89  0359	ramsdell@linus.mitre.org 	Re: Take Two  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Aug 89  03:59:29 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA20603; Wed, 2 Aug 89 06:46:57 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA08488; Wed, 2 Aug 89 06:42:19 EDT
Posted-Date: Wed, 02 Aug 89 06:42:16 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA07091; Wed, 2 Aug 89 06:42:17 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908021042.AA07091@huxley.mitre.org>
To: JMiller@crl.enet.dec.com
Cc: rrrs-authors@life.ai.mit.edu
Subject: Re: Take Two 
In-Reply-To: Your message of Tue, 01 Aug 89 10:54:37 -0400.
             <8908011454.AA01758@peanut.DEC.COM> 
Date: Wed, 02 Aug 89 06:42:16 EDT


I vote (a) -- Status quo.

∂02-Aug-89  1357	@mc.lcs.mit.edu:dyb@iuvax.cs.indiana.edu 	Re:  Take Two
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 2 Aug 89  13:56:54 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA27429; Wed, 2 Aug 89 16:41:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01969;
          2 Aug 89 15:56 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  2 Aug 89 15:25:55 EDT
Received: from IUVAX.CS.INDIANA.EDU by mintaka.lcs.mit.edu id aa20924;
          1 Aug 89 23:30 EDT
Received: by iuvax.cs.indiana.edu 
Date: Tue, 1 Aug 89 22:30:19 -0500
From: "R. Kent Dybvig" <dyb@iuvax.cs.indiana.edu>
To: JMiller@crl.enet.dec.com
Subject: Re:  Take Two
Cc: rrrs-authors@mc.lcs.mit.edu
Message-Id:  <8908012330.aa20924@mintaka.lcs.mit.edu>

I vote for option (c), selector semantics.  I think of min and max as
conditional expressions, which I guess makes me a C weenie.

∂06-Aug-89  1352	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	revisiting lambda*   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 6 Aug 89  13:50:40 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA14805; Sun, 6 Aug 89 16:30:20 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07367;
          6 Aug 89 16:27 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  6 Aug 89 16:27:59 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07354;
          6 Aug 89 16:25 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA14710; Sun, 6 Aug 89 16:08:12 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Sun, 6 Aug 89 16:04:01 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA21463; Sun, 6 Aug 89 13:07:05 pdt
Message-Id: <8908062007.AA21463@sde.hp.com>
Received: by hpesogg; Sun, 6 Aug 89 13:06:26 pdt
Date: Sun, 6 Aug 89 13:06:26 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: hieb@iuvax.cs.indiana.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Robert Hieb's message of Tue, 1 Aug 89 13:46:13 -0500 <8908011446.aa14839@mintaka.lcs.mit.edu>
Subject: revisiting lambda*
Reply-To: jinx%hpesogg@sde.hp.com

[
 Sorry if you receive multiple copies, but I've had some problems
 mailing stuff to rrrs-authors recently.
]

    However, he seems to imply that
    lambda* uses "special values" to pass arbitrary numbers of values.  In fact,
    lambda* uses special VARIABLES to pass arbitrary numbers of values---variables
    which refer to multiple values.  No new sort of data structure or value was
    implied.

There are two different ways to look at it.  You are "blaming" the
variables, rather than the values that they hold.  Ultimately you are
adding a new kind of object, or a new kind of variable, that I (and
many other people) consider unnecessary and distasteful.  I also
suspect that if you try to write the semantics for it, you will find
that it is easier to think about the value being "funny", rather than
the variable.

    Of more general interest is Rozas' claim that lambda* "jumbles" independent
    issues which would be better handled separately.  I found it notable that his
    alternative approach was based on Scheme procedures in all their glory, which
    "jumble" many language features which could be treated separately.  Consider
    some of things achieved by procedures in Scheme:

This argument is very strange.  You are not trying to defend lambda*,
you are instead saying something like
"Since there is already something broken in the language, it is not
surprising that we want something even more broken, and furthermore,
how come you don't argue about the broken things already there?".
Perhaps you are trying to discredit me, rather than my argument?  I
hope not.

I agree that lambda mixes up certain concepts.  Both lambda* and what
I hope to see fix some of these problems.  You are assuming that I'm
just being facetious by arguing against lambda* while you don't hear
me arguing against lambda.  The reason I argue against lambda* is
because it is not yet in the language.  Perhaps if lambda were being
considered for addition, I would be arguing against it too.  That has
not been feasible since 1975.  Another reason why I (and others)
haven't tried to replace lambda is that we don't have anything better,
although perhaps John Lamping's thesis points in the right direction.

After examining your list of capabilities for lambda/procedures, I
detect a basic confusion in your argument (or your interpretation of
my argument):

You must distinguish between the capabilities of procedures, and the
capabilities of the primitive forms (and procedures) that create
procedures.  You don't do that.

I don't object to procedures being able to do everything.  Scheme is
an applicative language, and I don't want to change that.  I do object
to making each individual primitive form that creates procedures be
able to do everything.  I don't want LAMBDA to become Scheme's kitchen
sink in the same way that LOOP is CommonLisp's kitchen sink (or one of
its many kitchen sinks).

Let's examine your list element by element and see whether your
objections are objections against lambda or against procedures in
general.  Again, I have no objections to procedures being able to do
everything.  I have objections against individual special forms (be it
lambda or lambda*) being able to do everything.

   * Passing parameters.

This has nothing to do with lambda, or ultimately even with
procedures.  Procedure applications (ie. combinations) pass parameters.
Procedures RECEIVE parameters.  More on this below.

   * Returning results.

This has nothing to do with either lambda or procedures.  Expressions
"return" (or have) values.  Therefore lambda expressions have values,
combinations have values, and procedure bodies have values.
Perhaps you are confusing the concept of procedures or lambda versus
their implementation with standard (procedure based) compiler technology.

   * Binding and assignment of variables.

Lambda definitely binds variables, but I hardly see how it assigns
variables.  Assignment is handled by set!  Procedures don't bind
anything.  They allocate storage for variables, and potentially mutate
the storage of preallocated variables.

   * Scoping of variables.

Definitely, but this is really the same as the point about binding,
since when you have the ability to bind, you must specify how
conflicts are resolved.  You are not saying anything new.

   * Capture of free variables (lexical scoping and indefinite extent).

Again, this is the same point.

   * Freezing of action (procedures are a form of "potential energy").

Yes.  But this is a property of procedures, not (inherently) of lambda.

   * Passing varying numbers of parameters.

I hope you mean receiving.  Otherwise you are talking about
combinations or APPLY.  If you are talking about receiving, your point
is ambiguous:

- Do you mean that procedures can accept more than one argument, ie. are
you talking about currying?

I certainly don't advocate for a curried language.  I don't see any
advantage (pragmatic or aesthetic) to that.

- Do you mean that a given procedure created by lambda can accept an
unbounded number of arguments, ie. dotted parameter lists?

This point is mentioned below.  At any rate, individual procedures
should certainly be able to receive any number of arguments, but it
doesn't follow that the same primitive must be used to construct all
of these procedures.

   * Access to primitive data structures (the magic of cons, car, etc).

This has nothing to do with lambda.

   * Access to continuations (call/cc).

Again, this has nothing to do with lambda.  As an aside, I think that
the fact that "primitive" continuations are invokable is a mistake,
but it is to late to fight this battle.

   * Converting lists to parameters (apply).

This has nothing to do with lambda.  I still think that it is funny,
and that is what prompted my messages.  Perhaps you've forgotten that.

   * Converting parameters to lists (dot interface).

Both you and I are trying to fix this.  Don't accuse me of defending
it.

    Yet it is certainly this "lambda jumble" that makes Scheme what it is.  I think
    few Schemers would want to lose any of at least the first 6 of the above
    properties of Scheme procedures.  The others are more debatable, but are
    certainly useful in practice.

As I stated before, you are confusing the power of procedures with the
capabilities of lambda.  The power of procedures is what makes Scheme
what it is, not lambda per se!

    Although lambda* adds to the jumble, I think it is the best means to date for
    handling procedures which accept variable numbers of arguments.  Perhaps
    allowing procedures with variable numbers of arguments was our first mistake,
    but we must make the best of it, which was the primary goal of lambda*.  The
    further issue of lambda* and multiple return values is orthogonal, but once
    multiple return values are added to a language it becomes necessary to
    integrate them smoothly with existing features.  lambda* provides solid base
    for adding multiple return values, but in no way depends upon their existence.	

I think that lambda* was valuable in pointing out a different way of
handling dispatch on number of arguments received.  There are problems
with the lambda* model, just as there are problems with the #!optional
(or &optional) model.  I think that the rest argument feature is much
more questionable (and most people agreed at Snowbird), and
furthermore, I believe strongly that multiple values should be handled
by an independent mechanism.  I'm not saying that lambda* is a
"waste".  I'm just saying that it is no panacea, and I would like to
isolate what I consider to be its good features from what I consider
to be its bad features.

    Finally, I think there is little justification for "proceduralizing"
    everything.  I for one am glad that I can write (if test then else) instead
    of (ef test (lambda () then) (lambda () else)).  Sometimes procedures are an
    appropriate way to introduce language features.  cons and call/c are examples
    of such procedures.  But not always.  I like if and I don't think procedures
    like SUPPLY-ARGUMENTS and MAKE-ARGUMENTS-COLLECTOR are an improvement to the
    dot interface.  (I realize Rozas was not submitting them for serious
    consideration, but they are the only examples of what a "procedural" solution
    might look like.)

I hope you mean (test (lambda () then) (lambda () else)).  Besides
isn't this what IF is ultimately? :-)

This is clearly a matter of aesthetics, and yours and mine differ (not
surprising given our different backgrounds).  My PERSONAL preference
is for new capabilities to be added in the form of procedures, not in
the form of special forms.  Assuming that we ultimately agree on
macros (as impossible as that may seem right now), everyone can build
their own cutsey syntax on top of the "raw capability".  I don't
advocate for anyone to necessarily use the primitive capabilities
directly, but I would like them to capture the essence of the concept,
and then people can abstract them away in any way they want.

The reason why I believe that capabilities should be added as
procedures, rather than syntax, is that I view syntax as a shorthand,
whose only purpose is legibility within context of the individual
program I am dealing with.  Since the legibility needs of individual
programs and programmers vary, I don't like to impose any particular
shorthand or syntactic model on anyone.  I believe that the
capabilities should be available by other means, and individual
programmers should map into them in whichever way they find
convenient at any point in time.







∂07-Aug-89  1734	@mc.lcs.mit.edu,@LIFE.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	LIST?   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89  17:33:44 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB00489; Mon, 7 Aug 89 20:22:53 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21088;
          7 Aug 89 20:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  7 Aug 89 20:03:25 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21063;
          7 Aug 89 20:01 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00247; Mon, 7 Aug 89 20:01:19 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Mon, 7 Aug 89 19:57:57 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
	(5.59++/IDA-1.2.8) id AA04273; Mon, 7 Aug 89 17:01:01 PDT
Received: by spencer.cs.uoregon.edu; Mon, 7 Aug 89 17:01:02 PDT
Date: Mon, 7 Aug 89 17:01:02 PDT
From: will@cs.uoregon.edu
Message-Id: <8908080001.AA04985@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: LIST?


Add LIST?.

Jim Miller:
    For virtually every data type mentioned in a procedure header line in
    R4RS there is either an existing predicate in the language (string?
    for string, vector? for vector, rational? for q_{n}, etc.) or a
    trivial piece of code (like (lambda (k) (and (integer? k) (exact? k)
    (positive? k))) for k_{n}).  Not so for (proper) lists referred to as
    "list" in the header line.  It was our intention to have P1178 make
    this connection explicit, whether or not R4RS chooses to do so, and
    the missing predicate for proper lists causes a problem.

    We had not planned to ask RNRS to change to add such a test.  But
    someone else has, so I'd like to support the addition of the predicate
    LIST? that tests for proper lists.  I don't mind if you call it
    PROPER-LIST?, but I prefer the other name, especially since the
    language of the report is very clear about the definition of a list,
    and it excludes both cdr-circularity and dotted tails.  Another
    predicate might be of interest to RnRS (NOT-TAIL-CIRCULAR?  or some
    such) but you won't hear me agitating to have that added to the IEEE
    proposal.

Several have spoken in favor of this procedure, and none have opposed it.
There has been some debate about the name; a minority prefers PROPER-LIST?
to LIST?.  The minority consists of two people, since I have changed my
mind and now prefer LIST?.  To summarize that debate, LIST? is more
consistent with the terminology used in Scheme but PROPER-LIST? is more
consistent with the terminology used in Common Lisp.

I will add LIST? to the R3.99RS and R4RS as an essential procedure provided
the authors will join me in a rousing chorus of "YES, YES!".  Proposed
wording:

    (LIST? obj)                                      essential procedure

    List? returns #t if obj is a list of finite length, and otherwise
    returns #f.

        (list '(a b c))                      ==>  #t
        (list '())                           ==>  #t
        (list '(a . b))                      ==>  #f
        (let ((x (list 'a)))
          (set-cdr! x x)
          (list? x))                         ==>  #f

Peace, Will

∂07-Aug-89  1756	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	sequential order of evaluation   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89  17:56:20 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00704; Mon, 7 Aug 89 20:41:51 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21145;
          7 Aug 89 20:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  7 Aug 89 20:09:34 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21067;
          7 Aug 89 20:01 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00255; Mon, 7 Aug 89 20:01:49 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Mon, 7 Aug 89 19:58:28 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
	(5.59++/IDA-1.2.8) id AA04280; Mon, 7 Aug 89 17:01:42 PDT
Received: by spencer.cs.uoregon.edu; Mon, 7 Aug 89 17:01:45 PDT
Date: Mon, 7 Aug 89 17:01:45 PDT
From: will@cs.uoregon.edu
Message-Id: <8908080001.AA04992@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: sequential order of evaluation


Indeterminate order of evaluation of expressions in a procedure call.

Bill Rozas:
    Any sequential order is the intention.  Interleaving should not be
    allowed because there are no locking primitives to serialize side
    effects.

Chris Hanson:
    Certainly the implementation is free to use any SEQUENTIAL order.
    It has never been clear to me whether the specification permits
    simultaneous evaluation of two different arguments.

Mike Shaff:
    This being the case (and presuming this is the generally agreed thinking)
    shouldn't this choice be made more explicit.  I think the absence of said
    locking primitives (at the current time) is an issue whose ramifications
    should be noted.

The choice is explicit in the rather informal formal semantics, which says
the expressions must be evaluated sequentially in some permuted order.
Thus it is ok to evaluate

    ((f (car x)) (g (car x)))

as though it were

    (let* ((t1 (f (car x)))
           (t2 (g (car x))))
      (t1 t2))
or
    (let* ((t2 (g (car x)))
           (t1 (f (car x))))
      (t1 t2))

but it is not ok to evaluate it as though it were

    (let* ((t0 (car x))
           (t1 (f t0))
           (t2 (g t0)))
      (t1 t2))
or
    (let* ((t0 (car x))
           (t2 (g t0))
           (t1 (f t0)))
      (t1 t2)).

The problem with saying that the evaluation must be sequential is that the
word "sequential" isn't very well-defined.  Some people think only the first
of the four is sequential, and some think all four are sequential.

How do the authors feel about adding the following note to section 4.1.3?

    Note:  Although the precise order of evaluation is unspecified, the
    expressions must be evaluated without interleaving.  Interleaving is
    not allowed because Scheme provides no facilities for serializing
    concurrent side effects.

∂07-Aug-89  1949	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	R3.99RS issues (long message)    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89  19:49:14 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01437; Mon, 7 Aug 89 22:30:28 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21149;
          7 Aug 89 20:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  7 Aug 89 20:09:53 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21076;
          7 Aug 89 20:03 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00266; Mon, 7 Aug 89 20:03:03 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Mon, 7 Aug 89 19:59:41 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
	(5.59++/IDA-1.2.8) id AA04281; Mon, 7 Aug 89 17:02:51 PDT
Received: by spencer.cs.uoregon.edu; Mon, 7 Aug 89 17:02:53 PDT
Date: Mon, 7 Aug 89 17:02:53 PDT
From: will@cs.uoregon.edu
Message-Id: <8908080002.AA05003@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: R3.99RS issues (long message)

No less than 12 issues, by my count, have been debated here since I lost
contact with the net.  I'll be responding to some of them separately.  For
the others, this message summarizes my perception of the consensus or lack
thereof for purposes of the R4RS.

William Clinger

--------------------------------------------------------------------------------
Timing of the R3.99RS, R4RS.

Mike Shaff:
    I am definitely in favor of moving forward on issues and getting the
    report out to the public, however the latest version of the report that
    I have (via zurich) still seems to have some areas that I thought were to
    be part of the document (per L&FP such things as macros, name
    regularization, etc were to be 'rubber stamped' by the group).  Is there
    to be another beta release *before* the submission to P1178?  If not, what
    happened to those and other favorites?

There will not be a beta release before submitting R3.99RS to P1178 because
there isn't time if P1178 is to circulate a draft IEEE standard before its
next meeting.  Matters for which we have not reached consensus will have
to wait for the R5RS.  There were only two things that the Snowbird meeting
"rubber stamped" in advance: clarification of the numeric procedures, and
macros.  On the matter of regularization, it was agreed that Morry Katz would
develop a proposal for consideration over the net, but the Snowbird meeting
did not commit itself to accepting such a proposal.

With regard to the numeric procedures, we appear to have reached consensus
on everything except MIN and MAX; at worst I can leave MIN and MAX out of
the R4RS, but I expect we will do better than that.  The macro committee
has thus far failed to agree on a proposal.  The plan is for the R4RS (but
not the R3.99RS) will have an appendix that describes (at least) two
incompatible macro proposals and the issues that have prevented them from
being resolved; this should be the only substantial difference between the
R3.99RS and the R4RS.  We do not have consensus on wholesale regularization,
but some regularization is occurring anyway (see below).

Pavel Curtis:
    I'd rather that we did not cut off debate on R4RS at the end of this
    month.  It seems to me that there are several reasonably important
    issues currently on the table that could make it into R4RS in the very
    near future (e.g., uniform definition semantics, fluid binding, and
    regularization of procedures).  I would hate to see R4RS come out so
    little changed from the previous report; in a sense, what's the point?

The point is that there should be a version of the RnRS that corresponds to
the P1178 draft.  The P1178 committee has committed itself to follow the RnRS,
not to lead it.  The changes that Pavel mentions are upwardly compatible with
what will be in the R4RS, so there's no reason to delay the R4RS on their
account.

--------------------------------------------------------------------------------
Flushing ELSE.

Morry Katz:
    ....I therefore advocate that we remove ELSE from the list of syntactic
    keywords and replace ELSE by #T in the COND examples in RNRS....

This proposal has not attracted support, and is about to die for lack of a
second.

--------------------------------------------------------------------------------
Fluid variables or cells.

There seems to be agreement in principle but little consensus on details.
I think this is a good topic for R5RS but not for R4RS.

--------------------------------------------------------------------------------
FORCE and DELAY.

Mike Shaff:
    Force and delay are currently in totally separate sections of R3.95RS
    which can lead readers to hours of fun and enjoyment.  Perhaps the
    Delayed Evaluation section (4.2.5) can be made a subsection of Control
    Features (6.9) and expanded to include force.

Sections 4.2.5 and 6.9 refer to each other explicitly.  I can see how this
might cause a minute or two of page-flipping, but I think only a very
creative reader could derive hours of fun and enjoyment from it.

--------------------------------------------------------------------------------
Add CONTINUATION?

This issue has been withdrawn.  In the message withdrawing this issue, Morry
Katz said:

    I believe that PROCEDURE? is a serious misnomer.  The function should
    really be called APPLICABLE?.

All applicable objects described in R4RS are procedures, and vice versa, so
PROCEDURE? is no more a misnomer than APPLICABLE?.  The name has been
debated twice in the last five years, and PROCEDURE? has won out both times.

--------------------------------------------------------------------------------
EQV? on numbers.

Jim Miller:
    I thought that 
       (and (number? x) (number? y) (= x y)) implied
       (eqv? x y).
    By my reading of R3.95RS this isn't true (consider x=3 and y=3.0),
    although I believe
       (and (number? x) (number? y) (eqv? x y)) implies
       (= x y)
    Have I got this right?

Yes.  In fact, my reading is that
    (and (number? x) (number? y) (eqv? x y))
is equivalent to
    (and (number? x) (number? y) (eqv? (exact? x) (exact? y)) (= x y)).

Pavel Curtis:
    I would be unhappy with any statement that distinguished between the
    behavior of, for example, the car cell of a pair and the contents of a
    lexical variable...

The discussion at the recent P1178 meeting addressed both, though this
may not have been reflected by the minutes.

In my separate message on MAX and MIN, I argue that the requirement that
EQV?-ness be preserved should not be strengthened to a requirement that
EQ?-ness be preserved.  I will expand that argument if people want me to.

--------------------------------------------------------------------------------
Add bitwise logical operation on exact integers (bitvectors, whatever).

This sounds like an excellent proposal for the yellow pages, and later for
inclusion in R5RS.

--------------------------------------------------------------------------------
Require left-to-right evaluation of internal definitions.

Pavel Curtis:
    Given your retraction of this objection and John's and my unanswered
    refutations of your first one, may we assume that you now support the
    proposal to unify definition semantics?  If not, could you say more?

I remember that you sent some messages denying my first objection, but I
don't recall any refutations of it.

I still prefer that the order of evaluation of internal definitions be left
unspecified, for the same reason that the order of evaluation of arguments
in a procedure call is unspecified.  In both cases the context is such that
the order of evaluation ordinarily would not matter even if it were
specified.  By leaving the order of evaluation unspecified, we save the
reader of a correct program from having always to consider the remote
possibility that the order is significant.

The obvious "disadvantage" of leaving the order unspecified is that people
who want to use side effects cannot use a tacit sequencing implicit to the
internal definitions or arguments, but must use an explicit BEGIN instead.
I maintain that this is actually the great advantage of leaving the order
unspecified.

The real disadvantage of leaving the order of evaluation unspecified is that
it becomes easier to write incorrect code.  In my opinion this has not been
an important problem.

An aesthetic disadvantage in the case of internal definitions is that the
order of evaluation *is* specified for top-level definitions.  I maintain
that this inconsistency results from our current compromise with file-based
program structures and separate compilation---matters that aren't even
mentioned in the Report, but influence it regardless.  I too would like to
remove this inconsistency, but would prefer to fix it by removing the
implicit sequencing of top-level definitions.  I hope this will be possible
in a future module facility or other extension for programming-in-the-large.

For all that, I repeat my earlier statement that I am not strongly opposed
to requiring that internal definitions be evaluated from left to right.
I am merely opposed.  I will certainly implement this change if the authors
want me to.

--------------------------------------------------------------------------------
Why aren't more procedures required to return exact integers more often?

Alan Bawden:
    Actually, I'd be more interested to know what -isn't- on the list.  I'll
    bet SQRT isn't there because people think that SQRT of an exact 4 should be
    allowed to return something inexact rather than an exact 2.  Am I right?
    I suspect that if I understood more about this "list" I would argue that
    -all- numeric functions belonged on it (including SQRT).

Bill Rozas:
    Correct.  I suppose it's a matter of practicality -- nobody wanted to
    commit to implement `sqrt' to handle this case specially, presumably
    because such behavior isn't too interesting.  To take it further, I
    suppose it wouldn't hurt to add the transcendental functions to the
    list....The only good reason why `/' and `sqrt' should not be in the
    list is efficiency and implementation complexity.  Maybe that's not
    good enough....

    I suspect that there's no argument for keeping the transcendental
    functions out of the list since my intuition tells me that there is no
    case where integer arguments provide an integer result; if there is
    such a case, it's probably pretty obscure...A similar argument holds
    for `make-polar' and `angle'....

Here's the cases I could think of that would require special treatment:
(exp 0), (log 1), (sin 0), (cos 0), (tan 0), (asin 0), (acos 1), (atan 0),
(atan 0 n), (make-rectangular n 0), (make-polar n 0), (angle n),
(magnitude n); where n is an exact but not necessarily non-negative
integer.

    Summary: the only procedures that seem to matter are `/' and `sqrt',
    and the argument in favor of excluding them is pragmatic.

Scheme would be simpler if we could just say that with the exception
of EXACT->INEXACT, all procedures in section 6.5 that return a numeric
result will return an exact integer result provided all their arguments
are exact integers and the mathematically expected result is representable
as an exact integer within the implementation.

I think the argument in favor of simplicity outweighs the pragmatic
argument, partly because the pragmatic argument is weak.  It isn't very
hard to handle the special cases, and it's unlikely that SQRT needs to be
particularly fast on exact integers.  I propose that we make this change
in R5RS.

Peace, Will

∂07-Aug-89  2002	@mc.lcs.mit.edu,@LIFE.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	MIN and MAX (long message)  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89  20:02:10 PDT
Received: from MINTAKA.LCS.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AB01536; Mon, 7 Aug 89 22:47:57 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21252;
          7 Aug 89 20:16 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  7 Aug 89 20:16:23 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21158;
          7 Aug 89 20:09 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00343; Mon, 7 Aug 89 20:09:54 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Mon, 7 Aug 89 20:06:31 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
	(5.59++/IDA-1.2.8) id AA26857; Mon, 7 Aug 89 16:02:43 PDT
Received: by spencer.cs.uoregon.edu; Mon, 7 Aug 89 16:02:42 PDT
Date: Mon, 7 Aug 89 16:02:42 PDT
From: will@cs.uoregon.edu
Message-Id: <8908072302.AA04327@spencer.cs.uoregon.edu>
To: rrrs-authors@zurich.ai.mit.edu
Subject: MIN and MAX (long message)

I agree with almost everything Alan Bawden and Mitch Wand have said
concerning MIN and MAX, so I will try to avoid repeating their
arguments in this note.  The purpose of this note is to argue:

  *  Although the concept of exactness is a new and useful idea, it
     is not a radical new idea.  Programmers who naively assume that
     inexact numbers are just another name for floating point numbers
     are unlikely to get into any trouble they wouldn't already be in
     with floating point.  Furthermore the concept of exactness does
     not entail any loss of efficiency.

  *  The controversy concerning the semantics of MIN and MAX has nothing
     to do with the fact that Scheme does not require inexact numbers to
     be represented in floating point format.  It has to do with the
     relationship between exact and inexact numbers (by whatever names
     you want to call them) in a generic arithmetic system.

  *  No major programming language adopts either semantics that we are
     considering for MIN and MAX.  In particular, I think Guy was pulling
     our collective leg when he claimed that MIN and MAX act as
     conditionals in C.

  *  Certain statements that have been made in this discussion deserve
     correction, qualification, or elaboration.

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

Alan Bawden:
    I've never heard users asking for the notion of exactness/inexactness at
    all.  Ask them what they want, and they will probably tell you that they
    want IEEE floating point.  As I have said before, I think it would be 100%
    reasonable for Scheme to do what every other language does, and adopt some
    reasonable set of rules for the behavior of floating point.  Unfortunately,
    Scheme decided to go in a different direction....

You might be shocked by how little "every other language" has to say about
what floating point is and how it behaves.  A lot of machines don't support
IEEE floating point very well, so language designers have to be pretty vague
about floating point if they want their language to run well on popular
hardware.

At Brandeis we asked ourselves what was distinctive about floating point,
and why we needed it.  The answer was that floating point was inexact, and
we needed it for efficient (though approximate) calculations with real
numbers.  Instead of writing a vague description of how floating point
arithmetic behaves in Scheme, we wrote a vague description of how
inexact arithmetic behaves.

Although the Scheme report explicitly recognizes that non-floating-point
implementations of inexact arithmetic are possible, I suspect that most
language standards are vague enough that non-floating-point implementations
of their "real" or "float" types would be just as legal as in Scheme.  So
I don't think we've done anything radical by allowing non-floating-point
implementations of inexact arithmetic.

Furthermore I don't think many programmers would notice the difference if
a good non-floating-point implementation of inexact numbers were used.
People doing serious calculations would notice and gripe, but they might
gripe about IEEE arithmetic as well (because, for example, its roundoff
characteristics are different from those of the Cray their programs have
been written for).  If people doing serious calculations have technical
complaints about the non-floating-point implementation, well, maybe the
implementors should listen to them.  (Now that would be radical!)

Kent Pitman:
    ....If Scheme numbers are to persist
    in their current form, I would like to be able to speak as confidently
    about their demonstrated usefulness, and I don't now feel that I have
    the ammunition to do so.

Here are four benefits, arranged in decreasing order of importance by
my estimate.  The basic argument in favor of the R3.95RS semantics for
MIN and MAX is that any other semantics would weaken the most important
benefit by adding yet another hypothesis.

  *  If a calculation yields an exact result, and the calculation did
     not involve any predicates on inexact numbers, and did not call
     INEXACT->EXACT, then the result is correct.
  *  The rules for calculating with exact numbers are such that the
     extra hypotheses in the sentence above can often be checked
     statically.
  *  The integers are a subset of the rationals, which are a subset of
     the reals, which are a subset of the complex numbers.
  *  The ODD?, EVEN?, QUOTIENT, REMAINDER, MODULO, GCD, LCM, NUMERATOR,
     and DENOMINATOR procedures accept inexact as well as exact
     arguments.

Kent Pitman:
    ....It would be one thing if it -also-
    provided floats, so that people could get real work done while they
    waited for the other stuff to get field tested, but my own cynical
    viewpoint is that--for quite a while yet, anyway-- implementations are
    likely to be either correct or efficient, but not both.  At least with
    floats the fact that games are being played is above board, and you
    don't have to fail to conform in order to use standard hardware.

Since floating point is not only a permitted representation for inexact
numbers but is in fact the typical representation, I don't understand
this argument at all.  Arithmetic in Scheme is as efficient as generic
arithmetic in, say, Common Lisp.

I agree that it will take a year or two for people to get the bugs out
of their systems.  In MacScheme 2.02, for example, the comparison
operators aren't transitive yet, the NUMBER->STRING, STRING->NUMBER, and
EXACT->INEXACT procedures aren't always good to the last bit, and the
MIN and MAX procedures still act as selectors.  These are the only
arithmetic bugs I know of, six months after product release.  None have
to do with exactness or inexactness, since they would remain bugs even
if Scheme were to require floats instead of inexact numbers.

Guy Steele Jr:
    ...every C weenie has the formula
      #define max(x,y) ((x) > (y)) ? (x) : (y)
    engraved in his little weenie brain.  See?  MAX really is a conditional.

I'm not much of a C weenie, and I don't have a description of the
proposed (or actual?) ANSI standard, but I think I know enough C to
suspect that Guy didn't mean for us Scheme weenies to take this seriously.
When examined more closely, Guy's example shows that C weenies think more
like me than like Guy.  (This doesn't surprise me, unfortunately.)

C is a statically typed language, with very little polymorphism, that
regards ints and floats as different types.  (I'm going to speak as
though all the different integer types were collapsed into one type, and
all the different float types into one type.)  The two alternatives of
a conditional expression must have the same type, or else be convertible
to the same type using C's conversion rules.  If you define max as Guy
suggested and then write max(2.5, 1000) as an expression, then the result
of that expression will be a float (1000.0), not an int.

If you write max(2.5, 1000) in a context that expects an int, then the
floating point 1000.0 will be converted back into an int (1000).  (It
isn't wise to regard that conversion as part of the expression's
semantics, because you would then have to believe that max(2, 1000.5)
also evaluates to an int.)  Hence max(2.5, 1000) in an int context is
really the equivalent of (INEXACT->EXACT (TRUNCATE (MAX 2.5 1000))) in
Scheme.

So if MAX really is a conditional in C, then (MAX 2.5 1000) ==> 1000.0
is consistent with MAX being a conditional.  It seems that Guy's example
actually supports the R3.95RS semantics he was arguing against.

To my knowledge, no major programming language defines MAX so that
MAX of a floating point 2.5 and an exact integer 1000 is guaranteed
to be an (exact) integer.  Common Lisp, which explicitly leaves it up
to the implementation, comes the closest.  [My original posting to the
effect that Common Lisp requires (MAX 2.5 1000) to be 1000.0 was
incorrect, as Guy pointed out.]

With most C compilers, it is true that the result of max(x, y) will
always be equal to one of the arguments.  This essentially results
from the poverty of C's representations.  The R3.95RS semantics of
MAX allows this property to be achieved in Scheme the same way it
is achieved by C:

  *  Don't implement exact arithmetic for any types except integers.
  *  Limit the range of exact integers to +-9007199254740992.
     (Any smaller range will work too.)
  *  Represent inexact reals as IEEE 64-bit floats.

Hence one could say that the R3.95RS semantics, like Common Lisp, allows
(but does not require) MAX to return a result that is not equal to any
of its arguments---but it would be misleading.  [Apologies to RMN.]

Guy Steele Jr:
    (1) I see no reason why the rules of inexact contagion should
    apply to MAX.  As Pavel has observed, >= does not return an
    inexact boolean.  (If >= were to be three-valued (yes/no/maybe)
    then it would be more consistent.)

MIN and MAX don't return booleans.  With the R3.95RS semantics, my
faith in an exact result is threatened only by predicates and by
INEXACT->EXACT.  I'm not happy about having to remember those
exceptions, but I'd be even less happy if I had to remember them as
"predicates, INEXACT->EXACT, MIN, and MAX".  The predicates and
INEXACT->EXACT are pretty easy to remember because they seem so
inevitable, but MIN and MAX would look like they made the list
because someone hadn't been thinking very clearly.

I'm not convinced by the argument that MIN and MAX are mere comparisons,
not computations, possibly because I know how much computation a mere
comparison is likely to take in Scheme when one argument is exact and
another inexact.


Alan Bawden:
    ....If the multiplication overflows the range of exact integers in
    some implementation and returns an inexact, then the division will
    return an inexact as well, and then VECTOR-REF will signal an error....

Guy Steele Jr:
    Depends on why I put the MIN in there.  If I put it in precisely to
    guard against indexing off the end of the vector when running in
    broken implementations that think 32 bits is enough to count anything
    interesting at all, then the program is doing its job, and MIN is
    exactly what I wanted.

VECTOR-REF isn't guaranteed to signal an error if its second argument is
inexact.  Section 1.3.2 says "Implementations may extend a procedure's
domain of definition to include such arguments".


Will Clinger:
    ...e.g. (MAX 1.4 #e1e100) ==> 9.999999999999998e99.

Bill Rozas:
    As far as I understand it (and GJS agrees with me), the example Will
    shows could only be correct in an implementation where 
    (>= 9.999999999999998e99 #e1e100) is true.  If it isn't, the
    implementation of MAX/SUP is in error.

Not as I understand it.  I intended for this example to illustrate
what happens in an implementation that uses IEEE 64-bit floating
point to represent inexact reals, but I goofed (because of a bug
in the least significant bit of MacScheme's implementation of
EXACT->INEXACT for large numbers).  A better example is

    (MAX 1.4 #e1e200) ==> 9.99999999999999969733e199

I think this example is correct in the implementation described, even
though (>= 9.99999999999999969733e199 #e1e200) is false.  The entire
specification of MAX and MIN is that they "return the maximum or minimum
of their arguments", but the implementation described will be unable to
meet this spec because it doesn't have enough precision to represent
10↑200 as an inexact number without loss of accuracy.  The implementation
has exactly the same problem with + and *, which are supposed to "return
the sum or product of their arguments" but can't in examples like
(+ 1.5 1e-30).  In such cases "it is the duty of each implementation
to make the result as close as practical to the mathematically
ideal result".  It happens that 9.99999999999999969733e199 is the
inexact number that is closest to 10↑200 in this implementation.
The next closest inexact number is 1.00000000000000013969e200,
which is apparently the result desired by Rozas and GJS:

    ...A good implementation would coerce to floating point
    rounding towards infinity (ie. add 1 at the least significant
    mantissa bit after truncating the bits) in order to return a
    value >= than all the inputs.

This isn't obvious, and I think it's untrue.  The property you
desire (that the result be greater than or equal to all inputs)
is in conflict with another nice property, namely that the result
of MAX be as close as possible to the mathematically ideal result.
Something has to give.

I think that requiring MAX to round up would be like requiring
(+ x y) to return a number greater than x whenever y is positive.
It sounds plausible at first, but would tend to make computations
less accurate.  I have to admit, given the difficulty of coming up
with any real-world examples where MAX returns a value that is not
equal to one of its arguments, that a difference in the least
significant bit in such cases would probably be of very little
consequence, and it might make someone's mother happy.


Jim Miller:
        (a) They are selectors from a set of numbers and thus there is
            a legitimate expectation that (memq (max <set>) <set>) ==>
            #t.  (Yes, I DO mean memq not memv.)

I think you should have meant MEMV, not MEMQ.  There is only one reason
why EQ? is in Scheme at all: it is an efficiency hack for performing an
EQV? comparison when one of the arguments is known to be of a type for
which EQ? coincides with EQV?.  Consider these facts:  The EQ? procedure
is nothing but a more implementation-dependent version of EQV?.  It is
perfectly legal for an implementation to make EQ? be exactly the same
procedure as EQV?.  It is also legal for EQ? to return #F whenever it is
passed a number or a character.  EQ? is, in short, a real crock whose
role we should be eliminating rather than expanding.

(The fact that EQ? is permitted to be universally false when passed a
number or character would not be affected by the R3.99RS's new requirement
that EQV?-ness must be preserved by storing and fetching from data
structures.  Strengthening this to preservation of EQ?-ness would decrease
the performance of some Scheme implementations, which could only be
justified by some offsetting benefit.  The efficiency argument against
preserving EQ?-ness cannot simply be dismissed, because efficiency is also
the only argument in favor of having EQ? in the language.  The only
important objects for which EQ? can differ from EQV? are numbers,
characters, and empty strings and vectors, so any benefits obtained from
preserving EQ?-ness as well as EQV?-ness must turn on the desirability
of making EQ? more reliable on these objects.  It will be hard to argue
that EQ? needs to be more reliable on these objects, because anyone who
thinks they need the additional reliability could just use EQV? instead.)


Guy Steele Jr:
    ....maybe inexact numbers should not possess object identity.

The behavior of EQ? on numbers (exact or inexact) is unspecified,
except that it must always return a boolean and (EQ? x y) implies
(EQV? x y).  The behavior of EQV? on numbers is defined in terms
of = and EXACT?.  It therefore seems to me that Scheme numbers in
general already lack object identity, unless what you mean by that
is either (1) you want calling EQ? or EQV? on an inexact number to
be an error; or (2) you want the Scheme procedure = to be unspecified
or erroneous on inexact numbers.


Alan Bawden:
    ....I am a believer in object identity even for inexact numbers....

I haven't the slightest idea what you are talking about, and it makes
me feel like Michael Dukakis.  Could somebody please tell me what
object identity is, and why it inspires such passionate allegiance?


Jim Miller:
    (e) None of the above.  Please state your position.

See page 33 of "'Toons for our Times" by Berke Breathed.

Peace, Will

∂07-Aug-89  2206	@mc.lcs.mit.edu,@life.ai.mit.edu:cph@zurich.ai.mit.edu 	LIST?    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89  22:06:15 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AB02881; Tue, 8 Aug 89 00:55:06 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa21779;
          7 Aug 89 21:00 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  7 Aug 89 21:00:49 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21713;
          7 Aug 89 20:53 EDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA00782; Mon, 7 Aug 89 20:52:54 EDT
Received: from localhost by zurich.ai.mit.edu; Mon, 7 Aug 89 20:49:35 edt
Date: Mon, 7 Aug 89 20:49:35 edt
From: Chris Hanson <cph@zurich.ai.mit.edu>
Message-Id: <8908080049.AA00201@zurich.ai.mit.edu>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:01:02 PDT <8908080001.AA04985@spencer.cs.uoregon.edu>
Subject: LIST?

   Date: Mon, 7 Aug 89 17:01:02 PDT
   From: will@cs.uoregon.edu

   I will add LIST? to the R3.99RS and R4RS as an essential procedure provided
   the authors will join me in a rousing chorus of "YES, YES!".

Yes.

∂07-Aug-89  2216	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	LIST? 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89  22:15:41 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02909; Tue, 8 Aug 89 01:00:55 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id ab21998;
          7 Aug 89 21:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  7 Aug 89 21:18:10 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa21817;
          7 Aug 89 21:06 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA00924; Mon, 7 Aug 89 21:06:44 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Mon, 7 Aug 89 21:03:22 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA01112; Mon, 7 Aug 89 18:06:26 pdt
Message-Id: <8908080106.AA01112@sde.hp.com>
Received: by hpesogg; Mon, 7 Aug 89 18:05:48 pdt
Date: Mon, 7 Aug 89 18:05:48 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:01:02 PDT <8908080001.AA04985@spencer.cs.uoregon.edu>
Subject: LIST?
Reply-To: jinx%hpesogg@sde.hp.com


    I will add LIST? to the R3.99RS and R4RS as an essential procedure provided
    the authors will join me in a rousing chorus of "YES, YES!".  Proposed
    wording:

	(LIST? obj)                                      essential procedure

	List? returns #t if obj is a list of finite length, and otherwise
	returns #f.

	    (list '(a b c))                      ==>  #t
	    (list '())                           ==>  #t
	    (list '(a . b))                      ==>  #f
	    (let ((x (list 'a)))
	      (set-cdr! x x)
	      (list? x))                         ==>  #f

(let loop ()
   (newline)
   (display "Yes, Yes!")
   (loop))

∂07-Aug-89  2237	cph@zurich.ai.mit.edu 	Scheme Digest #174    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 7 Aug 89  22:37:18 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA02907; Tue, 8 Aug 89 01:00:27 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 8 Aug 89 00:57:09 edt
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Sender: cph@zurich.ai.mit.edu
To: scheme-inbox@life.ai.mit.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id:  <8908070017.aa10696@mintaka.lcs.mit.edu>
Date: 7 AUG 89  00:02:32 EDT
Subject: Scheme Digest #174 

Scheme Digest #174                              7 AUG 89  00:02:32 EDT

Today's Topics:

        "Scheme has data types and Lisp doesn't."

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

Date: 6 Aug 89 18:55:51 GMT
From: Bruce Smith <thorin!evergreen!bts@mcnc.org>
Subject: Re: "Scheme has data types and Lisp doesn't."
Message-Id: <9085@thorin.cs.unc.edu>

I hope someone here can explain the origin of this notion that
"Scheme has data types and Lisp doesn't".  I have heard several
people make this claim over the past couple of years, but never
with any concrete evidence nor even a clear explanation of what
it's supposed to mean. (It was usually in almost exactly those
words, however.)

I know a modest amount about these languages and have access to
references on them.  I have not been able figure out what it is
supposed to mean.

Most recently, in a discussion of which functional programming
language should be taught to students (not at UNC, by the way)
I heard that Scheme was to be preferred because compiled Scheme
executes much faster than compiled Common Lisp.  The reason for
that difference?  Because, of course, "Scheme has data types
and Lisp doesn't."

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

End of Scheme Digest
********************

∂08-Aug-89  0015	@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:ziggy@hx.lcs.mit.edu 	RE: sequential evaluation of arguments   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89  00:15:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00254; Tue, 8 Aug 89 02:59:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22442;
          7 Aug 89 22:03 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU  7 Aug 89 22:03:25 EDT
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 280341; 7 Aug 89 22:03:14 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Mon, 7 Aug 89 22:01:54 EDT
Message-Id: <2827533780-14096492@RTS-8>
Sender: ziggy@rts-8.lcs.mit.edu
Date: Mon, 7 Aug 89  22:03:00 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: rrrs-authors@zermatt.lcs.mit.edu
Subject: RE: sequential evaluation of arguments

    Note:  Although the precise order of evaluation is unspecified, the
    expressions must be evaluated without interleaving.  Interleaving is
    not allowed because Scheme provides no facilities for serializing
    concurrent side effects.

Isn't this a bit strong?  Specifically, saying that exprs MUST BE EVALUATED
WITHOUT INTERLEAVING precludes parallel implementations which do compile-time
side-effect analysis to determine that two expressions' side effects are
non-interferring and thus can safely be run concurrently.  (Note that within
this context, we would consider two calls to CONS to "interfere" in the sense
that they have ALLOCATE effects, the results of which may not be shared, just
as we would consider two calls to I/O routines on the same I/O port to
interfere).

A more forgiving wording might be "expressions must be evaluated without
DETECTABLE interleaving" or "expressions must be evaluated in an order
consistent with some non-interleaved evaluation.  Detectable interleaving is
not allowed because Scheme provides no facilities for serializing concurrent
interferring side-effects." I emphasize interferrence since that is the real
concern: one shouldn't care about serializing non-interferring side-effects.

To point, it would be nice to allow common sub-expression ellimination of
pure expressions, such as:

 (let* ((x (f (moby-expensive-number-crunch 3.1415)))
	(y (g (moby-expensive-number-crunch 3.1415))))
   (h x	y))

  ==

 (let* (($$ (moby-expensive-number-crunch 3.1415))
        (x  (f $$))
        (y  (g $$)))
   (h x y))

My understanding of the Note at the top is that this would be forbidden.
It would be a shame to banish "sufficiently clever" compilers for parallel
machines to the realm of non-Scheme.

Am I just being an alarmist?				~Ziggy

∂08-Aug-89  0241	@mc.lcs.mit.edu,@zermatt.lcs.mit.edu:jinx@hpesogg.hp.com 	sequential evaluation of arguments   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89  02:41:44 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00786; Tue, 8 Aug 89 05:29:45 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26224;
          8 Aug 89 3:55 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU  8 Aug 89 03:56:20 EDT
Received: from SDE.HP.COM by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 280383; 8 Aug 89 03:56:07 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA15625; Tue, 8 Aug 89 00:54:59 pdt
Message-Id: <8908080754.AA15625@sde.hp.com>
Received: by hpesogg; Tue, 8 Aug 89 00:54:21 pdt
Date: Tue, 8 Aug 89 00:54:21 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zermatt.lcs.mit.edu
In-Reply-To: "Michael R. Blair"'s message of Mon, 7 Aug 89  22:03:00 EDT <2827533780-14096492@RTS-8>
Subject: sequential evaluation of arguments
Reply-To: jinx%hpesogg@sde.hp.com


	Note:  Although the precise order of evaluation is unspecified, the
	expressions must be evaluated without interleaving.  Interleaving is
	not allowed because Scheme provides no facilities for serializing
	concurrent side effects.

    Isn't this a bit strong?  Specifically, saying that exprs MUST BE EVALUATED
    WITHOUT INTERLEAVING precludes parallel implementations which do compile-time
    side-effect analysis to determine that two expressions' side effects are
    non-interferring and thus can safely be run concurrently.  (Note that within
    this context, we would consider two calls to CONS to "interfere" in the sense
    that they have ALLOCATE effects, the results of which may not be shared, just
    as we would consider two calls to I/O routines on the same I/O port to
    interfere).

Being a firm believer in Quantum Mechanics, I believe that if you
can't tell the difference, you can do anything you want.  I think you
are interpreting the wording too restrictively.  I interpret all such
"commands" as saying "your implementation must produce the same values
as if...", not "your implementation must act in exactly the following
way...". 

∂08-Aug-89  0258	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #175 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89  02:58:11 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00783; Tue, 8 Aug 89 05:25:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa23540;
          8 Aug 89 0:06 EDT
Date: 8 AUG 89  00:04:08 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #175 
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id:  <8908080006.aa23540@mintaka.lcs.mit.edu>

Scheme Digest #175                              8 AUG 89  00:04:08 EDT

Today's Topics:

        Opinions wanted.

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

Date: 7 Aug 89 13:35:43 GMT
From: "Mark W. Bailey" <haven!uvaarpa!virginia!uvacs!mwb5y@purdue.edu>
Subject: Opinions wanted.
Message-Id: <MWB5Y.89Aug7093543@hopper.hopper.cs.virginia.edu>


We looking for a good book on Scheme to use in a graduate programming
languages course. I've found "The SCHEME programming language"
by Dybvig, but I don't have access to a copy. I'd like information
on this or any other books that are available.

Please send e-mail.

Mark W. Bailey		mwb5y@virginia.edu
Computer Science
University of Virginia

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

End of Scheme Digest
********************

∂08-Aug-89  1701	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	R3.99RS issues (else)    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89  17:01:40 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06814; Tue, 8 Aug 89 19:47:24 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00126;
          8 Aug 89 11:01 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Aug 89 11:01:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa29950;
          8 Aug 89 10:56 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02346; Tue, 8 Aug 89 10:55:58 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 10:52:36 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA03048; Tue, 8 Aug 89 07:55:06 PDT
Date: Tue, 8 Aug 89 07:55:06 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8908081455.AA03048@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:02:53 PDT <8908080002.AA05003@spencer.cs.uoregon.edu>
Subject: R3.99RS issues (else)


ciao,

I think that Morry's argument is valid.  If a user wants to use 'else' in the
cond or case special forms define the variable to be #t.  This seems like a
clear example of where we can reduce the number of things the user has to
remember without screwing anyone!

I personally would like to see the language only grow with additional concepts.

(peace chance)

	mas

∂08-Aug-89  1733	@mc.lcs.mit.edu,@life.ai.mit.edu:hudak-paul@yale.edu 	Re: sequential order of evaluation  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89  17:33:45 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA07002; Tue, 8 Aug 89 20:19:17 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00428;
          8 Aug 89 11:31 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Aug 89 11:32:01 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00398;
          8 Aug 89 11:29 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02577; Tue, 8 Aug 89 11:29:38 EDT
Received: from ATHENA.CS.YALE.EDU ([128.36.0.27]) by zurich.ai.mit.edu; Tue, 8 Aug 89 11:26:15 edt
Received: by ATHENA.CS.YALE.EDU; Tue, 8 Aug 89 10:07:46 EDT
From: Paul Hudak <hudak-paul@yale.edu>
Message-Id: <8908081407.AA09346@ATHENA.CS.YALE.EDU>
Received: by yale-ring (node-add2/ADD2) 
          via WIMP-MAIL (Version 1.3/1.5) ; Tue Aug  8 09:56:20
Date: Tue, 8 Aug 89 09:56:16 EDT
Subject: Re: sequential order of evaluation
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu, Mon, 7 Aug 89 17:01:45 PDT

    The choice is explicit in the rather informal formal semantics, which says
    the expressions must be evaluated sequentially in some permuted order.

To be more precise, the informal formal semantics says that whatever
permuted order is chosen must be used for ALL expressions.  That bothers
me much more than having it prohibit interleaving.

    How do the authors feel about adding the following note to section 4.1.3?
    
        Note:  Although the precise order of evaluation is unspecified, the
        expressions must be evaluated without interleaving.  Interleaving is
        not allowed because Scheme provides no facilities for serializing
        concurrent side effects.
    
Completely prohibiting interleaving seems too strong.

To kill two birds with one stone, I think the note should read something like:

    Note:
    (1) The unspecified order-of-evaluation may be chosen differently for
        each expression.
    (2) An implementation is only required to guarantee a result that is 
        consistent with SOME sequential order-of-evaluation (and thus 
        interleaving is not necessarily prohibited).

-Paul
-------


∂08-Aug-89  1910	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	LIST?
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89  19:09:45 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA07634; Tue, 8 Aug 89 21:57:25 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00515;
          8 Aug 89 11:37 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Aug 89 11:38:19 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00440;
          8 Aug 89 11:32 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02590; Tue, 8 Aug 89 11:32:06 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 11:28:43 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA03174; Tue, 8 Aug 89 08:30:53 PDT
Date: Tue, 8 Aug 89 08:30:53 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8908081530.AA03174@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:01:02 PDT <8908080001.AA04985@spencer.cs.uoregon.edu>
Subject: LIST?

LIST? YES, YES!

-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂08-Aug-89  2158	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	sequential order of evaluation
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89  21:58:27 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09413; Wed, 9 Aug 89 00:48:56 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00627;
          8 Aug 89 11:44 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Aug 89 11:45:10 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa00579;
          8 Aug 89 11:42 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02692; Tue, 8 Aug 89 11:42:13 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 11:38:49 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA03202; Tue, 8 Aug 89 08:41:03 PDT
Date: Tue, 8 Aug 89 08:41:03 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8908081541.AA03202@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:01:45 PDT <8908080001.AA04992@spencer.cs.uoregon.edu>
Subject: sequential order of evaluation

   Date: Mon, 7 Aug 89 17:01:45 PDT
   From: will@cs.uoregon.edu

   How do the authors feel about adding the following note to section 4.1.3?

       Note:  Although the precise order of evaluation is unspecified, the
       expressions must be evaluated without interleaving.  Interleaving is
       not allowed because Scheme provides no facilities for serializing
       concurrent side effects.

I find the above opaque and would like to suggest the following alternative
which uses the concept os SERIALIZABILITY as established in the database
literature. 

Note: Although the precise order of evaluation is unspecified, the evaluation
of the expressions must be "serializable".  An evaluation ordering is said to
be serializable if its effects are indistinguishable from those of some
sequential evaluation of the expressions.  Interleaved evaluation of several
expresions is ONLY valid if the effects of interleaving are serializable (i.e.
undetectable). 
 
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂08-Aug-89  2334	@mc.lcs.mit.edu,@ZERMATT.lcs.mit.edu:RPG@sail.stanford.edu 	re: sequential evaluation of arguments  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89  23:34:30 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA09769; Wed, 9 Aug 89 02:24:12 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa00821;
          8 Aug 89 12:02 EDT
Received: from ZERMATT.LCS.MIT.EDU (CHAOS 17316) by MC.LCS.MIT.EDU  8 Aug 89 12:03:00 EDT
Received: from SAIL.STANFORD.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 280467; 8 Aug 89 12:02:48 EDT
Message-Id: <NJ7jX@SAIL.Stanford.EDU>
Date: 08 Aug 89  0900 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
Subject: re: sequential evaluation of arguments  
To: jinx%hpesogg@sde.hp.com, ziggy@hx.lcs.mit.edu
Cc: rrrs-authors@zermatt.lcs.mit.edu

[In reply to message from jinx%hpesogg@sde.hp.com sent Tue, 8 Aug 89 00:54:21 pdt.]

Jinx writes:

   Being a firm believer in Quantum Mechanics, I believe that if you
   can't tell the difference, you can do anything you want.  I think you
   are interpreting the wording too restrictively.  I interpret all such
   "commands" as saying "your implementation must produce the same values
   as if...", not "your implementation must act in exactly the following
   way...". 

Perhaps a clear statement of this should be placed at the front of the
document so that those who don't understand Quantum Mechanics can understand
Scheme.

			-rpg-


∂09-Aug-89  0009	@mc.lcs.mit.edu,@life.ai.mit.edu:shaff@sesame.stanford.edu 	R3.99RS issues (macros in R4RS)    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89  00:09:34 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00245; Wed, 9 Aug 89 02:58:30 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01606;
          8 Aug 89 13:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Aug 89 13:04:00 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01536;
          8 Aug 89 12:57 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03353; Tue, 8 Aug 89 12:57:18 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 12:53:56 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA03492; Tue, 8 Aug 89 09:56:26 PDT
Date: Tue, 8 Aug 89 09:56:26 PDT
From: Mike Shaff <shaff@sesame.stanford.edu>
Message-Id: <8908081656.AA03492@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 17:02:53 PDT <8908080002.AA05003@spencer.cs.uoregon.edu>
Subject: R3.99RS issues (macros in R4RS)


ciao,

Will>The plan is for the R4RS (but not the R3.99RS) will have an appendix that
Will>describes (at least) two incompatible macro proposals and the issues that
Will>have prevented them from being resolved; this should be the only
Will>substantial difference between the R3.99RS and the R4RS.

I am in strong disagreement with the inclusion of two appendices, as the net
effect will be an unfair evaluation of the issues by the user community.
Syntactic closures without a user interface will not be 'user friendly', but I
believe addresses the issues that are important.  Extend-syntax has many nice
properties, but does NOT address the issues that are important to me.  I can
not believe that a compromise is not attainable by the macro committee.  I
implore the committee and other interested parties to resolve this divisive
issue.

To make the point totally clear I believe that R4RS should NOT be issued until
this issue is resolved with ONE decision.

 (peace chance)

	mas

∂09-Aug-89  0012	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@ZERMATT.lcs.mit.edu:ziggy@hx.lcs.mit.edu 	RE: evaluation order rule
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89  00:12:08 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00276; Wed, 9 Aug 89 03:03:34 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05380;
          8 Aug 89 17:34 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Aug 89 17:30:32 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa05246;
          8 Aug 89 17:27 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05808; Tue, 8 Aug 89 17:25:59 EDT
Received: from ZERMATT.LCS.MIT.EDU (zermatt.lcs.mit.edu) by zurich.ai.mit.edu; Tue, 8 Aug 89 17:22:41 edt
Received: from HX.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via INTERNET with SMTP id 280559; 8 Aug 89 17:25:18 EDT
Received: by hx.LCS.MIT.EDU (5.51/4.7); Tue, 8 Aug 89 17:23:54 EDT
Message-Id: <2827603503-1770121@RTS-8>
Sender: ziggy@rts-8.lcs.mit.edu
Date: Tue, 8 Aug 89  17:25:03 EDT
From: "Michael R. Blair" <ziggy@hx.lcs.mit.edu>
To: jinx%zurich.ai.mit.edu@zermatt.ai.mit.edu
Cc: rrrs-authors%zurich.ai.mit.edu@zermatt.ai.mit.edu
Subject: RE: evaluation order rule

As per Jinx's reply:

    [paraphrase]: Breaking a rule is only illegal if someone sees you do it.

Thanks.  I had hoped I was just being too literal...  I get nervous when I
hear ``thou shalt not''.  In this case it seems no big deal, but I worry about
restrictions that may be too strong.

  Take for example the Anti-Aliasing Rule in Gifford & Lucassen's FX language:
it is intended to forbid undetected interferrence but it is worded to forbid
run-time detection&serialization of potentially interferring concurrent
threads (it forces them to signal an error instead).  Thus, stating a design
desiderata as a restriction without carefully stating the principle behind it,
although expedient, can be a precarious business.  [I believe the FX designers
intend to fix this deficiency in the next version of their language.]

 The evaluation rule as originally stated was careful to explain the lack of
serializing facilities in Scheme as the problem but it did so as a
rationalization for forbidding non-interleaving.  I had hoped that merely
adding the adjective DETECTABLE would be judicious and non-offensive.
Whatever.  Guess I just don't like rules.
							~Ziggy

∂09-Aug-89  0148	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: R3.99RS issues (else)  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89  01:47:44 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00691; Wed, 9 Aug 89 04:36:08 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07319;
          8 Aug 89 20:29 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Aug 89 20:29:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07293;
          8 Aug 89 20:24 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07031; Tue, 8 Aug 89 20:24:17 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 20:20:58 edt
Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 89 17:19:47 PDT
Date: Tue, 08 Aug 89 17:19:50 PDT
From: Pavel.pa@xerox.com
Subject: Re: R3.99RS issues (else)
In-Reply-To: <8908081455.AA03048@sesame.Stanford.EDU>
To: Mike Shaff <shaff@sesame.stanford.edu>
Cc: rrrs-authors@zurich.ai.mit.edu
Message-Id: <890808-171947-2772@Xerox>

Defining ``else'' to be #t in not sufficient to allow users to use the
``else'' keyword in case-expressions, since that position in the form is
not evaluated.

I see no reason to use #t as the ``otherwise'' clause marker in a
case-expression.  It has no more semantic justification than, say, 17.  The
right name for that spot is ``else''.

	Pavel

∂09-Aug-89  0355	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Dynamic variables
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89  03:55:37 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01177; Wed, 9 Aug 89 06:41:50 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa07634;
          8 Aug 89 20:53 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Aug 89 20:53:25 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07597;
          8 Aug 89 20:50 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07222; Tue, 8 Aug 89 20:50:29 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 20:47:08 edt
Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 89 17:48:10 PDT
Date: Tue, 08 Aug 89 17:48:10 PDT
From: Pavel.pa@xerox.com
Subject: Dynamic variables
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890808-174810-2879@Xerox>

This is the proposal for adding dynamic variables (aka fluid binding) to
Scheme, as approved by consensus at the first meeting of BASH.  See my
message of 05 Jul 89 for the details of the motivations behind the
proposal.

We propose adding four procedures and one derived expression type to
Scheme:

(MAKE-DYNAMIC obj)                                     [Procedure]

Create and return a new ``dynamic variable'' whose global value is obj.

(DYNAMIC-REF dvar)                                     [Procedure]

Return the value of the given dynamic variable in the current dynamic
environment.

(DYNAMIC-SET! dvar obj)                                [Procedure]

Change the value of the given dynamic variable to obj in the current
dynamic environment.  The returned value is unspecified.

(CALL-WITH-DYNAMIC-BINDING dvar obj thunk)             [Procedure]

Invoke and return the value of the given thunk in a new, nested dynamic
environment in which the given dynamic variable has been bound to a new
location whose initial contents are the value obj.  This dynamic
environment has precisely the same extent as the invocation of the thunk
and is thus captured by continuations created within that invocation and
re-established by those continuations when they are invoked.

(DYNAMIC-BIND ((var-expr val-expr) ...) . body)           [Syntax]

Evaluates the var-exprs and val-exprs in an unspecified order; the
var-exprs should yield dynamic variables.  Returns the result of evaluating
the body in a new, nested dynamic environment in which the given dynamic
variables have new bindings, initialized to the given values.  This dynamic
environment has precisely the same extent as the evaluation of the body and
is thus captured by continuations created within the body and
re-established by those continuations on invocation.

The DYNAMIC-BIND derived expression type has the following rewrite rule:

    (dynamic-bind ((<var-expr1> <val-expr1>)
                   (<var-expr2> <val-expr2>)
                   ...
                   (<var-exprN> <val-exprN>))
       . <body>)

    is equivalent to

    (let ((var1 <var-expr1>)
          (val1 <val-expr1>)
          (var2 <var-expr2>)
          (val2 <val-expr2>)
          ...
          (varN <var-exprN>)
          (valN <val-exprN>)
          (body-thunk (lambda () . <body>)))

       (call-with-dynamic-binding var1 val1
          (lambda ()
             (call-with-dynamic-binding var2 val2
                (lambda ()
                   ...
                      (call-with-dynamic-binding varN valN
                         body-thunk) ... )))))

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

Some notes on this proposal:

-- I think that the ``call-with-dynamic-binding'' procedure was actually
named ``call-with-dynamic'' in the proposal passed by BASH, but that
sounded funny to me.  I'm willing to change it back, though, if anyone
objects to my changing it.

-- Should there be a ``dynamic?'' predicate that is true only of dynamic
variables?  I'm inclined to think so.

-- Should it be specified that dynamic variables are a new data type,
disjoint from the others?  I'm again so inclined.

-- Given ``dynamic-wind'', a portable shallow-binding implementation of the
proposal can be written for all single-processor implementations of Scheme.
It was suggested at the BASH meeting that something like this be done and
placed in the library.  As stated in earlier messages, multiprocessor
implementations will have to implement it more primitively; Jinx has
pointed out, however, that two simple procedures for accessing the
process-specific dynamic environment suffice.

-- This proposal does not specify whether or not
``call-with-dynamic-binding'' tail-calls the given thunk.  I think this is
proper.  It is possible for deep-binding implementations to use tail-call,
but only at the expense of passing the dynamic environment on every
procedure call.  In shallow binding implementations, it is probably not
possible at all.

	Pavel

∂09-Aug-89  0440	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	sequential order of evaluation 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89  04:40:09 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01352; Wed, 9 Aug 89 07:28:52 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08015;
          8 Aug 89 21:32 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Aug 89 21:16:52 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa07815;
          8 Aug 89 21:13 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07317; Tue, 8 Aug 89 21:12:49 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 21:09:30 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA05770; Tue, 8 Aug 89 18:11:48 pdt
Message-Id: <8908090111.AA05770@sde.hp.com>
Received: by hpesogg; Tue, 8 Aug 89 18:11:13 pdt
Date: Tue, 8 Aug 89 18:11:13 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: hudak-paul@yale.edu
Cc: will@cs.uoregon.edu, rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Paul Hudak's message of Tue, 8 Aug 89 09:56:16 EDT <8908081407.AA09346@ATHENA.CS.YALE.EDU>
Subject: sequential order of evaluation
Reply-To: jinx%hpesogg@sde.hp.com


    To kill two birds with one stone, I think the note should read something like:

	Note:
	(1) The unspecified order-of-evaluation may be chosen differently for
	    each expression.
	(2) An implementation is only required to guarantee a result that is 
	    consistent with SOME sequential order-of-evaluation (and thus 
	    interleaving is not necessarily prohibited).

This may still be too restrictive.  It seems to me that it should be
allowable to choose a different sequential order each time an
expression is evaluated, rather than choosing an order per expression.
Admittedly this will be rare because of implementation problems, but
it should not be disallowed.

∂09-Aug-89  0657	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	MIN and MAX (long message)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89  06:57:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01948; Wed, 9 Aug 89 09:40:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa08093;
          8 Aug 89 21:40 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Aug 89 21:41:13 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa08043;
          8 Aug 89 21:36 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07396; Tue, 8 Aug 89 21:23:46 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 21:20:23 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA06014; Tue, 8 Aug 89 18:23:01 pdt
Message-Id: <8908090123.AA06014@sde.hp.com>
Received: by hpesogg; Tue, 8 Aug 89 18:22:26 pdt
Date: Tue, 8 Aug 89 18:22:26 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: will@cs.uoregon.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Mon, 7 Aug 89 16:02:42 PDT <8908072302.AA04327@spencer.cs.uoregon.edu>
Subject: MIN and MAX (long message)
Reply-To: jinx%hpesogg@sde.hp.com

    Bill Rozas:
	As far as I understand it (and GJS agrees with me), the example Will
	shows could only be correct in an implementation where 
	(>= 9.999999999999998e99 #e1e100) is true.  If it isn't, the
	implementation of MAX/SUP is in error.

    Not as I understand it.  I intended for this example to illustrate
    what happens in an implementation that uses IEEE 64-bit floating
    point to represent inexact reals, but I goofed (because of a bug
    in the least significant bit of MacScheme's implementation of
    EXACT->INEXACT for large numbers).  A better example is

	(MAX 1.4 #e1e200) ==> 9.99999999999999969733e199

The problem with this is that

(MAX 9.99999999999999969733e199 #e1e200) ==> 9.99999999999999969733e199

while the implementation can still distinguish (in the sense of < and
>) between both arguments.

This seems wrong!

    I think that requiring MAX to round up would be like requiring
    (+ x y) to return a number greater than x whenever y is positive.
    It sounds plausible at first, but would tend to make computations
    less accurate.  I have to admit, given the difficulty of coming up
    with any real-world examples where MAX returns a value that is not
    equal to one of its arguments, that a difference in the least
    significant bit in such cases would probably be of very little
    consequence, and it might make someone's mother happy.

I think your analogy is pushing it a bit.  I don't expect inexact + to
follow any particular ordering properties.  In fact, we know that
floating point addition (the "usual" implementation) rounds towards
even, and there are (or so I'm told) good reasons for this.  I do
expect some ordering properties out of MAX/SUP, however.  Otherwise I
would not be using it at all.  The rule that GJS and I like, namely
that MAX/SUP should return the smallest value >= all of its arguments,
makes it more predictable than yours.



∂09-Aug-89  1545	@mc.lcs.mit.edu,@life.ai.mit.edu:bartlett@decwrl.dec.com 	First BASH Meeting    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 9 Aug 89  15:44:46 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA06463; Wed, 9 Aug 89 18:25:51 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01511;
          8 Aug 89 12:55 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  8 Aug 89 12:50:51 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa01371;
          8 Aug 89 12:41 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02485; Tue, 8 Aug 89 11:13:44 EDT
Received: from decwrl.dec.com (decwrl.dec.com) by zurich.ai.mit.edu; Tue, 8 Aug 89 11:10:19 edt
Received: from gnomec.pa.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	id AA00220; Tue, 8 Aug 89 08:13:31 PDT
Received: from gnomec.pa.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	for rrrs-authors@zurich.ai.mit.edu; id AA00220; Tue, 8 Aug 89 08:13:31 PDT
Received: by gnomec.pa.dec.com (5.57/4.7.34)
	id AA02503; Tue, 8 Aug 89 08:00:51 PDT
Date: Tue, 8 Aug 89 08:00:51 PDT
From: Joel Bartlett <bartlett@decwrl.dec.com>
Message-Id: <8908081500.AA02503@gnomec.pa.dec.com>
To: bartlett@decwrl.dec.com, rrrs-authors@zurich.ai.mit.edu
Subject: First BASH Meeting

			First BASH Meeting

Bay Area Scheme Hackers (BASH) is dedicated to fostering informal
communication among those interested in the programming language Scheme in
the San Francisco Bay Area.  Details to follow after we get organized.

Minutes:

The first meeting was held at Stanford on 1 August 1989 with Daniel Weise
graciously providing a place to meet and lunch.  Those in attendance were:

	Daniel Weise		daniel@mojave.stanford.edu
	Michael Shaff		shaff@sesame.stanford.edu
	Guillermo Rozas		jinx@zurich.ai.mit.edu
	Morry Katz		katz@polya.stanford.edu
	James O'Toole		james@zermatt.lcs.mit.edu
	Pierre Jouvelot		jouvelot@brokaw.lcs.mit.edu
	James Rauen		rauen.pa@xerox.com
	Pavel Curtis		pavel.pa@xerox.com
	Michael Plass		plass.pa@xerox.com
	Erik Ruf		ruf@dolores.stanford.edu
	Jonathan Rees		jar@zurich.ai.mit.edu
	Joel Bartlett		bartlett@decwrl.dec.com

Following the drafting of a scribe, the first order of business was a
discussion of rrrs-authors issues.

MAX/MIN/SUP/INF

Resolved:  these words may not be used in any conversation during the
meeting.

Uniform definition syntax

Pavel spoke in favor of his earlier proposal to rrrs-authors on 22 jun 89:

      I'd like to request that the syntax and semantics of bodies and programs
      be identical, but not quite like either one in R3RS.  Let the syntax be

	<program> ::= { <expression> | <definition> | (begin <program>) }*
	<definition> ::= (define <variable> <expression>)
	    | (define (<variable> <def formals>) <body>)
	<body> ::= <program>

      so definitions and expressions can be freely mixed, both at ``top level''
      and internally.  Also, BEGINs at top level need not consist entirely of
      definitions or entirely of expressions, as in R3.95RS.  The semantics is
      as follows:

     -- (begin <program>)  is entirely equivalent to  <program> .
     -- programs comprising only expressions and definitions have the same
        meaning as given in the formal semantics in R3.95RS; that is, bindings
        are established for all defined variables giving them unspecified
	values after which the program is evaluated in sequence, treating
	definitions as if they were assignments.

Jinx spoke in favor of the status quo, i.e. the incremental nature of top
level expression evaluation as noted in section 5.1 of R3RS.

Resolved:  no resolution.

Fluid Binding

Pavel discussed his proposal for a fluid binding construct that has been
discussed on rrrs-authors.  Objections were made to using the words
"fluid" or "bindings" in the name as they might conflict with existing
fluid constructs.  The word "dynamic" was suggested as an alternative.

Resolved:  Accept Pavel's constructs with the name changed to dynamic
variables.  He will edit his proposal and resubmit to rrrs-authors.

Regularization

Morry was assigned at Snowbird to look into "regularization" of Scheme.
He made a proposal to rrrs-authors on 14 Oct 88.

Resolved:  Accept his "non-controversial" recommendations.

Resolved:  Accept LIST? as a new predicate.  LIST? must always run to
completion, i.e. (LIST? x) => #f, where x is a circular list.  Report
should note that lists are a convention, not a primitive data type.  It
should also note that the property LIST? of an object may change due to
the effects of SET-CDR!.

Resolved:  Without making a value judgement, it is the sense of the
meeting that this is not the time to add additional member functions.

Resolved:  Additional control expressions in the style of MAP and FOR-EACH
are desirable, but the group did not muster strong support for any of the
current rrrs-authors proposals.

Resolved:  No changes to APPLY.

Multiple Values

Resolved:  While not everyone thinks they are a good idea, there is the
feeling that they belong in the language.

Resolved:  (values 1) is equivalent to 1.

Resolved:  The proposed ARITY procedure reveals too much about the
underlying implementation and should be replaced by a predicate ACCEPTS?
that tests whether a procedure will accept a given number of values. Morry
will change his proposal and resubmit to rrrs-authors.

Modules

Joel described the module system that is in Scheme->C.  Scheme->C is
intended to allow Scheme code to coexist with code written in other
languages.  The compiler compiles a module at a time.  The source for the
module may reside in multiple files and can contain DEFINE-EXTERNAL syntax
for defining variables or procedures in other modules.  A variable X that
a module wishes to make visible at the top level has the name X.  All
other variables in the module are also visible at the top level with a
name of the form module-name_variable-name.  It is an error for two
modules to place the same variable name at the top level.

Jinx described the MIT Scheme package system.  MIT Scheme supports multiple
environments, with each package in its own environment.  The package
definition is in the form of a "wiring diagram" that unifies variables
across environments.  The mechanism also allows procedure integration
information and syntax extensions to be exported.

Pavel described the proposed module Scheme for Scheme Xerox.  It will be
based upon Cedar's module system.  Each module will have a list of imports
and exports, with an implicit import of the "scheme" interface.  Imported
names cannot be assigned.  Backdoor for debugging as modules may hide
items (see meta issues).  When completed, the definition of the module
system will be posted to rrrs-authors (for information only, not a
proposal for RnRs).

Resolved: no proposals, no resolutions.

Macros

Jonathan reported that there is an impasse between those wanting extend
syntax and those concerned about capture problems.  It is not clear how to
resolve this to produce one macro proposal.

Resolved:  The macro committee should keep trying.  R4RS should not go out
without a macro proposal.  It should not go out with two macro proposals.

Records

Much discussion about opaque vs. non-opaque types.  In order to satisfy
Jinx and other members of the non-opaque faction, a procedure that maps a
record to its record type descriptor, and some procedure that permits one
to obtain all the selectors from a record type descriptor, will be added
to the proposal.

Resolved:  Pavel will update Jonathan's earlier proposal and submit to
rrrs-authors.

Meta Issue - rrrs-authors

How are decisions made?  How does a concensus form?  Should there be
strong leadership by the editor over the net?  A general feeling of
frustration that rrrs-authors discussions don't seem to converge.
Suggestions that might make this happen were to have "someone with
sufficient moral authority" to ride herd on the net, and to require that
proposals contain more information.  The example given was Common Lisp
cleanup, where each proposal had to have the problem, the solution, the
cost to users and implementers, plus pros and cons.  The proposal is
revised and reissued as new issues come up.

Resolved:  it would be nice if rrrs-authors worked better.  It may be time
for another rrrs-authors meeting.  Perhaps at POPL in San Francisco.

Meta-issue - Timing of RnRS

Proposal:  R4RS should hold until there is a macro proposal.  While we're
waiting, no other changes should be considered.  Instead, new proposals
should be for R5RS.

Resolved:  no resolution.

Meta Issue - Opaque vs. non-opaque types

Should the user of a module or record type be allowed to look inside it if
the implementer did not export such an interface?  Lively discussion topic!

Resolved:  no resolution.

Meta Issue - What is the purpose of the Scheme Report?

	(1) To allow us to read each others code, but not constrain
	    anyone's implementation.
	(2) To encourage the construction of common implementations to
	    allow the exchange of programs.

Another lively discussion topic.

Resolved:  no resolution.

After spending most of the day on rrrs-authors issues.  The meeting turned
to short presentations about implementations.

Scheme Xerox (Pavel Curtis, Michael Plass, James Rauen)

This implementation is intended to be the upper bound of Scheme and Cedar.
Additions include dynamic variables, macros, modules, strong typing,
concurrency, signals, and monitor locks to Scheme.  Signal handling will
be done in a straight forward manner.  When a signal occurs, the procedure
that is the value of the dynamic variable *handler* is called with the
signal.  It may handle it, or pass it to the previous value of handler.
The project is in the design and specification stage.  Implementation
expected to be under way later this year.  The system will run on top of
the Portable Common Runtime (threads, garbage collection, dynamic loading,
and name management) that is being done for the port of Cedar to UNIX.
Implementation will be intercallable with Cedar.  The intent is to make it
widely available.

Scheme->C (Joel Bartlett)

Scheme->C is a Scheme system designed to generate code that can be
embedded in other systems.  The compiler compiles Scheme to C that is then
compiled by the system's C compiler to produce a runnable object. The
system is designed to be very portable with a minimal amount of machine
dependent code in the implementation.  Besides the essentials of R3RS (and
many optionals), there are also modules, macros, foreign function calls,
and and an interface to X11's xlib. The system currently runs on VAX and
DECStation 3100 systems. For more details see Scheme Digest #47, #49, and
#63.  Currently the licensing is fairly restrictive.  This should change
in the near future so that it will be more generally available to
non-commercial users.  When this happens, a note will be posted to the
Scheme Digest.

S48 (Jonathan Rees)

A side project to build a Scheme virtual machine.  It consists of a byte
code interpreter that has a C and a Scheme implementation.  The rest is
coded in Scheme.  Seen as a pedagogical tool, but also as a "competitor"
to Xscheme.

Pseudoscheme (Jonathan Rees)

A Scheme to Common Lisp translator that runs in any Common Lisp system.
While it can't completely support call-with-current-continuation and tail
call, it is quite popular.

T (Jonathan Rees)

Waiting for changes from Yale.  Would like to modify it so that it comes
up in an R4RS compatible environment.  David Kranz has done code
generators for MIPS and SPARC processor architectures.

MIT Scheme (Jinx)

MIT Scheme is done as a tool for courses and research at MIT.  While it is
available to others, MIT's needs will direct development.  In the process
of shifting from an interpreter based system to a compiler based system.
Compilers are currently available for the VAX and 68020.  Future work to
include faster numeric code. For more details see the recent posting to
the Scheme Digest.

The meeting concluded with a few comments on applications.

RPC

Michael Plass is going to be doing an RPC system for Scheme Xerox.  It
will allow heterogeneous Scheme implementations with no shared memory to
cooperate.

Library

Jonathan Rees is the new Scheme librarian.  He'd like to develop a
strategy to get more stuff into it and publicize it.  He'd like to define
standard interfaces and then solicit multiple implementations, some
portable, some not.  Some discussion about using Brian Reid's archive
server to handle requests for software.

Resolved:  All in favor of the library.

Future BASH meetings

Resolved:  We should have more.  Pavel to set up a mailing list,
bash↑@xerox.com.  Joel suggested that the next meeting could be at WRL
sometime in October.  To be further discussed via mail.  Speakers,
listeners, etc. needed.


∂10-Aug-89  0646	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	R3.99RS issues (else)    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89  06:46:14 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01851; Thu, 10 Aug 89 09:36:26 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16408;
          9 Aug 89 11:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  9 Aug 89 11:42:57 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16386;
          9 Aug 89 11:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02926; Wed, 9 Aug 89 11:38:35 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Wed, 9 Aug 89 11:35:13 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA07820; Wed, 9 Aug 89 08:37:41 PDT
Date: Wed, 9 Aug 89 08:37:41 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8908091537.AA07820@sesame.Stanford.EDU>
To: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 08 Aug 89 17:19:50 PDT <890808-171947-2772@Xerox>
Subject: R3.99RS issues (else)

   Date: Tue, 08 Aug 89 17:19:50 PDT
   From: Pavel.pa@xerox.com

   Defining ``else'' to be #t in not sufficient to allow users to use the
   ``else'' keyword in case-expressions, since that position in the form is
   not evaluated.

As was discussed earlier in private mail, ELSE does not have to be a syntactic
keyword for its use in CASE.  I advocated removing ELSE as a syntactic keyword,
which only effects COND.  In my opinion, it would have been semantically
cleaner if the matching expressions in case were in an evaluated context, but
this is another issue and one which I am sure will never change for historic
reasons, if none other.

-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂10-Aug-89  0717	@mc.lcs.mit.edu,@life.ai.mit.edu:mkatz@sesame.stanford.edu 	Dynamic variables   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89  07:16:44 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02072; Thu, 10 Aug 89 10:05:23 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa16493;
          9 Aug 89 11:50 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  9 Aug 89 11:50:36 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa16440;
          9 Aug 89 11:45 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02979; Wed, 9 Aug 89 11:45:09 EDT
Received: from sesame.Stanford.EDU (sesame.stanford.edu) by zurich.ai.mit.edu; Wed, 9 Aug 89 11:41:37 edt
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA07848; Wed, 9 Aug 89 08:43:47 PDT
Date: Wed, 9 Aug 89 08:43:47 PDT
From: Morris Katz <mkatz@sesame.stanford.edu>
Message-Id: <8908091543.AA07848@sesame.Stanford.EDU>
To: Pavel.pa@xerox.com
Cc: RRRS-Authors@zurich.ai.mit.edu, Pavel.pa@xerox.com
In-Reply-To: Pavel.pa@xerox.com's message of Tue, 08 Aug 89 17:48:10 PDT <890808-174810-2879@Xerox>
Subject: Dynamic variables

   Date: Tue, 08 Aug 89 17:48:10 PDT
   From: Pavel.pa@xerox.com

   This is the proposal for adding dynamic variables (aka fluid binding) to
   Scheme, as approved by consensus at the first meeting of BASH.  See my
   message of 05 Jul 89 for the details of the motivations behind the
   proposal.

This proposal was NOT accepted by consensus at BASH as I stated that I was not
comfortable with it at that meeting.  Despite the fact that I have corrected
Pavel TWICE on this issue, he insists on using the word consensus in an
effort, I suppose, to give his proposal more weight.  I am attempting to
formulate, in my own mind, exactly what about this proposal makes me
uncomfortable and will post a message as soon as I can make a cogent
presentation.  In the meantime, however, I wanted to set the record straight.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂10-Aug-89  0725	@mc.lcs.mit.edu,@life.ai.mit.edu:jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk 	No mail    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89  07:25:50 PDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AB02136; Thu, 10 Aug 89 10:13:43 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20679;
          9 Aug 89 17:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  9 Aug 89 17:03:55 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20636;
          9 Aug 89 16:59 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA05921; Wed, 9 Aug 89 16:59:18 EDT
Received: from NSFnet-Relay.AC.UK (nsfnet-relay.ac.uk) by zurich.ai.mit.edu; Wed, 9 Aug 89 16:54:57 edt
Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK   via Janet with NIFTP
           id aa07324; 9 Aug 89 19:15 BST
Date: Wed, 9 Aug 89 19:21:38 BST
Message-Id: <2090.8908091821@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk>
Subject: No mail
To: rrrs-authors@zurich.ai.mit.edu
Cc: rrrs-authors-request <@uunet.uu.net:rrrs-authors-request@zurich.ai.mit.edu>

I have not seen any mail on this list since the end of July.
What's happened?

∂10-Aug-89  0846	ramsdell@linus.mitre.org 	Re: First BASH Meeting (Let's meet at POPL) 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89  08:46:14 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02664; Thu, 10 Aug 89 11:29:43 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA03748; Thu, 10 Aug 89 11:30:47 EDT
Posted-Date: Thu, 10 Aug 89 11:24:43 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA00409; Thu, 10 Aug 89 11:24:46 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908101524.AA00409@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: First BASH Meeting (Let's meet at POPL)
In-Reply-To: Your message of Tue, 08 Aug 89 08:00:51 -0700.
             <8908081500.AA02503@gnomec.pa.dec.com> 
Date: Thu, 10 Aug 89 11:24:43 EDT

>> From:    Joel Bartlett <bartlett@decwrl.dec.com>
...
>> Bay Area Scheme Hackers (BASH) is dedicated to fostering informal
...
And I thought BASH was GNU's Born Again SHell....

>> Uniform definition syntax
>> 
>> Pavel spoke in favor of his earlier proposal to rrrs-authors on 22 jun 89:
>> 

>> Jinx spoke in favor of the status quo, i.e. the incremental nature of top
>> level expression evaluation as noted in section 5.1 of R3RS.

I am glad to see the issue get such a hearing.  Thanks also to Will
for his explaination of his position.  I favor dropping the issue for
consideration for R4RS.

>> Meta Issue - rrrs-authors
>> 
...
>> Resolved:  it would be nice if rrrs-authors worked better.  It may be time
>> for another rrrs-authors meeting.  Perhaps at POPL in San Francisco.

I would also like to see another rrrs-authors meeting as long as it is
not an R4RS meeting.  I would like to see R4RS out before the end of
this year.  R4RS should include name regularization, but if the macros
factions fail to agree, let's drop macros.

There seems to be a fair number of good solid proposals for
consideration in R5RS.  Fluid variables and multiple values come
immediately to mind.  Maybe we could get some agreement at POPL.

John

∂10-Aug-89  0902	@mc.lcs.mit.edu,@life.ai.mit.edu:jinx@hpesogg.hp.com 	R3.99RS issues (macros in R4RS)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89  08:58:49 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA02784; Thu, 10 Aug 89 11:43:17 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa20791;
          9 Aug 89 17:17 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU  9 Aug 89 17:16:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa20742;
          9 Aug 89 17:10 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06002; Wed, 9 Aug 89 17:10:48 EDT
Received: from sde.hp.com (sde.hp.com) by zurich.ai.mit.edu; Wed, 9 Aug 89 17:07:29 edt
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA04260; Wed, 9 Aug 89 14:10:30 pdt
Message-Id: <8908092110.AA04260@sde.hp.com>
Received: by hpesogg; Wed, 9 Aug 89 14:09:55 pdt
Date: Wed, 9 Aug 89 14:09:55 pdt
From: "Guillermo J. Rozas" <jinx@hpesogg.hp.com>
To: shaff@sesame.stanford.edu
Cc: rrrs-authors@zurich.ai.mit.edu
In-Reply-To: Mike Shaff's message of Tue, 8 Aug 89 09:56:26 PDT <8908081656.AA03492@sesame.Stanford.EDU>
Subject: R3.99RS issues (macros in R4RS)
Reply-To: jinx%hpesogg@sde.hp.com

   Date: Tue, 8 Aug 89 09:56:26 PDT
   From: Mike Shaff <shaff@sesame.stanford.edu>


   ciao,

   Will>The plan is for the R4RS (but not the R3.99RS) will have an appendix that
   Will>describes (at least) two incompatible macro proposals and the issues that
   Will>have prevented them from being resolved; this should be the only
   Will>substantial difference between the R3.99RS and the R4RS.

   I am in strong disagreement with the inclusion of two appendices, as the net
   effect will be an unfair evaluation of the issues by the user community.
   Syntactic closures without a user interface will not be 'user friendly', but I
   believe addresses the issues that are important.  Extend-syntax has many nice
   properties, but does NOT address the issues that are important to me.  I can
   not believe that a compromise is not attainable by the macro committee.  I
   implore the committee and other interested parties to resolve this divisive
   issue.

   To make the point totally clear I believe that R4RS should NOT be issued until
   this issue is resolved with ONE decision.

Hear, hear!

∂10-Aug-89  1246	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	Dynamic variables    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89  12:46:04 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04123; Thu, 10 Aug 89 15:28:53 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa02141;
          10 Aug 89 11:40 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 10 Aug 89 11:39:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa02101;
          10 Aug 89 11:38 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02750; Thu, 10 Aug 89 11:38:00 EDT
Received: from RELAY.CS.NET (relay.cs.net) by zurich.ai.mit.edu; Thu, 10 Aug 89 11:34:32 edt
Received: from tektronix.tek.com by RELAY.CS.NET id aa14063; 10 Aug 89 11:37 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
	id AA22625; Thu, 10 Aug 89 08:39:25 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
	id AA06474; Thu, 10 Aug 89 08:35:33 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
	id AA11137; Thu, 10 Aug 89 08:39:47 PDT
Date: Thu, 10 Aug 89 08:39:47 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908101539.AA11137@tekchips.LABS.TEK.COM>
To: mkatz%sesame.stanford.edu@relay.cs.net
Cc: RRRS-Authors@zurich.ai.mit.edu
In-Reply-To: Morris Katz's message of Wed, 9 Aug 89 08:43:47 PDT <8908091543.AA07848@sesame.Stanford.EDU>
Subject: Dynamic variables


I find it bothersome that something called a "variable" can be the
result of an evaluation.

-Norman


∂10-Aug-89  1332	mkatz@sesame.stanford.edu 	First BASH Meeting (Let's meet at POPL)    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89  13:32:07 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04678; Thu, 10 Aug 89 16:11:07 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA00461; Thu, 10 Aug 89 10:56:41 PDT
Date: Thu, 10 Aug 89 10:56:41 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908101756.AA00461@sesame.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Thu, 10 Aug 89 11:24:43 EDT <8908101524.AA00409@huxley.mitre.org>
Subject: First BASH Meeting (Let's meet at POPL)

   Posted-From: The MITRE Corp., Bedford, MA
   X-Alternate-Route: user%node@mbunix.mitre.org
   Posted-Date: Thu, 10 Aug 89 11:24:43 EDT
   From: ramsdell@linus.mitre.org
   Date: Thu, 10 Aug 89 11:24:43 EDT

   >> From:    Joel Bartlett <bartlett@decwrl.dec.com>
   R4RS should include name regularization, but if the macros
   factions fail to agree, let's drop macros.

Lets not drop macros.  In my opinion, macros are probably the most important
addition to R3RS which justify creating an R4RS.  R4RS without macros is a
quasi-worthless document.  How about if we all just agree to come to a decision
on this issue.  Sooner or later Scheme must have macros or die.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂10-Aug-89  1625	shaff@sesame.stanford.edu 	First BASH Meeting (macros) 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 10 Aug 89  16:25:44 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA07122; Thu, 10 Aug 89 19:10:35 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA00646; Thu, 10 Aug 89 13:41:35 PDT
Date: Thu, 10 Aug 89 13:41:35 PDT
From: shaff@sesame.stanford.edu (Mike Shaff)
Message-Id: <8908102041.AA00646@sesame.Stanford.EDU>
To: rrrs-authors@life.ai.mit.edu
In-Reply-To: Morris Katz's message of Thu, 10 Aug 89 10:56:41 PDT <8908101756.AA00461@sesame.Stanford.EDU>
Subject: First BASH Meeting (macros)


'Give me macros or give me death'
				- Macromancer

∂12-Aug-89  0228	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	Re:  Dynamic variables 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Aug 89  02:28:22 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00848; Sat, 12 Aug 89 05:14:22 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22338;
          11 Aug 89 16:35 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Aug 89 16:31:40 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22223;
          11 Aug 89 16:29 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20174; Fri, 11 Aug 89 16:29:50 EDT
Received: from skinner.cs.uoregon.edu ([128.223.4.13]) by zurich.ai.mit.edu; Fri, 11 Aug 89 16:26:29 edt
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
	(5.59++/IDA-1.2.8) id AA05479; Fri, 11 Aug 89 12:53:55 PDT
Received: by spencer.cs.uoregon.edu; Fri, 11 Aug 89 12:53:47 PDT
Date: Fri, 11 Aug 89 12:53:47 PDT
From: will@cs.uoregon.edu
Message-Id: <8908111953.AA08745@spencer.cs.uoregon.edu>
To: Pavel.pa@xerox.com, RRRS-Authors@zurich.ai.mit.edu
Subject: Re:  Dynamic variables

Pavel observed that DYNAMIC-WIND sufficed to implement a portable
shallow-binding implementation of the BASH proposal for all
single-processor implementations of Scheme, but claimed that
multiprocessor implementations will have to implement it more
primitively.

I observe that DYNAMIC-WIND suffices to implement a portable
deep-binding implementation of the BASH proposal.  It seems to
me that this deep-binding implementation should work for most
multiprocessor implementations as well, provided the "right"
relationship exists between processes and continuations.  Some
multiprocessor implementations might want to implement things
more primitively, either for efficiency or because their view
of what is right differs from mine.

Neither the deep-binding nor the shallow-binding implementation
in terms of DYNAMIC-WIND seems capable of supporting a tail-call
semantics for CALL-WITH-DYNAMIC-BINDING.

Peace, Will

∂12-Aug-89  1538	@mc.lcs.mit.edu,@life.ai.mit.edu:danvy@gang-of-four.stanford.edu 	Re:  Dynamic variables  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 12 Aug 89  15:38:25 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04664; Sat, 12 Aug 89 18:18:59 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa04565;
          12 Aug 89 15:13 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 12 Aug 89 15:13:44 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa04545;
          12 Aug 89 15:08 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03649; Sat, 12 Aug 89 15:08:01 EDT
Received: from gang-of-four.Stanford.EDU (gang-of-four.stanford.edu) by zurich.ai.mit.edu; Sat, 12 Aug 89 15:04:43 edt
Received:  by gang-of-four.Stanford.EDU (5.0/25-eef) id AA12068; Sat, 12 Aug 89 12:07:33 PDT
Date: Sat, 12 Aug 89 12:07:33 PDT
From: Olivier Danvy <danvy@gang-of-four.stanford.edu>
Message-Id: <8908121907.AA12068@gang-of-four.Stanford.EDU>
To: will@cs.uoregon.edu
Subject: Re:  Dynamic variables
Cc: RRRS-Authors@zurich.ai.mit.edu


Will>Neither the deep-binding nor the shallow-binding implementation
Will>in terms of DYNAMIC-WIND seems capable of supporting a tail-call
Will>semantics for CALL-WITH-DYNAMIC-BINDING.

	Unless, as usual, one is willing to test at such tail-calls
	whether they redefine a dynamic variable, and if they do,
	one does -not- save the corresponding binding since it would
	be restored uselessly.
	Price: more tests at runtime.
	Evaluation: (1) calling and dynamically binding infinitely many
	variables is not properly tail-recursive since only tail-recursive
	calls that re-bind a variable can be performed properly;
	(2) calling with N (N is finite) different dynamic variables
	is properly tail-recursive "modulo" N.

	So a "tail-call semantics" for CALL-WITH-DYNAMIC-BINDING is possible.
	Most French Lisp systems actually used this technique.


					Olivier

∂13-Aug-89  0537	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Dynamic variables 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 13 Aug 89  05:37:35 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA01697; Sun, 13 Aug 89 08:30:44 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22411;
          11 Aug 89 16:42 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Aug 89 16:42:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22366;
          11 Aug 89 16:39 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20395; Fri, 11 Aug 89 16:39:16 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 11 Aug 89 16:35:51 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 11 AUG 89 13:35:43 PDT
Date: Fri, 11 Aug 89 13:37:00 PDT
From: Pavel.pa@xerox.com
Subject: Re: Dynamic variables
In-Reply-To: <8908111953.AA08745@spencer.cs.uoregon.edu>
To: will@cs.uoregon.edu
Cc: RRRS-Authors@zurich.ai.mit.edu
Message-Id: <890811-133543-9589@Xerox>

I'm afraid that I either don't see your ``right'' relationship or don't see
how to do the implementation.  Could you be more explicit?

Also, if the deep binding is implemented more primitively, then you can
achieve tail-call semantics for CALL-WITH-DYNAMIC-BINDING; you simply
maintain the dynamic environment as an argument passed to every procedure.
CALL-WITH-DYNAMIC-BINDING then has an obvious implementation that
tail-calls the given thunk.  I can't tell if this is in contradiction to
your final paragraph; perhaps you mean that the portable deep-binding
implementation you have in mind does not support tail-call semantics.

	Pavel

∂13-Aug-89  2354	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Re: Dynamic variables 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 13 Aug 89  23:54:15 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA00213; Mon, 14 Aug 89 02:44:21 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa22730;
          11 Aug 89 16:58 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Aug 89 16:59:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa22562;
          11 Aug 89 16:47 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20561; Fri, 11 Aug 89 16:47:26 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 11 Aug 89 16:44:00 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 11 AUG 89 13:46:55 PDT
Date: Fri, 11 Aug 89 13:48:13 PDT
From: Pavel.pa@xerox.com
Subject: Re: Dynamic variables
In-Reply-To: <8908101539.AA11137@tekchips.LABS.TEK.COM>
To: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Cc: RRRS-Authors@zurich.ai.mit.edu
Message-Id: <890811-134655-9610@Xerox>

    I find it bothersome that something called a "variable" can be the
    result of an evaluation.

In some terminologies, the procedure CONS returns a pair of two variables;
that is, the word ``variable'' is synonymous with ``location''.  I don't
particularly subscribe to that point of view, however.

Perhaps ``dynamic variable'' is a misnomer.  Consider the environment and
store:

	env: (1) --> (2)
	store (2) --> (3)

I think that it's reasonably well-established that (2) is the set of
``locations'' and (3) is the set of ``values''.  In lexical environments,
(1) is usually referred to as the set of ``identifiers''.  One possibility
therefore is to change the specification to say that MAKE-DYNAMIC returns a
``dynamic identifier''.  This doesn't quite sound right to me, though.  How
about ``dynamic names''?  I guess I don't really care what these frobs are
called.

My main concerns are that shared-memory multiprocessors are not
discriminated against and that the semantics of the rest of the language
not change dramatically with the addition of dynamic binding.  The BASH
proposal grew out of my only idea satisfying these two concerns.

	Pavel

∂14-Aug-89  0829	@mc.lcs.mit.edu,@life.ai.mit.edu:halstead@crl.dec.com 	Re: Arg evaluation order 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Aug 89  08:28:56 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03007; Mon, 14 Aug 89 11:17:31 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa25164;
          11 Aug 89 20:03 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 11 Aug 89 20:04:35 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa25050;
          11 Aug 89 19:58 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA24767; Fri, 11 Aug 89 19:42:05 EDT
Received: from decwrl.dec.com (decwrl.dec.com) by zurich.ai.mit.edu; Fri, 11 Aug 89 19:38:43 edt
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	id AA03741; Fri, 11 Aug 89 16:41:23 PDT
Received: from crl.crl.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	for rrrs-authors@zurich.ai.mit.edu; id AA03741; Fri, 11 Aug 89 16:41:23 PDT
Received: by crl.crl.dec.com (5.57/Ultrix2.4-C)
	id AA21422; Fri, 11 Aug 89 18:34:11 EDT
Message-Id: <8908112233.AA08043@urmel.DEC.COM>
To: andy@ads.com
Cc: rrrs-authors@zurich.ai.mit.edu, rhh@hx.lcs.mit.edu
Subject: Re: Arg evaluation order 
In-Reply-To: Your message of Thu, 13 Jul 89 22:28:54 -0400.
             <8907140228.AA05095@crl.crl.dec.com> 
Date: Fri, 11 Aug 89 18:33:30 EDT
From: halstead@crl.dec.com

This is a response to a rather old message -- but then again, a file
system lossage recently reset my state to July 17, causing me to take
a fresh look at some then-pending mail messages (and then the first
time I tried to send this message it bounced):

> Jinx writes:

> 	The problem is that there are perfectly portable sequential programs
> 	which work when ANY sequential order is used, but not when
> 	interleaved.  Consider, for example, ...

> Now, a compiler should be able trivially to determine that node-mark!
> is a (potential) mutator, and hence that count-nodes! is a mutator; 
> thus determining that there is a race condition just in case
> 	(eq? (node-left graph-node) (node-right graph-node))
> is straightforward, ....

Your argument here seems to be devoted to whether a compiler can tell
that, in this case, a parallel execution could yield a result different
from that of any legal sequential execution.
I don't think anybody is trying to *prevent* a Scheme implementation
from working in parallel, if it can prove that the result of such
operation will be equivalent to that of a legal sequential execution.
The issue here is whether the Scheme specification should be weakened
so as to include as a legal execution order the kind of interleaving
that Jinx's example highlights.  I agree completely with Jinx that this
would be a radical change and would cause great difficulty in writing
portable programs.  You can invent a language that is like Scheme in
every respect except that it relaxes this restriction (I have, in fact),
but that's different enough that you shouldn't call it Scheme.
						-Bert Halstead



∂14-Aug-89  1634	@mc.lcs.mit.edu,@life.ai.mit.edu,@zurich.ai.mit.edu,@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	Re: Dynamic variables  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 14 Aug 89  16:34:26 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA08658; Mon, 14 Aug 89 19:22:18 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa28953;
          14 Aug 89 19:19 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 14 Aug 89 19:19:07 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa28929;
          14 Aug 89 19:15 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08586; Mon, 14 Aug 89 19:15:08 EDT
Received: from oregon.uoregon.edu (oregon.uoregon.edu) by zurich.ai.mit.edu; Mon, 14 Aug 89 19:11:40 edt
Received: from spencer.cs.uoregon.edu by oregon.uoregon.edu; Mon, 14 Aug 89
 16:13 PDT
Received: by spencer.cs.uoregon.edu; Mon, 14 Aug 89 16:14:27 PDT
Date: Mon, 14 Aug 89 16:14:27 PDT
From: will@cs.uoregon.edu
Subject: Re: Dynamic variables
To: Pavel.pa@xerox.com
Cc: RRRS-Authors@zurich.ai.mit.edu
Message-Id: <8908142314.AA27913@spencer.cs.uoregon.edu>

  I'm afraid that I either don't see your ``right'' relationship or don't see
  how to do the implementation.  Could you be more explicit?

No.  I goofed.  Sorry about that.

Peace, Will

∂15-Aug-89  1812	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #177 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 15 Aug 89  18:12:26 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA10069; Tue, 15 Aug 89 20:28:39 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26313;
          10 Aug 89 1:02 EDT
Date: 10 AUG 89  00:06:51 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #177 
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id:  <8908100102.aa26313@mintaka.lcs.mit.edu>

Scheme Digest #177                             10 AUG 89  00:06:51 EDT

Today's Topics:

        "Scheme has data types and Lisp doesn't."
        functional command shells?

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

Date: 9 Aug 89 16:00:44 GMT
From: Dan Weinreb <odi!valens!dlw@uunet.uu.net>
Subject: Re: "Scheme has data types and Lisp doesn't."
Message-Id: <410@odi.ODI.COM>

In article <13046@well.UUCP> nagle@well.UUCP (John Nagle) writes:

This is very confused.  It's hard to know where to begin.

	It's more of an MIT vs the rest of the LISP world tradition.

If you are contrasting Lisp and Scheme, it's hard to see how this can
be a conflict between MIT and the rest of the Lisp world.  Scheme is
from MIT.  Traditionally, the Lisps with the best numeric support,
compared to other Lisps, are *also* from MIT (particularly the NCOMPLR
for Maclisp).

   Although Common LISP has data type declarations of a sort, they tend
   not to be taken all that seriously by compilers.  

This is not the case.  Many major Lisp compilers for standard
hardware, such as Lucid and Franz, pay close attention to numeric
declarations, and produce far better numeric code when the
declarations are present.

						     CLTL is very weak
   on this subject: 

Yes; this is intentional.  The idea is to accomodate both standard
hardware, for which the declarations are needed, and Lisp machines,
for which they are superfluous.

		    There's a faction in the LISP world that feels that
   floating point is unimportant.  The strongest expression of this feeling
   was in the early Symbolics machines, which lacked floating point hardware.

What?  The reason that the Symbolics LM-2 lacked floating point
hardware had nothing to do with a "strong expression of a feeling"; it
was due to marketing timing and economics.  The LM-2 was just a
repackaged MIT prototype, and the idea was to get it shipped as fast
as possible, reserving improvements for later hardware platforms.
Machines that were actually designed by Symbolics all had floating
point accelerators, generally based on Weitek floating point chips.
Symbolics typically did very well in Lisp floating point benchmarks.
Furthermore, I know of no "faction" anywhere in the Lisp world that
claims that floating point is unimportant.

   Much of the weakness on typing in Common Lisp reflects lobbying from the
   Symbolics faction, which generally supported the idea that everything
   possible should be dynamic.

That the language should not REQUIRE declarations.  And it didn't
require any lobbying; the conventional-hardware faction agreed with
the philosophy that declarations should be optional hints from the
user to the compiler.  Guy Steele, Richard Gabriel, and Scott Fahlman
never have advocated mandatory declarations of the types of variables
in Lisp.  There was plenty of lobbying during the design of Common Lisp,
but not about this point.

	Reading section 4.5 of CLTL (Common Lisp, the Language) will give
   you a good feeling of the weakness of the commitment to strong typing
   in Common Lisp.

You bet.  There is no committment to "strong typing" (typed variables)
in Common Lisp.  This is very much intentional.

	What people tend to actually implement are systems in which all objects
   are "LISP objects", and are still individually allocated and pointed to.

Yes, in the general case.

   Defining an array of "short-float" is likely to generate an array of pointers
   to LISP objects.  

Nope.  Not on Symbolics machines and not on the conventional-machine
implementations that I'm aware of.  Lisp objects are not always
implemented as pointers; they can be stored "immediately".  The
technique of doing this for numbers is nicknamed "inums" and has been
around for at least 15 years.

And none of this has anything to do with the original query, since
Lisp and Scheme are essentially the same in these regards.  Scheme
doesn't have typed variables, either.

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

Date: 10 Aug 89 00:05:06 GMT
From: "Peter R. Ham" <shelby!polya!Polya.Stanford.EDU!ham@decwrl.dec.com>
Subject: functional command shells?
Message-Id: <HAM.89Aug9170506@Polya.Stanford.EDU>

Are any of these shells, like fsh, available?
--
Peter Ham			PO Box 3430	(h)(415) 324-9645
MS Computer Science Student	Stanford, CA	ham@polya.stanford.edu
Stanford University 		94309		(o)(415) 723-2067

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

End of Scheme Digest
********************

∂20-Aug-89  1056	@mc.lcs.mit.edu,@life.ai.mit.edu:Pavel.pa@xerox.com 	Programmer-defined data types   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Aug 89  10:55:58 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03709; Sun, 20 Aug 89 13:37:59 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa05421;
          18 Aug 89 21:38 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 18 Aug 89 21:38:47 EDT
Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa05374;
          18 Aug 89 21:35 EDT
Received: from zurich.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA10884; Fri, 18 Aug 89 21:34:46 EDT
Received: from Xerox.COM (xerox.com) by zurich.ai.mit.edu; Fri, 18 Aug 89 21:31:16 edt
Received: from Cabernet.ms by ArpaGateway.ms ; 18 AUG 89 18:34:07 PDT
Date: Fri, 18 Aug 89 18:36:26 PDT
From: Pavel.pa@xerox.com
Subject: Programmer-defined data types
To: RRRS-Authors@zurich.ai.mit.edu
Cc: Pavel.pa@xerox.com
Message-Id: <890818-183407-4872@Xerox>

This is the proposal for adding records (aka programmer-defined data types,
aka opaque types) to Scheme, as approved by consensus at the first meeting
of BASH.  It is derived from discussion at that meeting and messages to
RRRS-Authors on 8 Jul 87 and 26 May through 7 Jun 88.

I apologize in advance for the verbosity of the description; no good
precision-preserving abbreviations occurred to me as I was writing it up.

We propose adding the following procedures to Scheme:

(MAKE-RECORD-TYPE type-name slot-names)

Returns a ``record-type descriptor'', a value representing a new data type,
disjoint from all others.  The type-name argument must be a string, but is
only used for debugging purposes (such as the printed representation of a
record of the new type).  The slot-names argument is a list of symbols
naming the ``slots'' of a record of the new type.  It is an error if the
list contains any duplicates.

(RECORD-CONSTRUCTOR rtd)

Returns a procedure for constructing new members of the type represented by
rtd.  The returned procedure accepts exactly as many arguments as there
were slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd; these are used, in order, as the initial values of
those slots in a new record, which is returned by the constructor
procedure.

(RECORD-PREDICATE rtd)

Returns a procedure for testing membership in the type represented by rtd.
The returned procedure accepts exactly one argument and returns a true
value if the argument is a member of the indicated record type; it returns
a false value otherwise.

(RECORD-ACCESSOR rtd slot-name)

Returns a procedure for reading the value of a particular slot of a member
of the type represented by rtd.  The returned procedure accepts exactly one
argument which must be a record of the appropriate type; it returns the
current value of the slot named by the symbol slot-name in that record.
The symbol slot-name must be a member of the list of slot-names in the call
to MAKE-RECORD-TYPE that created the type represented by rtd.

(RECORD-UPDATER rtd slot-name)

Returns a procedure for writing the value of a particular slot of a member
of the type represented by rtd.  The returned procedure accepts exactly two
arguments: a record of the appropriate type and an arbitrary Scheme value;
it modifies the slot named by the symbol slot-name in that record to
contain the given value.  The returned value of the updater procedure is
unspecified.  The symbol slot-name must be a member of the list of
slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd.

(RECORD? obj)

Returns a true value if obj is a record of any type and a false value
otherwise.

(RECORD-TYPE-DESCRIPTOR record)

Returns a record-type descriptor representing the type of the given record.
That is, for example, if the returned descriptor were passed to
RECORD-PREDICATE, the resulting predicate would return a true value when
passed the given record.  Note that it is not necessarily the case that the
returned descriptor is the one that was passed to RECORD-CONSTRUCTOR in the
call that created the constructor procedure that created the given record.

(RECORD-TYPE-NAME rtd)

Returns the type-name associated with the type represented by rtd.  The
returned value is EQV? to the type-name argument given in the call to
MAKE-RECORD-TYPE that created the type represented by rtd.

(RECORD-TYPE-SLOT-NAMES rtd)

Returns a list of the symbols naming the slots in members of the type
represented by rtd.  The returned value is EQUAL? to the slot-names
argument given in the call to MAKE-RECORD-TYPE that created the type
represented by rtd.

=====================
Notes on the proposal
=====================

[Some of the notes below are taken from the discussion in 1988.]

-- The only significant difference between this proposal and the one made
by Jonathan Rees in his message of 26 May 88 is the inclusion of procedures
to ``inspect'' records.  These procedures were referred to as
``abstraction-breaking'' in Jonathan's proposal.

-- The procedure RECORD? is necessary to allow reliable use of the
procedure RECORD-TYPE-DESCRIPTOR.

-- The type-name argument to MAKE-RECORD-TYPE is constrained to be a string
in order to allow experimentation with interesting semantics for other
kinds of values there.  One possibility raised in the discussion in 1988
was some kind of a ``handler'' procedure, as in T objects.

-- We do not propose any general macro for the definition of record types.
The feeling is that this is not easy to do in a way that is both elegant
and sufficiently flexible.  Once we have macros, the primitives above
should be sufficient for portable experimentation.

-- Should there be a RECORD-COPIER procedure?  Some folks would like to
have one for performance and convenience; others point out that a copier
for any particular type is easy to write.  In fact, given the inspection
primitives above, one can even write a somewhat slow but general record
copying procedure that works on all types.

-- The issues of subtyping and inheritance, print methods, and integration
with modules and/or
environments (e.g. Pascal's WITH construct) have been purposely avoided in
order to achieve more rapid consensus.  Designs for adding single
inheritance appeared in the discussion in 1988.

-- A case can be made that constructor procedures should take no arguments
and leave all slots in new records uninitialized.  There appear to be
advantages to both points of view.

-- It is probably easy to agree on how EQ? and EQV? treat records; they
should be treated in the same way as pairs, vectors, and strings.  The
consensus of those I've spoken to concerning EQUAL? is that it should be
equivalent to EQV? on records, instead of treating them as it treats
vectors, pairs, and strings.  I have no opinion on the subject and look
forward to hearing any alternative points of view.

	Pavel

∂21-Aug-89  1359	ramsdell@linus.mitre.org 	Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89  13:59:11 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA04683; Mon, 21 Aug 89 16:40:08 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA07583; Mon, 21 Aug 89 08:15:41 EDT
Posted-Date: Mon, 21 Aug 89 08:15:36 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA07557; Mon, 21 Aug 89 08:15:38 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908211215.AA07557@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Multiple values for R4RS.
Date: Mon, 21 Aug 89 08:15:36 EDT

Maybe there is enough consensus to allow agreement on the
non-controversial aspects of multiple values for R4RS.  What do people
think about adding only VALUES and APPLY-VALUES?

-----------------Adapted from Mike Shaff <shaff@sesame.stanford.edu>.

(values obj ...)                                        essential procedure

Returns 0 or more values to a receiving procedure (See apply-values).

        (values)        =>              returns zero (no) values

        (values 1)      =>              returns a single value, 1

        (values 1 'a) 	=>              returns two values, 1 and the symbol a


(apply-values receiver generator)      			essential procedure

Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments.  It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.

        (apply-values cons
               (lambda ()
                 (values 1 2)))         =>              (1 . 2)

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

Note:  I think a useful extension of apply-values is

(apply-values receiver generator . generator-args)

Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with 'generator-args'.  It
is an error if 'receiver' cannot be applied to the number of values
returned by 'generator' or if 'generator' cannot be called with the
number of values in 'generator-args'.


John

∂21-Aug-89  1450	cph@zurich.ai.mit.edu 	Multiple values for R4RS.  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89  14:50:32 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05287; Mon, 21 Aug 89 17:37:04 EDT
Received: from localhost by zurich.ai.mit.edu; Mon, 21 Aug 89 17:33:49 edt
Date: Mon, 21 Aug 89 17:33:49 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8908212133.AA24382@zurich.ai.mit.edu>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 21 Aug 89 08:15:36 EDT <8908211215.AA07557@huxley.mitre.org>
Subject: Multiple values for R4RS.

   From: ramsdell@linus.mitre.org
   Date: Mon, 21 Aug 89 08:15:36 EDT

   Maybe there is enough consensus to allow agreement on the
   non-controversial aspects of multiple values for R4RS.  What do people
   think about adding only VALUES and APPLY-VALUES?

I'm not sure how this circumvents the "controversial" aspects.  As I
understood it, the controversy had to do with the semantics of how
VALUES interacted with the continuation in effect where it was called.

   [...]

   (apply-values receiver generator)

I've been using a similar interface for multiple values for about a
year now, the major difference being that instead of `apply-values'
there is an operation `with-values' which has these two arguments in
the opposite order.  I think the order of arguments is somewhat
important: `with-values' orders the generator and receiver so that
they are executed in the same order in which they appear
(left-to-right), while `apply-values' executes them in the opposite
order.  I think `with-values' is significantly easier to read; I'd
favor having the arguments appear in that order, even though it screws
up the "generator arguments" extension (sorry, I don't find that
extension very interesting).  This is (at least part of) the same
reasoning that makes `let' easier to read than its `lambda' expansion.

∂21-Aug-89  1539	harris%hplwhh@hplabs.hp.com 	Re: Multiple values for R4RS.  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89  15:39:28 PDT
Received: from hplms2.hpl.hp.com by life.ai.mit.edu (4.1/AI-4.10) id AA05826; Mon, 21 Aug 89 18:24:52 EDT
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Mon, 21 Aug 89 14:26:10 pdt
Received: from localhost by hplwhh.HPL.HP.COM; Mon, 21 Aug 89 15:23:37 pdt
Message-Id: <8908212223.AA14032@hplwhh.HPL.HP.COM>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS. 
In-Reply-To: Your message of "Mon, 21 Aug 89 08:15:36 EDT."
             <8908211215.AA07557@huxley.mitre.org> 
Date: Mon, 21 Aug 89 15:23:33 PDT
From: Warren Harris <harris%hplwhh@hplabs.hp.com>

Your proposal doesn't say what happens when the number of values
expected by the receiver is different from the number the generator
produces.  A simple case is when multiple values are returned and one
is expected:

	(cons (values 1 2) 3)
	=> (1 . 3)
	=> (<?> . 3)
	=> <error>

In the case of most functions (like CONS), I favor signaling an error,
but I can imagine some cases where passing multiple values as a single
parameter into a function should be permitted.

My argument stems from my discontent with Common Lisp when I have to
write code like:

	(let ((a (foo)))
	  (multiple-value-bind (b c d)
	      (bar)
	    (let ((e (baz)))
	      ...)))

when I would much prefer to write:

	(let* ((a (foo))
	       ((b c d) (bar))
	       (e (baz)))
	  ...)

Granted, this can be accomplished by extending the syntax of LET*,
which in Scheme would expand to:

	(let ((a (foo)))
	  (apply-values 
	    (lambda (b c d)
	      (let ((e (baz)))
	        ...))
	    (bar)))

but the same is not true of LET:

	(let ((a (foo))
	      ((b c d) (bar))
	      (e (baz)))
	  ...)

	-->

	((lambda (a (b c d) e)
	   ...)
	 (foo)
	 (bar)
	 (baz))

This suggests an extension of LAMBDA in which it may be specified that
multiple values can be passed in by a single parameter.  In addition
to the conciseness this permits with LET and LET*, one could also
imagine writing code with this extended LAMBDA such as:

	(define foo 
	  (lambda (a (b c))
	    (list a b c)))

	(foo 1 (values 2 3))
	=> (1 2 3)

	(foo 1 2)
	=> <error>


---PROPOSAL---------------------------------------------------------------------

(LAMBDA <formals> <body>)			essential syntax

<formals> ::=   <variable>
              | (<var/values>*)
              | (<var/values>+ . <variable>)

<var/values> ::=   <variable>			; single value
                 | (<var/values>*)		; multiple values


(LET (<binding spec>*) <body>)			essential syntax
(LET* (<binding spec>*) <body>)			essential syntax

<binding spec> ::= (<var/values> <expression>)


(VALUES . <expression>*)			essential procedure

(APPLY-VALUES <receiver> <generator>)		essential procedure

- with appropriate error messages when numbers of values mismatch.
- also suggest renaming APPLY to APPLY-LIST.

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

Note that:
	
	(apply-values (lambda (a b c) ...) (foo))

is equivalent to:

	((lambda ((a b c)) ...) (foo))


I realize that the cost to implementors is much higher for this
proposal, but I think the power and conciseness of expression
justifies it.

Warren Harris

∂21-Aug-89  1543	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89  15:43:31 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05856; Mon, 21 Aug 89 18:28:47 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa09616;
          21 Aug 89 11:39 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 21 Aug 89 11:39:08 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa09594;
          21 Aug 89 11:36 EDT
Received: from fafnir.think.com by Think.COM; Mon, 21 Aug 89 11:37:17 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 21 Aug 89 11:34:48 EDT
Received: by verdi.think.com; Mon, 21 Aug 89 11:34:37 EDT
Date: Mon, 21 Aug 89 11:34:37 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908211534.AA29201@verdi.think.com>
To: Alan@reagan.ai.mit.edu
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Alan Bawden's message of Thu, 27 Jul 89 21:15 EDT <19890728011525.2.ALAN@PIGPEN.AI.MIT.EDU>
Subject: Numbers

I'm back from an exhausting, and therefore very restful, vacation.
Back into the fray!

   Date: Thu, 27 Jul 89 21:15 EDT
   From: Alan Bawden <Alan@reagan.ai.mit.edu>

   I wonder, by the way, what those of you who insist that MAX must return
   something EQV? to one of its arguments because "MAX computes -the- maximum
   of a set of numbers", think should be the answer in the case of (MAX 1 1.0)? 

Either 1 or 1.0.  By the same token I believe the result of (MAX 1 1)
may be either occurrence of "1" (by stating it this way I avoid
commmitment on the question of whether the two occurrences of "1" are
the same or not).

Here is a new proposal.  Given a set of points within a partial order,
there are two interesting kinds of "max"-like operation.  One is to find
some point (not necessarily within the set) that is >= all points in the
given set; this is SUP.  In a general poset there may be many such points;
the lattice property guarantees uniqueness.

Another is to find some point in the set such that no point in the set is >
that point.  This can fail for infinite sets, but that cannot occur in
Scheme.  It may also be that there is more than one such point in the set.
In that case we must define some tie-breaking rule (arbitrary choice is one
such rule).  One partial tie-breaking rule that I find appealing is to
choose one of the least exact of otherwise qualified candidates.  I had
earlier proposed to call this second operation MAX.

The new proposal is the call the first kind SUP (as before), and to
call the second kind LARGEST (similarly INF and SMALLEST).  Let Scheme
have no built-in operations called MIN and MAX.

I still believe both kinds of operation are useful.  They reflect two
different points of view about inexact numbers.  One is that they are
shadows of Platonically ideal real numbers, pitifully striving to mirror
the behavior of their exact counterparts and to retain some record of the
degree of their failure.  The other is that they are objects unto
themselves, obeying perfectly an algebraic system that is useful because it
is similar, though not identical, to that for real numbers and much easier
to implement.

Theologically or politically speaking, under the first view inexact numbers
strive to obey laws acknowledged to be perfect, but to a greater or lesser
degree are each in a state of sin.  Under the second view they are all
model citizens, adhering perfectly to their own laws which, however, are
acknowledged not to be ideal but merely the best one can do in this
imperfect and finite world.

--Guy

∂21-Aug-89  1652	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Aug 89  16:52:26 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA06523; Mon, 21 Aug 89 19:38:03 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA24643; Mon, 21 Aug 89 16:37:52 pdt
Message-Id: <8908212337.AA24643@sde.hp.com>
Received: by hpesogg; Mon, 21 Aug 89 16:37:12 pdt
Date: Mon, 21 Aug 89 16:37:12 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 21 Aug 89 08:15:36 EDT <8908211215.AA07557@huxley.mitre.org>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com


    Maybe there is enough consensus to allow agreement on the
    non-controversial aspects of multiple values for R4RS.  What do people
    think about adding only VALUES and APPLY-VALUES?

I don't think they are worth adding if ACCEPTS? is not included as
well.  ACCEPTS? allows a programmer to extend old operations into new
ones which match their continuation.  For example, QUOTIENT can be
cleanly upgraded to return two values when expected, but its old
single value when only one is expected.

The reason Mike and Morry added ACCEPTS? to the proposal is that I
did not consider it interesting without some way of providing the
functionality that I want.

Without ACCEPTS?, their use and functionality can be provided in user
code, although without the error checking or the efficiency of a
"native" implementation.

∂22-Aug-89  0445	ramsdell@linus.mitre.org 	Re: Multiple values for R4RS.     
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  04:44:57 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02147; Tue, 22 Aug 89 07:21:23 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA28804; Tue, 22 Aug 89 07:16:10 EDT
Posted-Date: Tue, 22 Aug 89 07:16:05 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA08527; Tue, 22 Aug 89 07:16:07 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908221116.AA08527@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: Multiple values for R4RS. 
In-Reply-To: Your message of Mon, 21 Aug 89 17:33:49 -0400.
             <8908212133.AA24382@zurich.ai.mit.edu> 
Date: Tue, 22 Aug 89 07:16:05 EDT

>> I'm not sure how this circumvents the "controversial" aspects.  As I
>> understood it, the controversy had to do with the semantics of how
>> VALUES interacted with the continuation in effect where it was called.

Given Shaff's proposal, I thought the controversy was just over
ACCEPTS?.  I thought the "obvious" semantics implied by the
denotational semantics had finally been accepted.  Maybe I am wrong.

>> 
>>    [...]
>> 
>>    (apply-values receiver generator)
>> 
>> I've been using a similar interface for multiple values for about a
>> year now, the major difference being that instead of `apply-values'
>> there is an operation `with-values' which has these two arguments in
>> the opposite order.  

I too prefer the arguments in reverse order so that the most straight
forward extension of apply-values is to make a CPS style call. 

(apply-value generator receiver . generator-args)

or using other names

(apply-values procedure continuation . procedure-args)
[continuation here means a procedure representing a continuation].

I thought the order of arguments is not important enought to stand in
the way of agreement.  Maybe I am wrong.

>> From: Warren Harris <harris%hplwhh@hplabs.hp.com>
>> 
>> Your proposal doesn't say what happens when the number of values
>> expected by the receiver is different from the number the generator
>> produces.  

Sure it does.  It clearly states "it is an error if 'receiver' cannot
be applied to the number of values returned by 'generator' or if
'generator' cannot be called with zero arguments".  Warren, please
reread my proposal.
 
>> From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
>>
>> I don't think they are worth adding if ACCEPTS? is not included as
>> well.  
....
>> Without ACCEPTS?, their use and functionality can be provided in user
>> code, although without the error checking or the efficiency of a
>> "native" implementation.

The point is that by adding just VALUES and APPLY-VALUES, programmers
can depend on the efficiency and error checking of a "native"
implementation. 

John

---- Amended multiple values proposal.

(values obj ...)                                        essential procedure

Returns 0 or more values to a receiving procedure (See apply-values).

        (values)        =>              returns zero (no) values

        (values 1)      =>              returns a single value, 1

        (values 1 'a) 	=>              returns two values, 1 and the symbol a


(apply-values generator receiver)      			essential procedure

Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments.  It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.

        (apply-values 
          (lambda ()
            (values 1 2))
	  cons)   	      =>              (1 . 2)

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

∂22-Aug-89  1052	harris%hplwhh@hplabs.hp.com 	Re: Multiple values for R4RS.  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  10:52:34 PDT
Received: from hplms2.hpl.hp.com by life.ai.mit.edu (4.1/AI-4.10) id AA01885; Tue, 22 Aug 89 13:35:01 EDT
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Tue, 22 Aug 89 09:38:41 pdt
Received: from localhost by hplwhh.HPL.HP.COM; Tue, 22 Aug 89 09:38:26 pdt
Message-Id: <8908221638.AA14520@hplwhh.HPL.HP.COM>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu
Subject: Re: Multiple values for R4RS. 
In-Reply-To: Your message of "Tue, 22 Aug 89 07:16:05 EDT."
             <8908221116.AA08527@huxley.mitre.org> 
Date: Tue, 22 Aug 89 09:38:22 PDT
From: Warren Harris <harris%hplwhh@hplabs.hp.com>

My apologies.  Your proposal certainly does talk about number of
values mismatching.  I guess I got excited about this extended lambda
idea. 

∂22-Aug-89  1130	ramsdell@linus.mitre.org 	Re: Multiple values for R4RS.     
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  11:30:05 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA02350; Tue, 22 Aug 89 14:05:24 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA02873; Tue, 22 Aug 89 14:00:12 EDT
Posted-Date: Tue, 22 Aug 89 14:00:07 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA08733; Tue, 22 Aug 89 14:00:09 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908221800.AA08733@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Re: Multiple values for R4RS. 
In-Reply-To: Your message of Tue, 22 Aug 89 09:43:26 -0700.
             <8908221643.AA01234@sesame.Stanford.EDU> 
Date: Tue, 22 Aug 89 14:00:07 EDT

I cannot figure out what some of you would like me to conclude from
your responses.  My premise is that VALUES and APPLY-VALUES as defined
reflect existing practice in some Scheme dialects, are useful, and are
non-controversial enough to add to R4RS.  Let me suggest some
questions to answer which may help clear up my confusion.

[1] Do you think VALUES and APPLY-VALUES as defined are controversial?
(I understand CPH's view on this issue).

[2] Do you think VALUES and APPLY-VALUES as defined reflect existing
practice?  For example, in T, VALUES = RETURN, and APPLY-VALUES = 
(LAMBDA (X Y) (RECEIVE-VALUES Y X)), and MIT Scheme has the
functionality. 

[3] Do you think VALUES and APPLY-VALUES as defined prohibit the
future inclusion of ACCEPTS? or some other proposal to deal with
incompatiable arities?

[4] Do you believe VALUES and APPLY-VALUES should be excluded from
Scheme solely because there is no agreement on how to deal with
incompatiable arities?

John

---- Amended multiple values proposal.

(values obj ...)                                        essential procedure

Returns 0 or more values to a receiving procedure (See apply-values).

        (values)        =>              returns zero (no) values

        (values 1)      =>              returns a single value, 1

        (values 1 'a) 	=>              returns two values, 1 and the symbol a


(apply-values generator receiver)      			essential procedure

Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments.  It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.

        (apply-values 
          (lambda ()
            (values 1 2))
	  cons)   	      =>              (1 . 2)

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

∂22-Aug-89  1150	mkatz@sesame.stanford.edu 	Multiple values for R4RS.   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  11:50:13 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA02587; Tue, 22 Aug 89 14:25:33 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA01234; Tue, 22 Aug 89 09:43:26 PDT
Date: Tue, 22 Aug 89 09:43:26 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908221643.AA01234@sesame.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 21 Aug 89 08:15:36 EDT <8908211215.AA07557@huxley.mitre.org>
Subject: Multiple values for R4RS.

∂22-Aug-89  1221	dyb@iuvax.cs.indiana.edu 	Re:  Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  12:21:00 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02931; Tue, 22 Aug 89 14:51:14 EDT
Message-Id: <8908221851.AA02931@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu 
Date: Tue, 22 Aug 89 13:51:43 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re:  Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu

Let me take a stab at "quotient-and-maybe-remainder":

    (define quotient-and-maybe-remainder
       (lambda (n1 n2)
          (call/cc
             (lambda (k)
                (if (accepts? k 2)
                    (let ([q (quotient n1 n2)])
                       (let ([r (- n1 (* q n2))])
                          (k q r)))
                    (k (quotient n1 n2)))))))
    
Unless I'm missing something and there is a different way to do this, I
guess I'm not too excited about "accepts?".

The predicate "accepts?" seems a little like the (rejected) predicate
"continuation?".  A procedure may not complain "up front" about a given
number of arguments, but may complain at some later time.  Or it may
accept any number of arguments, but ignore all but the first few.  I
don't see how "accepts?" can be generally useful if it breaks down in
these cases.

   (define kons
      (lambda l
         (apply cons l)))

   (accepts? cons 3) => #f
   (accepts? kons 3) => #t

Kent

∂22-Aug-89  1234	mkatz@sesame.stanford.edu 	Multiple values for R4RS.   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  12:32:52 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA03066; Tue, 22 Aug 89 15:08:15 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA01234; Tue, 22 Aug 89 09:43:26 PDT
Date: Tue, 22 Aug 89 09:43:26 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908221643.AA01234@sesame.Stanford.EDU>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Mon, 21 Aug 89 08:15:36 EDT <8908211215.AA07557@huxley.mitre.org>
Subject: Multiple values for R4RS.

   Posted-From: The MITRE Corp., Bedford, MA
   X-Alternate-Route: user%node@mbunix.mitre.org
   Posted-Date: Mon, 21 Aug 89 08:15:36 EDT
   From: ramsdell@linus.mitre.org
   Date: Mon, 21 Aug 89 08:15:36 EDT

   Maybe there is enough consensus to allow agreement on the
   non-controversial aspects of multiple values for R4RS.  What do people
   think about adding only VALUES and APPLY-VALUES?

In the past, Jinx has given a cogent argument as to why the procedure arity is
important for enabling implementors to experiment with upward compatible
versions of the core language.  In essence, the idea is that one might want to
create an upward compatible version of a function which returns more values
than the one specified in RNRS.  Since our proposal requires that the
return-arity of the generator be compatible with the arity of the receiver,
this can only be done if the generator can determine the arity of the receiver
and return an appropriate number of values.  I personally find this argument
persuasive. 

   Note:  I think a useful extension of apply-values is

   (apply-values receiver generator . generator-args)

This might me a useful addition to the yellow pages; but, I would oppose making
this form op apply-values the required one.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂22-Aug-89  1339	mkatz@sesame.stanford.edu 	Multiple values for R4RS.   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  13:39:32 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA03764; Tue, 22 Aug 89 15:59:21 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA00379; Tue, 22 Aug 89 12:58:10 PDT
Date: Tue, 22 Aug 89 12:58:10 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908221958.AA00379@sesame.Stanford.EDU>
To: cph@zurich.ai.mit.edu
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Chris Hanson's message of Mon, 21 Aug 89 17:33:49 edt <8908212133.AA24382@zurich.ai.mit.edu>
Subject: Multiple values for R4RS.

   Date: Mon, 21 Aug 89 17:33:49 edt
   From: cph@zurich.ai.mit.edu (Chris Hanson)

      From: ramsdell@linus.mitre.org
      Date: Mon, 21 Aug 89 08:15:36 EDT

   I've been using a similar interface for multiple values for about a
   year now, the major difference being that instead of `apply-values'
   there is an operation `with-values' which has these two arguments in
   the opposite order.  

I personally also favor the with-values order of generator and then receiver as
opposed to the apply-values order.  Mike and I chose the apply-values order for
consistency with the regularization of procedures in Scheme.  Since the
regularization of apply has been nixed, there remains no reason for the
apply-values order.
-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂22-Aug-89  1359	mkatz@sesame.stanford.edu 	Multiple values for R4RS.   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  13:59:33 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA03898; Tue, 22 Aug 89 16:10:19 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA00404; Tue, 22 Aug 89 13:09:03 PDT
Date: Tue, 22 Aug 89 13:09:03 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908222009.AA00404@sesame.Stanford.EDU>
To: harris%hplwhh@hplabs.hp.com
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Warren Harris's message of Mon, 21 Aug 89 15:23:33 PDT <8908212223.AA14032@hplwhh.HPL.HP.COM>
Subject: Multiple values for R4RS. 

   Date: Mon, 21 Aug 89 15:23:33 PDT
   From: Warren Harris <harris%hplwhh@hplabs.hp.com>

   Your proposal doesn't say what happens when the number of values
   expected by the receiver is different from the number the generator
   produces.  A simple case is when multiple values are returned and one
   is expected:

	   (cons (values 1 2) 3)
	   => (1 . 3)
	   => (<?> . 3)
	   => <error>

I believe  that we explicitly stated that the return-arity must be compatible
with the arity of the receiver.  If we forget about rest arguments for a
moment, compatible was defined as identical.  In the case above, the arity of
the implicit continuation to cons is 1 and the return-arity of values is 2, so
there is an arity incompatibility.  We proposed that arity incompatibilities
are an error (not signal an error).  This leaves open the ability for some
implementors to create extensions to multiple values which are not strict
without violating RNRS.
extensions that some 

-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂22-Aug-89  1415	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  14:15:36 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA04404; Tue, 22 Aug 89 16:50:49 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA22154; Tue, 22 Aug 89 13:17:22 pdt
Message-Id: <8908222017.AA22154@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 13:16:43 pdt
Date: Tue, 22 Aug 89 13:16:43 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 13:51:43 -0500 <8908221851.AA02931@life.ai.mit.edu>
Subject:  Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com

    The predicate "accepts?" seems a little like the (rejected) predicate
    "continuation?".  A procedure may not complain "up front" about a given
    number of arguments, but may complain at some later time.  Or it may
    accept any number of arguments, but ignore all but the first few.  I
    don't see how "accepts?" can be generally useful if it breaks down in
    these cases.

This is like saying that a given object may pass a PAIR? test yet when
given to a list operation, the operation will flame.  Just because it
does not cover all cases, it does not mean that it is useless.  Are
you advocating for removing PAIR? from the language?

∂22-Aug-89  1432	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  14:31:48 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA04470; Tue, 22 Aug 89 16:59:39 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA22411; Tue, 22 Aug 89 13:31:40 pdt
Message-Id: <8908222031.AA22411@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 13:31:00 pdt
Date: Tue, 22 Aug 89 13:31:00 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, ramsdell@linus.mitre.org
In-Reply-To: ramsdell@linus.mitre.org's message of Tue, 22 Aug 89 14:00:07 EDT <8908221800.AA08733@huxley.mitre.org>
Subject: Multiple values for R4RS. 
Reply-To: jinx%hpesogg@sde.hp.com


    [2] Do you think VALUES and APPLY-VALUES as defined reflect existing
    practice?  For example, in T, VALUES = RETURN, and APPLY-VALUES = 
    (LAMBDA (X Y) (RECEIVE-VALUES Y X)), and MIT Scheme has the
    functionality. 

MIT Scheme does not quite have it.  It is not integrated with
continuations at all (I don't know if T's is either).  I think that it
is not worth putting in, if I cannot accomodate users who would like
Common Lisp style truncation of values, or who want to be able to port
Common Lisp code a little more easily.  I find the backwards
compatibility that "truncation" offers to be the most significant
feature in multiple values, and would use CPS otherwise.

    [3] Do you think VALUES and APPLY-VALUES as defined prohibit the
    future inclusion of ACCEPTS? or some other proposal to deal with
    incompatiable arities?

Certainly not TECHNICALLY, but it is my POLITICAL feeling, that if it
is not accepted as a complete package, it will not be accepted later.
The people who want the "restrictive" multiple values will feel no
pressure to accept it later since they will already have what they
want.  I'm not asking for their semantics to be different (I've
compromised on paranoid checking by default), but I would like a
little compromise on everyone else's part.

I view ACCEPTS? as a harmless little addition, and don't understand
what the fuss is all about.

    [4] Do you believe VALUES and APPLY-VALUES should be excluded from
    Scheme solely because there is no agreement on how to deal with
    incompatiable arities?

That is the reason why they have been excluded up to now.  Perhaps a
compromise is not possible.

∂22-Aug-89  1445	@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	Multiple values for R4RS.   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  14:45:03 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04654; Tue, 22 Aug 89 17:15:52 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
	id AA03014; Tue, 22 Aug 89 17:15:40 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa08811; 22 Aug 89 17:12 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
	id AA20162; Tue, 22 Aug 89 14:15:05 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
	id AA26560; Tue, 22 Aug 89 14:13:00 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
	id AA24785; Tue, 22 Aug 89 14:15:28 PDT
Date: Tue, 22 Aug 89 14:15:28 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908222115.AA24785@tekchips.LABS.TEK.COM>
To: jinx%hpesogg@sde.hp.com
Cc: ramsdell%linus.mitre.org@relay.cs.net,
        rrrs-authors%life.ai.mit.edu@relay.cs.net
Subject: Multiple values for R4RS.


	From: ramsdell@linus.mitre.org
	Maybe there is enough consensus to allow agreement on the
	non-controversial aspects of multiple values for R4RS.  What do people
	think about adding only VALUES and APPLY-VALUES?

I'd take this, or VALUES and WITH-VALUES.

    From: jinx%hpesogg@sde.hp.COM
    I don't think they are worth adding if ACCEPTS? is not included as
    well. ...

This is an extreme position.  The proposed functionality is
useful even in the absence of ACCEPTS?  

    From: Morris Katz <mkatz@sesame.stanford.edu>
    In the past, Jinx has given a cogent argument as to why the 
    procedure arity is important ...

I remain unconvinced.  As a user, I have found multiple values
(without ACCEPTS?) quite useful.  So, I don't think ACCEPTS? provides
super-essential functionality.  As an implementor, I would prefer not
to be committed to keeping around arity information for every
procedure.

-Norman

∂22-Aug-89  1448	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  14:48:32 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AB04683; Tue, 22 Aug 89 17:22:20 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA23597; Tue, 22 Aug 89 14:20:31 pdt
Message-Id: <8908222120.AA23597@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 14:19:50 pdt
Date: Tue, 22 Aug 89 14:19:50 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: adams@tekchips.labs.tek.com
Cc: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu
In-Reply-To: Norman Adams's message of Tue, 22 Aug 89 14:15:28 PDT <8908222115.AA24785@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com


    This is an extreme position.  The proposed functionality is
    useful even in the absence of ACCEPTS?  

It's much less extreme than imposing a particular fascist semantics on
those who don't find it interesting or useful.  Usefulness is an
aesthetic measure, and I find CPS better if I'm going to be fascist.

    I remain unconvinced.  As a user, I have found multiple values
    (without ACCEPTS?) quite useful.  So, I don't think ACCEPTS? provides
    super-essential functionality.  As an implementor, I would prefer not
    to be committed to keeping around arity information for every
    procedure.

You don't have to keep it around for every procedure.  Just those
procedurs that might be given to ACCEPTS? as arguments.  This may seem
silly, but I'm not kidding.  This effectively means that only closures
(and not all of them) need to have this information.  The MIT Scheme
compiler keeps arity information only for procedures that it
determines may be invoked from places that "don't know about them."
This turns out to be but a fraction of the total in typical code.


∂22-Aug-89  1606	mkatz%sesame.stanford.edu@relay.cs.net 	Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  16:06:51 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05225; Tue, 22 Aug 89 18:36:21 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
	id AA03116; Tue, 22 Aug 89 18:36:11 EDT
Received: from sesame.stanford.edu by RELAY.CS.NET id aa12554;
          22 Aug 89 18:36 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA00236; Tue, 22 Aug 89 15:34:50 PDT
Date: Tue, 22 Aug 89 15:34:50 PDT
From: Morris Katz <mkatz%sesame.stanford.edu@relay.cs.net>
Message-Id: <8908222234.AA00236@sesame.Stanford.EDU>
To: adams%tekchips.labs.tek.com@relay.cs.net
Cc: jinx%hpesogg@sde.hp.com, ramsdell%linus.mitre.org@relay.cs.net,
        rrrs-authors%life.ai.mit.edu@relay.cs.net
In-Reply-To: Norman Adams's message of Tue, 22 Aug 89 14:15:28 PDT <8908222115.AA24785@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.

   Date: Tue, 22 Aug 89 14:15:28 PDT
   From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>

   As an implementor, I would prefer not
   to be committed to keeping around arity information for every
   procedure.

I can't imagine how one could create an implementation in which the arity
information is not already present in some form for procedures that are passed
as arguments.  Similarly, implicit continuations had better know something
about the number of values on which they intend to operate.  Retrieving the
arity information may require some bit twiddling, but I suspect that the needed
information is always present in some form.

-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂22-Aug-89  1634	cph@zurich.ai.mit.edu 	Multiple values for R4RS.  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  16:34:29 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05339; Tue, 22 Aug 89 19:06:45 EDT
Received: from localhost by zurich.ai.mit.edu; Tue, 22 Aug 89 19:03:31 edt
Date: Tue, 22 Aug 89 19:03:31 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8908222303.AA04769@zurich.ai.mit.edu>
To: jinx%hpesogg@sde.hp.com
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: Guillermo J. Rozas's message of Tue, 22 Aug 89 14:19:50 pdt <8908222120.AA23597@sde.hp.com>
Subject: Multiple values for R4RS.

   Date: Tue, 22 Aug 89 14:19:50 pdt
   From: Guillermo J. Rozas <jinx@hpesogg.hp.com>

       This is an extreme position.  The proposed functionality is
       useful even in the absence of ACCEPTS?  

   It's much less extreme than imposing a particular fascist semantics on
   those who don't find it interesting or useful.

I agree, with Norman, that the proposed functionality is useful in the
absence of `accepts?'.  However, tossing around words like "extreme"
and "fascist" in this fashion seems hypocritical.  Aside from the
differing emotional charges attached to these phrases, both seem to
have the same purpose: discrediting the opposition by distancing them
from the hypothetical "middle ground" (or "moral majority" if you
prefer the three-red-stars-extra-spicy emotional charge).  Let's try
not to make arguments that presume knowledge of the consensus.

As an aside, I have no objection to implementing `accepts?'; I think
that it is very useful, whether or not you have multiple values.  But
I dislike that particular name because it is too vague; I'd prefer
something more like `procedure-accepts?' or (as in MIT Scheme)
`procedure-arity-valid?'.

       [2] Do you think VALUES and APPLY-VALUES as defined reflect existing
       practice?  For example, in T, VALUES = RETURN, and APPLY-VALUES = 
       (LAMBDA (X Y) (RECEIVE-VALUES Y X)), and MIT Scheme has the
       functionality. 

   MIT Scheme does not quite have it.  It is not integrated with
   continuations at all (I don't know if T's is either).  I think that it
   is not worth putting in, if I cannot accomodate users who would like
   Common Lisp style truncation of values, or who want to be able to port
   Common Lisp code a little more easily.  I find the backwards
   compatibility that "truncation" offers to be the most significant
   feature in multiple values, and would use CPS otherwise.

I disagree with this statement -- multiple values have usefulness
independent of the "truncation" feature, and I feel they are worth
having anyway.  Despite the fact that MIT Scheme's multiple values are
not fully implemented, I have found them quite useful and I have
written much code that uses them.

CL's handling of "extra" values is distasteful to me, because it makes
the standard behavior complicated; I think that values should be
discarded only when that is explicitly stated by the code.  This is
not to say that I would be extremely upset should such a semantics be
adopted, because I would just avoid using "truncation".  But on
aesthetic grounds I would prefer something simpler.

∂22-Aug-89  1713	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  17:13:51 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA05583; Tue, 22 Aug 89 19:44:24 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA27806; Tue, 22 Aug 89 16:44:08 pdt
Message-Id: <8908222344.AA27806@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 16:43:26 pdt
Date: Tue, 22 Aug 89 16:43:26 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: cph@zurich.ai.mit.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: Chris Hanson's message of Tue, 22 Aug 89 19:03:31 edt <8908222303.AA04769@zurich.ai.mit.edu>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com


    CL's handling of "extra" values is distasteful to me, because it makes
    the standard behavior complicated; I think that values should be
    discarded only when that is explicitly stated by the code.  This is
    not to say that I would be extremely upset should such a semantics be
    adopted, because I would just avoid using "truncation".  But on
    aesthetic grounds I would prefer something simpler.

I don't object to this position.  I object to trying to force this
position down my throat.

∂22-Aug-89  1740	@relay.cs.net,@tektronix.tek.com:adams@tekchips.labs.tek.com 	Multiple values for R4RS.   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  17:40:40 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05739; Tue, 22 Aug 89 20:12:27 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
	id AA03209; Tue, 22 Aug 89 20:12:16 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa16619; 22 Aug 89 20:11 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
	id AA26764; Tue, 22 Aug 89 17:13:40 PDT
Received: by tekirl.labs.tek.com (5.51/7.1)
	id AA13649; Tue, 22 Aug 89 17:11:35 PDT
Received: by tekchips.LABS.TEK.COM (5.51/6.24)
	id AA26483; Tue, 22 Aug 89 17:14:03 PDT
Date: Tue, 22 Aug 89 17:14:03 PDT
From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
Message-Id: <8908230014.AA26483@tekchips.LABS.TEK.COM>
To: jinx%hpesogg@sde.hp.com,
        Morris Katz <mkatz%sesame.stanford.edu@relay.cs.net>
Cc: rrrs-authors%life.ai.mit.edu@relay.cs.net, adams@tekchips.labs
In-Reply-To: "Guillermo J. Rozas"'s message of Tue, 22 Aug 89 14:19:50 pdt <8908222120.AA23597@sde.hp.com>
Subject: Multiple values for R4RS.


	From: adams@tekchips.LABS.TEK.COM
	I would prefer not
	to be committed to keeping around arity information for every
	procedure.

    From: jinx@hpesogg.hp.COM
    You don't have to keep it around for every procedure.  

I know.  And this is a side issue.  I want multiple values, and I don't
want to get hung up on ACCEPTS?.

If you are interested in the side issue, here are my thoughts:

The requirement that some procedures support ACCEPTS? still imposes
constraints on the implementation.  You must have a representation of
procedures that can support ACCEPTS?  As an implementor, this is the
sort of language-imposed restriction I have found useful to eliminate.

    From: mkatz%sesame.stanford.edu
    I can't imagine how one could create an implementation in which the arity
    information is not already present in some form for procedures that 
    are passed

Sure, it is present in some form.

Perhaps each procedure is responsible for coping with wrong number of
arguments passed in.  Somewhere in the procedure's code are
instructions that perform the check.  The information is there, but
with a sufficiently clever compiler -- the sort of implementation I
find most interesting -- finding that information could be
impractical, if not intractable.  

-Norman

∂22-Aug-89  1824	@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	multiple values
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  18:24:10 PDT
Received: from skinner.cs.uoregon.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06118; Tue, 22 Aug 89 21:07:08 EDT
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
	(5.59++/IDA-1.2.8) id AA23975; Tue, 22 Aug 89 18:07:08 PDT
Received: by spencer.cs.uoregon.edu; Tue, 22 Aug 89 18:07:02 PDT
Date: Tue, 22 Aug 89 18:07:02 PDT
From: will@cs.uoregon.edu
Message-Id: <8908230107.AA29487@spencer.cs.uoregon.edu>
To: rrrs-authors@life.ai.mit.edu
Subject: multiple values

Morry Katz:
    I can't imagine how one could create an implementation in which the arity
    information is not already present in some form for procedures that are
    passed as arguments.  Similarly, implicit continuations...

Passing an incorrect number of arguments to a procedure isn't required to
signal an error, so procedures don't have to check it.  Hence the arity may
not be retrievable through any amount of bit-twiddling.  Also, why should
the run-time representation of (lambda args #t) include any bits that
indicate the number of arguments it expects?  As a third example, the
variety and complexity of code sequences emitted by multiple compilers
may make the arity unrecoverable when embedded within code.  Similarly
for continuations.

That said, I don't think ACCEPTS? would be an unreasonable burden on any
implementor.  But it's certainly a burden that doesn't exist now.

Chris Hanson:
    I agree, with Norman, that the proposed functionality is useful in the
    absence of `accepts?'.

I agree with Chris and Norman.

Chris Hanson:
    ...multiple values have usefulness independent of the "truncation"
    feature, and I feel they are worth having anyway.

I agree again.  I believe the multiple values proposal being considered
allows the "truncation" feature as an extension: the critical property
is that (VALUES E) is always equivalent to E.

Peace, Will

∂22-Aug-89  1838	@spencer.cs.uoregon.edu:will@cs.uoregon.edu 	theology; MAX and MIN    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  18:37:57 PDT
Received: from skinner.cs.uoregon.edu by life.ai.mit.edu (4.1/AI-4.10) id AA06133; Tue, 22 Aug 89 21:08:19 EDT
Received: from spencer.cs.uoregon.edu by skinner.cs.uoregon.edu with SMTP
	(5.59++/IDA-1.2.8) id AA23985; Tue, 22 Aug 89 18:08:32 PDT
Received: by spencer.cs.uoregon.edu; Tue, 22 Aug 89 18:08:24 PDT
Date: Tue, 22 Aug 89 18:08:24 PDT
From: will@cs.uoregon.edu
Message-Id: <8908230108.AA29492@spencer.cs.uoregon.edu>
To: rrrs-authors@life.ai.mit.edu
Subject: theology; MAX and MIN

Note to Jim Miller:  My mail to you has bounced.  How did your poll on
this issue come out?

Guy Steele Jr:
    Theologically or politically speaking, under the first view inexact numbers
    strive to obey laws acknowledged to be perfect, but to a greater or lesser
    degree are each in a state of sin.  Under the second view they are all
    model citizens, adhering perfectly to their own laws which, however, are
    acknowledged not to be ideal but merely the best one can do in this
    imperfect and finite world.

In the imperfect world I live in, the supremum implied by the phrase
"the best one can do" is even less likely to exist than in the world of
computer arithmetic.

Theologically speaking, Guy's new proposal has the same problem as his old
proposal:  It introduces two new demons to undermine a user's faith in
exact numbers.  Only the names have changed: now the demons are called
LARGEST and SMALLEST.  The damage done by these two procedures won't be
ameliorated by having exactness-preserving SUP and INF as well.  For
simplicity, I say that if MAX and MIN, by whatever names, are going to be
exceptions to the perfect rules of exactness, then let's just acknowledge
them as exceptions and to hell, theologically speaking, with the sinfully
striving exactness-preserving versions.

Guy Steele Jr:
    But my point of view is that the MAX operation per se, like other C
    operators is *not* polymorphic.  They operate only on two ints or
    two floats.  The type mechanism enforces this requirement by inserting
    coercions; the point is that these coercions are outside the control
    of the implementation of the operation itself, and therefore not
    properly a part of them.  In exactly the same way that max(2.5, 1000)
    in an int context ends up having a coercion inserted, so the coercion
    that converts 1000 to a float is artificially inserted.

It doesn't matter how you look at it.  My point is that, contrary
to some recent discussion in RRRS-AUTHORS, experience with mainstream
programming languages has conditioned programmers to expect expressions
like (MAX 2.5 1000) to evaluate to an inexact number.  I pointed this
out to dispose of a bogus argument, not to argue that programmers'
expectations should decide the issue.  Expectations formed by other
languages aren't necessarily met by arithmetic in Scheme, precisely
because arithmetic in Scheme is more generic (polymorphic, if you will)
than in other languages.

Peace, Will

∂22-Aug-89  1842	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  18:42:06 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA05920; Tue, 22 Aug 89 20:44:41 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA29418; Tue, 22 Aug 89 17:43:51 pdt
Message-Id: <8908230043.AA29418@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 17:43:10 pdt
Date: Tue, 22 Aug 89 17:43:10 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: adams@tekchips.labs.tek.com
Cc: mkatz%sesame.stanford.edu@relay.cs.net, rrrs-authors@life.ai.mit.edu,
        adams@tekchips.labs
In-Reply-To: Norman Adams's message of Tue, 22 Aug 89 17:14:03 PDT <8908230014.AA26483@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com

    Perhaps each procedure is responsible for coping with wrong number of
    arguments passed in.  Somewhere in the procedure's code are
    instructions that perform the check.  The information is there, but
    with a sufficiently clever compiler -- the sort of implementation I
    find most interesting -- finding that information could be
    impractical, if not intractable.  

With a sufficiently clever compiler, the information should not be in
the code, since all checks have been done at compile time :-)

The MIT compiler used to output instructions to do arity checks at
runtime, but now the dynamic linker checks for arity mismatches when
definitions or assignments occur, thus rendering the runtime check a
waste of time in most of the cases.  The only cases where arity needs
to be checked at runtime in (compiled) MIT Scheme are things like

((car some-pair) arg1 arg2 arg3)

where the shape of the car of SOME-PAIR is not known at compile time.

The arity information is present in fixed format in "external
procedures" so that the linker (a fixed program) can check for
mismatches and create the appropriate trampolines at run time.  The
information is encoded so that the runtime check in cases like the
above is very fast when the number of arguments passed matches exactly
the number of arguments expected, and can be coded in-line, although
we don't do it right now.

The arity information only makes the output code be slightly larger in
a few cases, but hardly affects the time performance.  Except for
garbage collection time (compiled code objects are slightly larger),
and closure creation time (the closures must contain the arity
information if they are passed to "unknown" places), the time penalty
is very small, and I suspect that on the average, it is smaller than
in your model.  

In our implementation we multiplex this information with debugging
information (how many words are on the stack "on top" of a return
address, the kind of compiled entry point this is, etc), and it takes
16 bits per external entry point (whether a compiled procedure,
expression, return address or other), which we feel is not an excesive
space penalty.

Another possibility is to encode the arity information redundantly.
One encoding is for the actual runtime check, the other for ACCEPTS?
or similar procedures.  Note that this redundant encoding need not
take any space in the runtime image, since the compiler can produce
another object when compiling code, associating PCs to arities, and
this can be kept on an external "file", loaded only when someone uses
ACCEPTS?

In general, I find that implementation efficiency arguments based on
details of particular implementation strategies don't carry much
weight because two days later someone finds a different implementation
strategy that jiggles the trade-offs, but maintains the semantics.

Note that I don't need ACCEPTS? to be particularly efficient, since it
will only be used to provide an expensive portability hook.
Implementations that are sincerely interested in supporting less
strict return arity checking will want to provide a more efficient
primitive mechanism.

∂22-Aug-89  2037	dyb@iuvax.cs.indiana.edu 	Re:  Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  20:36:52 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07736; Tue, 22 Aug 89 23:14:59 EDT
Message-Id: <8908230314.AA07736@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu 
Date: Tue, 22 Aug 89 22:15:25 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re:  Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu

>     The predicate "accepts?" seems a little like the (rejected) predicate
>     "continuation?".  A procedure may not complain "up front" about a given
>     number of arguments, but may complain at some later time.  Or it may
>     accept any number of arguments, but ignore all but the first few.  I
>     don't see how "accepts?" can be generally useful if it breaks down in
>     these cases.
> 
> This is like saying that a given object may pass a PAIR? test yet when
> given to a list operation, the operation will flame.  Just because it
> does not cover all cases, it does not mean that it is useless.  Are
> you advocating for removing PAIR? from the language?

There is a difference that I'm surprised you don't see.  When "pair?"
returns #t for an object, I know that I can use "car" or "cdr" without
causing an error.  No similar claim can be made for "accepts?".

If we decide to add "accepts?" to the language, we would have to say
that an implementation is free to return #t if it cannot determine
whether or not a given number of arguments is accepted by a given
procedure.  An implementation might even define "accepts?" as:

   (lambda (procedure arity) #t)

This may seem to water down the predicate, but it only makes explicit
that which must already be true.

Kent

∂22-Aug-89  2052	dyb@iuvax.cs.indiana.edu 	Re:  Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  20:52:11 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA07971; Tue, 22 Aug 89 23:30:36 EDT
Message-Id: <8908230330.AA07971@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu 
Date: Tue, 22 Aug 89 22:31:06 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re:  Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu

> Certainly not TECHNICALLY, but it is my POLITICAL feeling, that if it
> is not accepted as a complete package, it will not be accepted later.
> The people who want the "restrictive" multiple values will feel no
> pressure to accept it later since they will already have what they
> want.  I'm not asking for their semantics to be different (I've
> compromised on paranoid checking by default), but I would like a
> little compromise on everyone else's part.

As long as we are considering the issues politically rather than
technically, how would you feel about the following compromises?

   * let's add "values" and "with-values" (or "apply-values") and
     change the name of the so-called "named let" to "recur".

   * let's add "accepts?" and remove the requirement that Scheme
     be case insensitive.

These may be considered together or separately, as you desire.

Kent

∂22-Aug-89  2105	dyb@iuvax.cs.indiana.edu 	Re:  multiple values    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Aug 89  21:05:38 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA08061; Tue, 22 Aug 89 23:45:04 EDT
Message-Id: <8908230345.AA08061@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu 
Date: Tue, 22 Aug 89 22:45:40 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: rrrs-authors@life.ai.mit.edu, will@cs.uoregon.edu
Subject: Re:  multiple values

> I agree again.  I believe the multiple values proposal being considered
> allows the "truncation" feature as an extension: the critical property
> is that (VALUES E) is always equivalent to E.

And this is the feature I'm most critical of.  Unless an implementation
does support the truncation feature, I don't see any reason why we should
require that "(values e)" be equivalent to "e".  I would like to feel
free to signal an error if "(values e)" is returned to a context that
is not prepared to accept multiple values.

Kent

∂23-Aug-89  0440	jinx@hpesogg.hp.com 	multiple values    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  04:40:39 PDT
Received: from sde.hp.com ([15.255.152.2]) by life.ai.mit.edu (4.1/AI-4.10) id AA00828; Wed, 23 Aug 89 06:57:53 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA06357; Wed, 23 Aug 89 00:00:05 pdt
Message-Id: <8908230700.AA06357@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 23:51:29 pdt
Date: Tue, 22 Aug 89 23:51:29 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu, will@cs.uoregon.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 22:45:40 -0500 <8908230345.AA08061@life.ai.mit.edu>
Subject:  multiple values
Reply-To: jinx%hpesogg@sde.hp.com


   And this is the feature I'm most critical of.  Unless an implementation
   does support the truncation feature, I don't see any reason why we should
   require that "(values e)" be equivalent to "e".  I would like to feel
   free to signal an error if "(values e)" is returned to a context that
   is not prepared to accept multiple values.

The question is whether you want to catch your personal errors, or you
want to catch everyone else's errors.


1) If you want to catch everyone else's errors, you don't gain
anything by making this additional restriction.  No one but you, and I
suspect not even you, is going to write the following code:

(with-values
  (lambda ()
    <some code>)
  (lambda (k)			; Single value expected
    <more code>))

Given this, everyone (except perhaps you) will redefine values in the
following way:

(define (lax-values . all)
  (if (not (singleton? all))
      (apply values all)
      (car all)))

Furthermore, if ACCEPTS? is in the language, people will do the
following

(define (lax-with-values generator recvr)
  (if (not (arity-is-1? recvr))
      (with-values generator recvr)
      (let ((value (generator)))
	(recvr value))))

Where

(define (singleton? list)
  (and (pair? list)
       (null? (cdr list))))

(define (arity-is-1? procedure)
  (and (accepts? procedure 1)
       (not (accepts? procedure 0))
       (not (accepts? procedure 2))))

and you won't gain any error checking on everyone else's code.

[PS: I realize that lax-values above has a bug, but it will do for
most people.  The bug can be fixed with ACCEPTS? in the following way:

(define (lax-values . all)
  (if (not (singleton? all))
      (apply values all)
      (call-with-current-continuation
       (lambda (k)
	 (if (arity-is-1? k)
	     (car all)
	     (apply values all))))))
]


2) If you want to catch your own errors, you (personally) can use the
following versions instead:

(define (dyb-with-values generator recvr)
  (with-values generator
    (lambda all
      (if (< (length all) 2)
	  (error "dyb-with-values: Mismatch" all)
	  (apply recvr (cddr all))))))

(define (dyb-values . all)
  (apply values (cons 'ignore-0 (cons 'ignore-1  all))))
    

∂23-Aug-89  0458	ramsdell@linus.mitre.org 	Just add WITH-VALUES and VALUES.  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  04:58:20 PDT
Received: from mbunix.mitre.org by life.ai.mit.edu (4.1/AI-4.10) id AA01612; Wed, 23 Aug 89 07:39:26 EDT
Posted-From: The MITRE Corp., Bedford, MA
X-Alternate-Route: user%node@mbunix.mitre.org
Return-Path: <ramsdell@linus.MITRE.ORG>
Received: from huxley.mitre.org by linus.MITRE.ORG (5.59/RCF-3S)
	id AA18144; Wed, 23 Aug 89 07:33:06 EDT
Posted-Date: Wed, 23 Aug 89 07:33:02 EDT
Received: by huxley.mitre.org (4.0/RCF-4C)
	id AA09643; Wed, 23 Aug 89 07:33:03 EDT
From: ramsdell@linus.mitre.org
Message-Id: <8908231133.AA09643@huxley.mitre.org>
To: rrrs-authors@life.ai.mit.edu
Cc: ramsdell@linus.mitre.org
Subject: Just add WITH-VALUES and VALUES.
In-Reply-To: Your message of Tue, 22 Aug 89 15:12:00 -0400.
             <19890822191226.5.KMP@BOBOLINK.SCRC.Symbolics.COM> 
Date: Wed, 23 Aug 89 07:33:02 EDT

I sounds to me like the WITH-VALUES is the preferred name and the
generator should be the first argument to WITH-VALUES.  So here is my
amended proposal.

------------------------------ WITH-VALUES Proposal.

(values obj ...)                                        essential procedure

Returns 0 or more values to a receiving procedure (See with-values).

        (values)        =>              returns zero (no) values

        (values 1)      =>              returns a single value, 1

        (values 1 'a) 	=>              returns two values, 1 and the symbol a


(with-values generator receiver)      			essential procedure

Returns the result of applying the procedure 'receiver' to the values
produced by calling procedure 'generator' with no arguments.  It is an
error if 'receiver' cannot be applied to the number of values returned
by 'generator' or if 'generator' cannot be called with zero arguments.

        (with-values 
          (lambda ()
            (values 1 2))
	  cons)   	      =>              (1 . 2)

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

As for the politics, consider this proposal as the best oportunity for
a compromise.  We ask Kent Dybvig to accept the critical property that
(VALUES E) is always equivalent to E and we ask Guillermo Rozas to
accept no agreement can currently be reached about an arity checking
procedure.  Please do not hold WITH-VALUES and VALUES hostage for they
really do represent existing practice, and many programmers use these
procedures.  The art of politics is compromise.  What say we give it a try?

John

PS.  My preferred name for WITH-VALUES is CPS-CALL, but I would not
let the preferrence stand in the way of a compromise!

∂23-Aug-89  0458	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  04:57:10 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA01635; Wed, 23 Aug 89 07:40:25 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA04990; Tue, 22 Aug 89 23:13:16 pdt
Message-Id: <8908230613.AA04990@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 23:12:31 pdt
Date: Tue, 22 Aug 89 23:12:31 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 22:31:06 -0500 <8908230330.AA02675@sde.hp.com>
Subject:  Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com

   As long as we are considering the issues politically rather than
   technically, how would you feel about the following compromises?

      * let's add "values" and "with-values" (or "apply-values") and
	change the name of the so-called "named let" to "recur".

Clearly these are independent issues.  The issues with multiple values
are not.  I PERSONALLY find multiple values useless (other people
obviously disagree) if they don't give me the capability that I want.
I don't think you can link named let to multiple values in a similar
way.

      * let's add "accepts?" and remove the requirement that Scheme
	be case insensitive.

Again, you are being random.  I can offer you many of these random
compromises too (how about trading "named let" -> "recur" for "begin"
-> "progn" ?).





∂23-Aug-89  0508	jinx@hpesogg.hp.com 	Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  05:08:39 PDT
Received: from sde.hp.com (hp-sde.sde.hp.com) by life.ai.mit.edu (4.1/AI-4.10) id AA01856; Wed, 23 Aug 89 07:49:18 EDT
Received: from hpesogg by hp-sde.sde.hp.com with SMTP
        (15.7/SES42.42) id AA04907; Tue, 22 Aug 89 23:08:46 pdt
Message-Id: <8908230608.AA04907@sde.hp.com>
Received: by hpesogg; Tue, 22 Aug 89 23:08:03 pdt
Date: Tue, 22 Aug 89 23:08:03 pdt
From: Guillermo J. Rozas <jinx@hpesogg.hp.com>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Tue, 22 Aug 89 22:15:25 -0500 <8908230314.AA02393@sde.hp.com>
Subject:  Multiple values for R4RS.
Reply-To: jinx%hpesogg@sde.hp.com


    There is a difference that I'm surprised you don't see.  When "pair?"
    returns #t for an object, I know that I can use "car" or "cdr" without
    causing an error.  No similar claim can be made for "accepts?".

There is an analogy that I'm surprised you don't see: :-)

Just because (pair? x) is #t, I can't guarantee that (cddr x) won't
error.

Similarly, just because (accepts? p 3) evaluates to #t I can't guarantee
that (accepts? cons 3) even if

(define (p . args)
  (apply cons args))

As another example, you would certainly say that I was being confused
if I complained about the following program signalling an error

(define (foo x y)
  (if (and (list? x) (> (length x) 1))
      (begin
        (set-cdr! x y)
        (cddr x))))

(foo (list 1 2) 'joe)

Further processing after initial invocation is not guaranteed to be
correct.  It depends on exactly what the program does.

Your argument seems to be that ACCEPTS? is an ill-defined concept
because when we actually give that many arguments the process may
still error out (for example if the types or range of the arguments
are incorrect).

Accepts? is not a general purpose error-hook.  It does not attempt to
find out whether a given process will terminate or error out.  It is
just telling me whether the signature of a given procedure object (not
the corresponding mathematical function) is such that it is legal to
give it 3 arguments.  It is almost "syntactic".

    If we decide to add "accepts?" to the language, we would have to say
    that an implementation is free to return #t if it cannot determine
    whether or not a given number of arguments is accepted by a given
    procedure.  An implementation might even define "accepts?" as:

Again, if you don't try to make it transitive, and a Turing oracle, it
is perfectly well defined whether a given procedure object accepts a
given number of arguments or not.  I would be very annoyed (and
consider the implementation to be in error) if 

(accepts? p 3) -> #t

and then

(p 'a 'b 'c) -> Error from apply: Too many (or few) arguments to p

It is perfectly fine if

(accepts? p 3) -> #t

and then

(p 'a 'b 'c) -> Error from apply: Too many (or few) arguments to q

where (eqv? p q) -> #f

The further constraint that is needed to make me happy is that

(define (check-2 n)
  (with-values
    (lambda ()
      (call-with-current-continuation
        (lambda (cont)
          (values (accepts? cont n) 'ignore))))
    (lambda (x y)
      x)))

(check-2 2) -> #t

(and (integer? m)
     (not (negative? m))
     (not (= m 2))
     (check-2 m)) -> #f

For all objects m.

Analogously for check-0, check-1, check-3, etc.

∂23-Aug-89  0853	@mc.lcs.mit.edu,@gateway.think.com:gls@think.com 	Numbers   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  08:51:28 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03979; Wed, 23 Aug 89 11:29:46 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa26520;
          22 Aug 89 13:25 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Aug 89 13:25:21 EDT
Received: from Gateway.Think.COM by mintaka.lcs.mit.edu id aa26446;
          22 Aug 89 13:19 EDT
Received: from fafnir.think.com by Think.COM; Tue, 22 Aug 89 13:19:24 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 22 Aug 89 13:16:52 EDT
Received: by verdi.think.com; Tue, 22 Aug 89 13:16:40 EDT
Date: Tue, 22 Aug 89 13:16:40 EDT
From: Guy Steele <gls@think.com>
Message-Id: <8908221716.AA01133@verdi.think.com>
To: bawden.pa@xerox.com
Cc: gls@think.com, rrrs-authors@mc.lcs.mit.edu
In-Reply-To: bawden.pa@xerox.com's message of Mon, 21 Aug 89 17:24 PDT <19890822002405.2.ALAN@ROCKY.parc.xerox.com>
Subject: Numbers

   Date: Mon, 21 Aug 89 17:24 PDT
   From: bawden.pa@xerox.com

       Date: Mon, 21 Aug 89 11:34:37 EDT
       From: Guy Steele <gls@think.com>
       I'm back from an exhausting, and therefore very restful, vacation.
       Back into the fray!

   I was wondering why I hadn't heard from you.  I couldn't imagine that you
   had given up the argument!

       Here is a new proposal.  Given a set of points within a partial order,
       there are two interesting kinds of "max"-like operation.  One is to find
       some point (not necessarily within the set) that is >= all points in the
       given set; this is SUP....

       Another is to find some point in the set such that no point in the set is >
       that point....

   But the version of MAX I am advocating isn't either of these!  I would
   allow:

     (max 1.0 549755813889)  ==>  549755813888.0

   Where presumably (< 549755813888.0 549755813889) is true.  Thus MAX can
   return an object that, according to `<', is smaller than one of the
   arguments.

   Now I'm sure that about half of you are shouting at your terminal about how
   I couldn't -possibly- mean that, but I do.  Understand me once and for all:

			 INEXACT NUMBERS ARE NOT NUMBERS

			 INEXACT NUMBERS ARE NOT NUMBERS

			 INEXACT NUMBERS ARE NOT NUMBERS

   They do not obey the rules followed by numbers, because they cannot.
   Inexact numbers only represent our -approximate- -knowledge- about numbers.
   In

     (max 1.0 549755813889)  ==>  549755813888.0

   we strongly suspect that the first number is 1, but we don't know for sure.
   Thus we strongly suspect that the answer is 549755813889, but again we
   don't know for sure (the first number could have actually been
   549755813890).  Since we don't know the answer for sure, we must return an
   inexact representation of our best guess.  549755813888.0 is the closest we
   can come.  (The next larger might be 549755879424.0, assuming 23 bits of
   floating point precision, which is not very close at all.)

   Indeed, we could -specify- that MAX always ``round up'' in the inexact case
   so that the result always appears greater (accroding to `<') than any of
   the arguments.  This would be similar to specifying that `<' must always
   behave transitively.  It would be a feeble attempt on our part to paper
   over the ugly fact that -in- -general-, inexact numbers do not obey the
   axioms of arithmetic.

I did misunderstand.  Thank you for correcting me on this point.  Now:

Pardon my French, but this is completely ridiculous.  You are telling me
that if I compare the height of a skyscraper, accurately measured by laser
and known to be within a few microns of 1000 feet tall, with a little kid
judged by eyeball to be within four inches of three feet tall, then I
should conclude that I know the larger of the two heights to be 1000 feet
but only to within four inches.

I agree that in *some* cases the best you can do is return an inexact
representation of one's best guess.  But sometimes you can tell for sure
that the answer is exact, even if some of the inputs were inexact.

In other words, I deny that the inexactness contagion used for + and * is
appropriate for MAX and MIN.  Why is 549755813888.0 the closest we can
come?  Only because we have made an arbitrary decision to cast the result
into a representation that reflects the inexactness of the least exact
input, regardless of whether that amount of inexactness in fact had
anything to do with the result computed.

--Guy

∂23-Aug-89  0856	@mc.lcs.mit.edu:bawden.pa@xerox.com 	Numbers 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  08:55:52 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA04029; Wed, 23 Aug 89 11:33:38 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa01876;
          22 Aug 89 18:09 EDT
Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 Aug 89 17:48:20 EDT
Received: from Xerox.COM by mintaka.lcs.mit.edu id aa01446; 22 Aug 89 17:43 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 AUG 89 14:43:10 PDT
Date: Tue, 22 Aug 89 14:40 PDT
From: bawden.pa@xerox.com
Subject: Numbers
To: gls@think.com
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: <8908221716.AA01133@verdi.think.com>
Message-Id: <19890822214016.5.ALAN@ROCKY.parc.xerox.com>
Line-Fold: no

    Date: Tue, 22 Aug 89 13:16:40 EDT
    From: gls@Think.COM (Guy Steele)
    Pardon my French, but this is completely ridiculous.

I keep hoping that if I rattle you hard enough I may be able to shake you
loose from your position.  Perhaps I'm making progress...

							  You are telling me
    that if I compare the height of a skyscraper, accurately measured by laser
    and known to be within a few microns of 1000 feet tall, with a little kid
    judged by eyeball to be within four inches of three feet tall, then I
    should conclude that I know the larger of the two heights to be 1000 feet
    but only to within four inches.

Inexact numbers do not necessarily contain a representation of the
precision with which a quantity is known.  In the common case where
floating point is used, they most definitely do not.  (In the rare case
where interval arithmetic is used, the bounds are known.)  Thus in a
floating point implementation of inexact numbers, you cannot represent the
concepts of "within a few microns of 1000 feet" or "within four inches of
three feet".  The best you can do is "perhaps 1000 feet" and "about four
feet".  The MAX of these two is "perhaps 1000 feet" -- any arguments about
the precision ("within a few microns of 1000 feet" vs. "within four inches
of 1000 feet") are in the province of a numerical analyst to reason about.

What I was -actually- claiming was that the MAX of "exactly 1000 feet" and
"about four feet" is "perhaps 1000 feet".  (In an implementation that used
interval arithmetic, I could indeed compute the MAX of "exactly 1000 feet"
and "within four inches of three feet" and get "exactly 1000 feet", but in
-general-, inexact arithmetic does not have this ability.)

    I agree that in *some* cases the best you can do is return an inexact
    representation of one's best guess.  But sometimes you can tell for sure
    that the answer is exact, even if some of the inputs were inexact.

Perhaps a numerical analyst can look at my program and tell me that for
sure.  Perhaps if I am using interval arithmetic my implementation can tell
me that for sure.  But if I am using floating point, my implementation can
-never- know that for sure.

    In other words, I deny that the inexactness contagion used for + and * is
    appropriate for MAX and MIN.  Why is 549755813888.0 the closest we can
    come?  Only because we have made an arbitrary decision to cast the result
    into a representation that reflects the inexactness of the least exact
    input, regardless of whether that amount of inexactness in fact had
    anything to do with the result computed.

It was not an "arbitrary decision" at all.  549755813888.0 is closest
because we only have 23-bit floating point to represent inexact numbers,
and the answer must be inexact.  Its the best we can do.  If we return an
exact number we are potentially returning an -INCORRECT- result.  We don't
know the answer exactly, so we cannot return an exact number.

I would have no objection if we decided to specify that MAX would have to
round up, so that 549755879424.0 was the answer in my example.  One could
argue that this was somehow a better approximation to the true answer
because it passed the `<' test.  But under no circumstances can I see
allowing 549755813889 to be returned, as that would discard the important
information that the answer is not known exactly.

∂23-Aug-89  0905	dyb@iuvax.cs.indiana.edu 	Re:  multiple values    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  09:05:46 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04104; Wed, 23 Aug 89 11:40:55 EDT
Message-Id: <8908231540.AA04104@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu 
Date: Wed, 23 Aug 89 10:41:22 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re:  multiple values
Cc: rrrs-authors@life.ai.mit.edu

	The question is whether you want to catch your personal errors, or you
	want to catch everyone else's errors.

As an implementor, I would like to signal an error whenever someone
attempts to return (values ...) to a context where multiple values
aren't expected, or something other than (values ...) to a context
expecting multiple values.  Requiring "(values e)" to be the same as
"e" makes it impossible to do this.  As you pointed out in your note,
this won't affect anyone who doesn't like this behavior, since they
can always create their own versions of "values" and "with-values"
that circumvent the error checks.

Note that I'm not asking for a requirement that "(values e)" be
distinct from "e", only that we not require that "(values e)" be
the same as "e".  So it doesn't rule out an implementation that
automatically truncates multiple values.

Kent

∂23-Aug-89  0925	Scheme-REQUEST@mc.lcs.mit.edu 	Scheme Digest #180 
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  09:25:07 PDT
Received: from lcs.mit.edu (MINTAKA.LCS.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA03917; Wed, 23 Aug 89 11:21:58 EDT
Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa06320;
          17 Aug 89 10:36 EDT
Date: 17 AUG 89  09:39:51 EDT
From: Automatic Scheme Digestifier <Scheme-Request%mc.lcs.mit.edu@mintaka.mc.lcs.edu>
Subject: Scheme Digest #180 
To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Reply-To: Scheme%mc.lcs.mit.edu@mintaka.mc.lcs.edu
Message-Id:  <8908171037.aa06320@mintaka.lcs.mit.edu>

Scheme Digest #180                             17 AUG 89  09:39:51 EDT

Today's Topics:

        Lisp shells
        Books on Scheme
        Books on Scheme
        Additional function libraries for PC-Scheme...
        X Scheme availability
        "Scheme has data types and Lisp doesn't."

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

Date: Wed, 16 Aug 89 05:16:39 EDT 
From: Olin.Shivers@a.gp.cs.cmu.edu
Subject: Lisp shells
Message-ID:  <8908160517.aa18074@mintaka.lcs.mit.edu>


John Lacey requested information on Lisp shells. John Ellis implemented
a shell for a PDP-11/45 running Unix in Harvard Lisp in 1979. 
	"A LISP SHELL"
	John R. Ellis
	ACM SIGPLAN Notices, Vol. 15 #5, May 1980

John Levine has a paper about using Lisp for a command language in the
same issue of SIGPLAN Notices ("Why a Lisp-Based Command Language?").

Of course, you might do well to look into the Lisp Machine interface, both
before and after the fancy Symbolics interface that allowed non-Lisp-syntax
commands. Any you might consider gnu-emacs plus all the extensions (like
monkey mode) to be a fairly reasonable shell, with lisp as an extension
language.
	-Olin



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

Date: 15 Aug 89 17:43:18 GMT
From: Jonas 'Gamemaster' Mellin <mcvax!sunic!his!jonas@uunet.uu.net>
Subject: Books on Scheme
Message-Id: <261@his.UUCP>

Does anyone know a good book about Scheme?

Please answer via E-mail.

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

Date: 16 Aug 89 14:58:49 GMT
From: Adam Glass <adam@media-lab.media.mit.edu>
Subject: Re: Books on Scheme
Message-Id: <493@mit-amt.MEDIA.MIT.EDU>

jonas@his.UUCP (Jonas 'Gamemaster' Mellin) writes:
> Does anyone know a good book about Scheme?
> 
> Please answer via E-mail.

Please answer via a public message in this newsgroup. I am quite interested
also.

Adam

--
"Offer me anything I ask for..."
"Anything you want."
"I want my father back, you son of a bitch." - The Princess Bride

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

Date: 16 Aug 89 15:28:04 GMT
From: Kevin Spier <usc!cs.utexas.edu!csd4.csd.uwm.edu!leah!rpi!turing.cs.rpi.edu!spierk@bloom-beacon.mit.edu>
Subject: Additional function libraries for PC-Scheme...
Message-Id: <6802@rpi.edu>

I am looking for any public domain function libraries (in source form
only) available for PC Scheme v3.0 (which is R↑3 compatible). I guess
any library which requires only R↑3 compatibility would also be fine.

Please mail directly to me and I will post a summary if others are
interested. 

Thanks,
Kevin L. Spier
spierk@turing.cs.rpi.edu

Kevin L. Spier
spierk@turing.cs.rpi.edu

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

Date: 16 Aug 89 20:29:17 GMT
From: Erik Talvola <pasteur!talvola@ucbvax.berkeley.edu>
Subject: X Scheme availability
Message-Id: <TALVOLA.89Aug16132917@janus.berkeley.edu>


  I have a rather old version of X-Scheme on my IBM PC (version 0.16) and
was wondering where I could obtain the most recent version, in both source
and object form.  Availability by FTP would be nice, but if not, then a
BBS source would be fine.  Thanks in advance.

--
+----------------------------+
! Erik Talvola               | "It's just what we need... a colossal negative 
! talvola@janus.berkeley.edu | space wedgie of great power coming right at us
! ...!ucbvax!janus!talvola   | at warp speed." -- Star Drek

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

Date: 15 Aug 89 14:52:37 GMT
From: Jeff Dalton <mcvax!ukc!edcastle!aiai!jeff@uunet.uu.net>
Subject: Re: "Scheme has data types and Lisp doesn't."
Message-Id: <737@skye.ed.ac.uk>

In article <13120@well.UUCP> nagle@well.UUCP (John Nagle) writes:
>Common LISP has lots of declarations.  But the programmer isn't required
>to provide them and the compiler implementor isn't required to make them
>do much.  CLTL: [...]  Not that SCHEME is really all that different.

I knew about all of the things you cite in CLtL.  I still don't see
how it explains the claim that "Scheme has data types and Lisp doesn't."

-- Jeff

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

End of Scheme Digest
********************

∂23-Aug-89  0939	dyb@iuvax.cs.indiana.edu 	Re:  Multiple values for R4RS.    
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  09:39:03 PDT
Received: from iuvax.cs.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) id AA04605; Wed, 23 Aug 89 12:27:20 EDT
Message-Id: <8908231627.AA04605@life.ai.mit.edu>
Received: by iuvax.cs.indiana.edu 
Date: Wed, 23 Aug 89 11:27:42 -0500
From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
To: jinx%hpesogg@sde.hp.com
Subject: Re:  Multiple values for R4RS.
Cc: rrrs-authors@life.ai.mit.edu

	There is an analogy that I'm surprised you don't see: :-)
	
	Just because (pair? x) is #t, I can't guarantee that (cddr x) won't
	error.

Ah, but I can ask (and (pair? x) (pair? (cdr x))), and if this is #t,
then I can be certain that (cddr x) won't error.
	
	Similarly, just because (accepts? p 3) evaluates to #t I can't guarantee
	that (accepts? cons 3) even if
	
	(define (p . args)
	  (apply cons args))

That's right.
	
	Further processing after initial invocation is not guaranteed to be
	correct.  It depends on exactly what the program does.

Right again.
	
	Your argument seems to be that ACCEPTS? is an ill-defined concept ...

My argument is that "accepts?" is virtually meaningless, since it is
a superficial property of the outermost level of the procedure, and there
is no way to extend it further in.  If "accepts?" returns #t, so what?
	
	Again, if you don't try to make it transitive, and a Turing oracle, it
	is perfectly well defined whether a given procedure object accepts a
	given number of arguments or not.  I would be very annoyed (and
	consider the implementation to be in error) if 
	
	(accepts? p 3) -> #t
	
	and then
	
	(p 'a 'b 'c) -> Error from apply: Too many (or few) arguments to p

But this is exactly what may happen if "p" does its own checking, i.e.,
if I write p as:

    (lambda args
       (if (> (length args) 2)
           (error 'apply "Too many (or few) arguments to p")
           (f args)))

Of course, "p" is representing itself as "apply" in the error message,
but I hardly see that it's relevant where the message comes from.

∂23-Aug-89  1027	mkatz%sesame.stanford.edu@relay.cs.net 	Multiple values for R4RS.
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  10:27:37 PDT
Received: from MIT.EDU (MIT.MIT.EDU) by life.ai.mit.edu (4.1/AI-4.10) id AA05110; Wed, 23 Aug 89 13:09:16 EDT
Received: from RELAY.CS.NET by MIT.EDU with SMTP
	id AA03906; Wed, 23 Aug 89 13:09:05 EDT
Received: from sesame.stanford.edu by RELAY.CS.NET id aa01216;
          23 Aug 89 13:08 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA00319; Wed, 23 Aug 89 10:07:34 PDT
Date: Wed, 23 Aug 89 10:07:34 PDT
From: Morris Katz <mkatz%sesame.stanford.edu@relay.cs.net>
Message-Id: <8908231707.AA00319@sesame.Stanford.EDU>
To: adams%tekchips.labs.tek.com@relay.cs.net
Cc: jinx%hpesogg@sde.hp.com, mkatz%sesame.stanford.edu@relay.cs.net,
        rrrs-authors%life.ai.mit.edu@relay.cs.net, adams@tekchips.labs
In-Reply-To: Norman Adams's message of Tue, 22 Aug 89 17:14:03 PDT <8908230014.AA26483@tekchips.LABS.TEK.COM>
Subject: Multiple values for R4RS.

   Date: Tue, 22 Aug 89 17:14:03 PDT
   From: Norman Adams <adams%tekchips.labs.tek.com@relay.cs.net>
       From: mkatz%sesame.stanford.edu
       I can't imagine how one could create an implementation in which the arity
       information is not already present in some form for procedures that 
       are passed

   Sure, it is present in some form.

   Perhaps each procedure is responsible for coping with wrong number of
   arguments passed in.  Somewhere in the procedure's code are
   instructions that perform the check.  The information is there, but
   with a sufficiently clever compiler -- the sort of implementation I
   find most interesting -- finding that information could be
   impractical, if not intractable.  

Difficult maybe; intractable, I doubt.  I think this same argument could be
given for eliminating continuations from Scheme as they create restrictions on
implementation methodologies.  There is almost always a tradeoff between
graeter functionality and implementation simplicity.  I, for one, think that
the functionality gained by adding ACCEPTS? justifies its complexity.  To
convince me otherwise I am afraid you are going to have to be more specific
about why a good compiler gets screwed by accepts.  It seems to me that a good
compiler should only pay a cost for ACCEPTS? when it is used (as Jinx has
stated).  Isn't this the ideal characterization of a feature?  It only costs
the user when they use it.


-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂23-Aug-89  1102	cph@zurich.ai.mit.edu 	Multiple values for R4RS.  
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  11:02:35 PDT
Received: from zurich.ai.mit.edu ([18.43.0.172]) by life.ai.mit.edu (4.1/AI-4.10) id AA05337; Wed, 23 Aug 89 13:24:31 EDT
Received: from localhost by zurich.ai.mit.edu; Wed, 23 Aug 89 13:21:17 edt
Date: Wed, 23 Aug 89 13:21:17 edt
From: cph@zurich.ai.mit.edu (Chris Hanson)
Message-Id: <8908231721.AA07769@zurich.ai.mit.edu>
To: dyb@iuvax.cs.indiana.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Wed, 23 Aug 89 11:27:42 -0500 <8908231627.AA04605@life.ai.mit.edu>
Subject:  Multiple values for R4RS.

   Date: Wed, 23 Aug 89 11:27:42 -0500
   From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>

      Your argument seems to be that ACCEPTS? is an ill-defined concept ...

   My argument is that "accepts?" is virtually meaningless, since it is
   a superficial property of the outermost level of the procedure, and there
   is no way to extend it further in.  If "accepts?" returns #t, so what?

(Here is yet another chapter in the war between the theoreticians and
the engineers.)

Because the proposed semantics of `accepts?' does not return the
"correct" answer 100% of the time, Kent is unwilling to accept it.
Indeed, it is not possible to determine the "correct" answer because
of the halting problem.  Yet at the same time, the proposed semantics
is sufficient to solve what Jinx sees as a real problem.

My summary of these arguments is that Kent is rejecting `accepts?'
because it doesn't satisfy a specification which is known to be
impossible to satisfy.  I believe this is an unreasonable position,
and we should move on to a more substantive argument.  I've heard two
of these:

1. `accepts?' is not very useful.  (I agree with Jinx, having used MIT
Scheme's version of this predicate for about a year or so.  In
practice, I find that the counterexamples Kent has presented are not
too common.)

2. `accepts?' places an unreasonable burden on the implementor.  (I
concede that this -might- be true, but that is a judgment of the
usefulness of `accepts?' as well as its implementation cost.)

∂23-Aug-89  1104	KMP@stony-brook.scrc.symbolics.com 	Re: Multiple values for R4RS.     
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  11:03:15 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM by life.ai.mit.edu (4.1/AI-4.10) id AA05149; Wed, 23 Aug 89 13:12:44 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 645502; 22 Aug 89 15:12:28 EDT
Date: Tue, 22 Aug 89 15:12 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Subject: Re: Multiple values for R4RS. 
To: ramsdell@linus.mitre.org
Cc: rrrs-authors@life.ai.mit.edu, KMP@stony-brook.scrc.symbolics.com
In-Reply-To: <8908221800.AA08733@huxley.mitre.org>
Message-Id: <19890822191226.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

    [1] Do you think VALUES and APPLY-VALUES as defined are controversial?
Yes.
    [2] Do you think VALUES and APPLY-VALUES as defined reflect existing
    practice?
Yes.
    [3] Do you think VALUES and APPLY-VALUES as defined prohibit the
    future inclusion of ACCEPTS? or some other proposal to deal with
    incompatiable arities?
No, though this seems somewhat irrelevant.
    [4] Do you believe VALUES and APPLY-VALUES should be excluded from
    Scheme solely because there is no agreement on how to deal with
    incompatiable arities?
No.

For what it's worth, I would not endorse the inclusion of VALUES and
APPLY-VALUES as proposed. Here are my suggestions for correcting it:

I would invert the order of arguments.   I think this will feel more
natural.  APPLY, normal function call, MAP, etc. all work this way.

If you cannot bring yourself to change the order, you should definitely
remove the morpheme `APPLY' to avoid confusion with argument conventions
for the APPLY function.  Programmers are likely to model the
values-yielding argument to APPLY-VALUES as a generalized variant of the
list-to-spread last argument to APPLY, and then to wonder why the two
functions take their `other' argument in opposite places.

In fact, I think this function is more closely related to
CALL-WITH-CURRENT-CONTINUATION than to APPLY, and that the naming should
reflect that.  I think a name like CALL-WITH-RESULTING-VALUES (or just
CALL-WITH-VALUES, though that's less descriptive) would be better.

In effect, what this operator does is to splice a new function into the
continuation chain.  As such, something like INTERPOSE-CONTINUATION or
ENCAPSULATE-CURRENT-CONTINUATION (well, not quite) or 
COMPOSE-CURRENT-CONTINUATION (my personal favorite, for `symmetry' with
T's COMPOSE) would also be appropriate.

RECEIVE-VALUES is clearly better than APPLY-VALUES in my mind, but it
still leaves you feeling like it should be a special form that magically
picks up values resulting from the second form, rather than something
which takes a normal functional argument. That's the main reason why I
think something with the morpheme `CONTINUATION' in it would be best.

Although these are syntactic rather than semantic issues, I consider
them important to get right.  But modulo the syntax stuff, I strongly
favor the introduction of the proposed level of functionality into R4RS.

By the way, while I'm at it, I don't much like the name VALUES because
it looks yucky for the 1-argument case.  Since RETURN is problematic, I
think I would prefer YIELD over VALUES.  But I can live with either if
it comes to it.

Also, regarding ACCEPTS?, just so I'm on the record about it, I think a
predicate that took a continuation (or even an arbitrary function) and
an integer and told you if that number of arguments was suitable.  I
think the name ACCEPTS? is too short and too general for so specific a
purpose.  I would rather a longer, less generic sounding name.  But I
have no conflict with the idea of this kind of functionality.

∂23-Aug-89  1104	mkatz@sesame.stanford.edu 	multiple values   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  11:04:26 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05385; Wed, 23 Aug 89 13:28:16 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA00373; Wed, 23 Aug 89 10:26:39 PDT
Date: Wed, 23 Aug 89 10:26:39 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908231726.AA00373@sesame.Stanford.EDU>
To: dyb@iuvax.cs.indiana.edu
Cc: jinx%hpesogg@sde.hp.com, rrrs-authors@life.ai.mit.edu
In-Reply-To: R. Kent Dybvig's message of Wed, 23 Aug 89 10:41:22 -0500 <8908231540.AA04104@life.ai.mit.edu>
Subject:  multiple values

   Date: Wed, 23 Aug 89 10:41:22 -0500
   From: R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>
   Note that I'm not asking for a requirement that "(values e)" be
   distinct from "e", only that we not require that "(values e)" be
   the same as "e".  So it doesn't rule out an implementation that
   automatically truncates multiple values.

I must be missing something.  How does the requirement that "(values e)" and
"e" be the same rule out an implementation the automatically truncates? 


-------------------------------------------------------------------------------
Morry Katz
katz@polya.stanford.edu
-------------------------------------------------------------------------------

∂23-Aug-89  1105	mkatz@sesame.stanford.edu 	multiple values   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Aug 89  11:04:49 PDT
Received: from sesame.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA05301; Wed, 23 Aug 89 13:22:30 EDT
Received: by sesame.Stanford.EDU (5.57/Ultrix2.4-C)
	id AA00363; Wed, 23 Aug 89 10:21:04 PDT
Date: Wed, 23 Aug 89 10:21:04 PDT
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8908231721.AA00363@sesame.Stanford.EDU>
To: will@cs.uoregon.edu
Cc: rrrs-authors@life.ai.mit.edu
In-Reply-To: will@cs.uoregon.edu's message of Tue, 22 Aug 89 18:07:02 PDT <8908230107.AA29487@spencer.cs.uoregon.edu>
Subject: multiple values

   Date: Tue, 22 Aug 89 18:07:02 PDT
   From: will@cs.uoregon.edu

   Passing an incorrect number of argume