perm filename COMSCH.2[SCH,LSP] blob sn#873959 filedate 1989-06-01 generic text, type C, neo UTF8
COMMENT ⊗   VALID 01680 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00274 00002	
C00275 00003	∂26-Apr-86  0738	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	The generality of define
C00277 00004	∂26-Apr-86  1816	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@xx.lcs.mit.edu 	variata  
C00283 00005	∂27-Apr-86  1455	@MC.LCS.MIT.EDU:KMP@SCRC-STONY-BROOK.ARPA 	variata
C00292 00006	∂27-Apr-86  1607	@MC.LCS.MIT.EDU:dcj%jacksun@SUN.COM 	SCOOPS, and GNU support question 
C00295 00007	∂28-Apr-86  1155	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: variata    
C00301 00008	∂28-Apr-86  1340	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: SCOOPS, and GNU support question    
C00304 00009	∂29-Apr-86  0743	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	meaning of *global* define   
C00308 00010	∂30-Apr-86  1425	@MC.LCS.MIT.EDU:jcm@ORNL-MSR.ARPA 	Questions from a newcomer
C00311 00011	∂30-Apr-86  2156	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	Questions from a newcomer    
C00313 00012	∂05-May-86  1142	@MC.LCS.MIT.EDU:amn@LOCUS.UCLA.EDU 	getting C-Scheme running on HP workstations 
C00315 00013	∂05-May-86  1402	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	one more message about CScheme    
C00317 00014	∂05-May-86  1910	@MC.LCS.MIT.EDU:serafini@ames-aero 	implementation roundup  
C00318 00015	∂05-May-86  1914	JAR@MC.LCS.MIT.EDU 	implementation roundup   
C00321 00016	∂22-May-86  0819	NET-ORIGIN@MC.LCS.MIT.EDU 	H, E, S, B, O, D, X    
C00323 00017	∂22-May-86  0900	NET-ORIGIN@MC.LCS.MIT.EDU 	LOAD    
C00328 00018	∂22-May-86  1016	@MC.LCS.MIT.EDU:andy@aids-unix 	Re:  LOAD    
C00332 00019	∂22-May-86  1558	@MC.LCS.MIT.EDU:KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Notes about (↑ revised 3) report   
C00338 00020	∂23-May-86  0957	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: H, E, S, B, O, D, X  
C00341 00021	∂23-May-86  1013	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: LOAD  
C00344 00022	∂25-May-86  0923	@MC.LCS.MIT.EDU:VERACSD@USC-ISI.ARPA 	Addition to Mailing-List   
C00346 00023	∂25-May-86  1237	@MC.LCS.MIT.EDU:VERACSD@USC-ISI.ARPA 	Addition to Mailing-List   
C00348 00024	∂26-May-86  1555	@MC.LCS.MIT.EDU:JAR@MX.LCS.MIT.EDU 	R↑3RS draft   
C00351 00025	∂27-May-86  1120	NET-ORIGIN@MC.LCS.MIT.EDU 	Remaining questions & remarks (1)
C00363 00026	∂27-May-86  1339	@MC.LCS.MIT.EDU:cth%indiana.csnet@CSNET-RELAY.ARPA 	define (resend)   
C00367 00027	∂27-May-86  1844	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	define (resend) (long)  
C00375 00028	∂28-May-86  0827	@MC.LCS.MIT.EDU,@KATHERINE.THINK.COM:gls@AQUINAS.THINK.COM 	Remaining questions & remarks (1)  
C00377 00029	∂28-May-86  0836	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	hash-consing   
C00380 00030	∂28-May-86  1137	@MC.LCS.MIT.EDU:andy@aids-unix 	Re:  define  
C00384 00031	∂28-May-86  1241	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  define (resend) (long) (short)   
C00386 00032	∂28-May-86  1736	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	define (resend) (long) (short)    
C00392 00033	∂28-May-86  2216	@MC.LCS.MIT.EDU:gls@Think.COM 	Embedded DEFINE forms   
C00394 00034	∂28-May-86  2243	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: Notes about (↑ revised 3) report
C00399 00035	∂29-May-86  1417	NET-ORIGIN@MC.LCS.MIT.EDU 	define  
C00405 00036	∂29-May-86  1438	NET-ORIGIN@MC.LCS.MIT.EDU 	schedule
C00408 00037	∂29-May-86  1450	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	define    
C00411 00038	∂29-May-86  1454	@MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA 	R3RS draft -- procedural
C00413 00039	∂29-May-86  1545	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	R3RS draft -- procedural 
C00415 00040	∂29-May-86  1610	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	response to new draft report (long)
C00435 00041	∂29-May-86  1610	@MC.LCS.MIT.EDU,@CSNET-RELAY.ARPA,@boethius.think.com:gls@AQUINAS.THINK.COM 	hash-consing 
C00437 00042	∂29-May-86  1706	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: global definitions    
C00442 00043	∂30-May-86  1432	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	definitions APPEND! etc 
C00449 00044	∂30-May-86  1650	@MC.LCS.MIT.EDU:OXLEY%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: Embedded DEFINE forms  
C00453 00045	∂30-May-86  1703	@MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA 	procedure (Tnx)    
C00454 00046	∂30-May-86  1703	@MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA 	define -- a modest proposal  
C00459 00047	∂31-May-86  0108	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	define -- a modest proposal  
C00464 00048	∂31-May-86  0331	NET-ORIGIN@MC.LCS.MIT.EDU 	wanted: teaching do's and dont's 
C00466 00049	∂31-May-86  0539	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	wanted: teaching do's and dont's  
C00472 00050	∂31-May-86  0738	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	sentiments   
C00479 00051	∂31-May-86  1608	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	sentiments    
C00490 00052	∂31-May-86  2319	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	define -- a modest proposal  
C00513 00053	∂01-Jun-86  0815	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	define -- a modest proposal  
C00523 00054	∂01-Jun-86  2051	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	schedule  
C00525 00055	∂01-Jun-86  2343	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  sentiments   
C00544 00056	∂02-Jun-86  0730	@MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU 	Another Can of Worms?
C00548 00057	∂02-Jun-86  1558	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	sentiments    
C00560 00058	∂02-Jun-86  1604	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	DEFINE -- a concrete proposal  
C00569 00059	∂02-Jun-86  1803	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: definitions APPEND! etc 
C00572 00060	∂03-Jun-86  0853	@MC.LCS.MIT.EDU:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA   
C00574 00061	∂03-Jun-86  0953	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	APPEND!  
C00576 00062	∂03-Jun-86  1010	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	portability   
C00584 00063	∂03-Jun-86  1124	@MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA 	define   
C00587 00064	∂03-Jun-86  1441	@MC.LCS.MIT.EDU:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA 	SCOOPS source   
C00589 00065	∂03-Jun-86  1554	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Is BEGIN primitive?  
C00592 00066	∂03-Jun-86  2023	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	ftp-able r3rs.dvi   
C00594 00067	∂04-Jun-86  0554	@MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU 	Re:  portability
C00596 00068	∂04-Jun-86  1049	@MC.LCS.MIT.EDU:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: SCOOPS source    
C00598 00069	∂04-Jun-86  1623	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: portability 
C00601 00070	∂05-Jun-86  0546	@MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU 	Re: portability 
C00603 00071	∂05-Jun-86  0935	@MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA 	Will's proposal
C00604 00072	∂05-Jun-86  0939	@MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA 	named-lambda and rec
C00605 00073	∂05-Jun-86  1055	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	named-lambda and rec
C00607 00074	∂06-Jun-86  0800	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	portability   
C00612 00075	∂06-Jun-86  0806	@MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA 	add1 and sub1  
C00614 00076	∂06-Jun-86  1039	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	add1 and sub1  
C00616 00077	∂06-Jun-86  2038	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: portability
C00620 00078	∂07-Jun-86  1658	@MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA 	macros.   
C00621 00079	∂07-Jun-86  1820	@MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: named-lambda and rec  
C00623 00080	∂07-Jun-86  1829	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  add1 and sub1
C00625 00081	∂08-Jun-86  1652	@MC.LCS.MIT.EDU:Swenson.Multics@MIT-MULTICS.ARPA 	Re: SCOOPS source   
C00627 00082	∂09-Jun-86  1643	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	portability   
C00634 00083	∂10-Jun-86  0744	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  portability  
C00638 00084	∂11-Jun-86  1021	@MC.LCS.MIT.EDU:TIM%upenn.csnet@CSNET-RELAY.ARPA 	Scheme for AI based CAI  
C00645 00085	∂11-Jun-86  1145	@MC.LCS.MIT.EDU:FAHLMAN@C.CS.CMU.EDU 	Scheme for AI based CAI    
C00650 00086	∂13-Jun-86  0956	@MC.LCS.MIT.EDU:mmeyer%tilde%ti-csl.csnet@CSNET-RELAY.ARPA 	Revised↑3 Draft Comment  
C00652 00087	∂15-Jun-86  1251	@MC.LCS.MIT.EDU:cth%indiana.csnet@CSNET-RELAY.ARPA 	Logic Continuations (Abstract)   
C00655 00088	∂17-Jun-86  1621	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Number syntax  
C00659 00089	∂17-Jun-86  1909	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Number syntax  
C00662 00090	∂17-Jun-86  1912	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Policy on change-making  
C00666 00091	∂18-Jun-86  2144	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  Number syntax
C00668 00092	∂20-Jun-86  0202	@MC.LCS.MIT.EDU:JINX@OZ.AI.MIT.EDU 	Policy on change-making 
C00670 00093	∂23-Jun-86  1412	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Bibliography   
C00672 00094	∂26-Jun-86  2114	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Remaining questions & remarks (2)  
C00694 00095	∂27-Jun-86  0943	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	r3rs presentation  
C00700 00096	∂27-Jun-86  1115	@MC.LCS.MIT.EDU:gls@Think.COM 	Remaining questions & remarks (2) 
C00705 00097	∂27-Jun-86  1653	@MC.LCS.MIT.EDU:SGR@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	[INGRIA@G.BBN.COM: Scheme for LISPM]    
C00707 00098	∂27-Jun-86  1930	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	typo 
C00708 00099	∂27-Jun-86  2142	@MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA 	Grandfathering Responses 
C00727 00100	∂28-Jun-86  1511	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	variable vs. identifier  
C00729 00101	∂28-Jun-86  1511	@MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA 	Grandfathering response  
C00748 00102	∂29-Jun-86  1205	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[INGRIA@G.BBN.COM: Scheme for LISPM]    
C00751 00103	∂29-Jun-86  2140	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  Remaining questions & remarks (2)
C00762 00104	∂30-Jun-86  0741	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  r3rs presentation (long)    
C00771 00105	∂01-Jul-86  1040	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Call-with-current-continuation    
C00775 00106	∂01-Jul-86  1432	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: Remaining questions & remarks (2)   
C00790 00107	∂01-Jul-86  1446	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: Remaining questions & remarks (2)    
C00812 00108	∂02-Jul-86  0515	@MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU 	Re: Remaining questions & remarks (2)    
C00814 00109	∂02-Jul-86  0557	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Call-with-current-continuation    
C00818 00110	∂02-Jul-86  1652	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Remaining questions & remarks (2)  
C00821 00111	∂07-Jul-86  0929	@MC.LCS.MIT.EDU:VERACSD@A.ISI.EDU 	CL Compatiblity Package  
C00823 00112	∂07-Jul-86  1254	@MC.LCS.MIT.EDU:cth%indiana.csnet@CSNET-RELAY.ARPA 	votes and things  
C00829 00113	∂08-Jul-86  0538	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	display and write-char 
C00831 00114	∂08-Jul-86  2347	@MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA 	remaining questions & remarks (2) 
C00837 00115	∂09-Jul-86  0340	@MC.LCS.MIT.EDU:HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	mitch wand's comments    
C00838 00116	∂10-Jul-86  1015	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	number syntax  
C00843 00117	∂10-Jul-86  1016	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	call-with-*put-file  -->  call-with-*put-port
C00845 00118	∂10-Jul-86  1228	@MC.LCS.MIT.EDU:MICHAEL@CS.COLUMBIA.EDU 	How big would a "minimal" scheme interpreter be? 
C00846 00119	∂10-Jul-86  1300	@MC.LCS.MIT.EDU:andy@sun3.ads.ARPA 	My comments on the R↑RS 
C00865 00120	∂10-Jul-86  1313	@MC.LCS.MIT.EDU:MICHAEL@CS.COLUMBIA.EDU 	[Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>: How big would a "minimal" scheme interpreter be?]    
C00868 00121	∂10-Jul-86  1342	@MC.LCS.MIT.EDU:wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA 	Re: Remaining questions & remarks (2)
C00872 00122	∂10-Jul-86  1540	@MC.LCS.MIT.EDU:andy@sun3.ads.ARPA 	My answers to your thirty questions on R↑RS 
C00882 00123	∂10-Jul-86  1941	@MC.LCS.MIT.EDU:whill%hplabsc@hplabs.HP.COM 	Re:  [Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>: How big would a "minimal" scheme interpreter be?]
C00884 00124	∂11-Jul-86  0336	@MC.LCS.MIT.EDU:bc@MEDIA-LAB.MIT.EDU 	MacScheme   
C00886 00125	∂11-Jul-86  0925	@MC.LCS.MIT.EDU:gls@Think.COM 	My comments on the R↑RS 
C00895 00126	∂11-Jul-86  0935	@MC.LCS.MIT.EDU:cscott@bfly-vax.bbn.com 	tiny scheme   
C00897 00127	∂11-Jul-86  1142	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: My comments on the R↑RS   
C00903 00128	∂11-Jul-86  1642	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	test 
C00904 00129	∂12-Jul-86  1837	@MC.LCS.MIT.EDU:RPG@SU-AI.ARPA 	Compatibility with Common Lisp: A meta comment       
C00909 00130	∂13-Jul-86  1528	@MC.LCS.MIT.EDU:andy@sun3.ads.ARPA 	Scheme's DO construct   
C00925 00131	∂14-Jul-86  0252	@MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Flaws of form   
C00932 00132	∂14-Jul-86  0325	@MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Flaws of form   
C00939 00133	∂14-Jul-86  0641	@MC.LCS.MIT.EDU:OXLEY%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: Compatibility with Common Lisp: A meta comment       
C00941 00134	∂14-Jul-86  0741	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Common Lisp   
C00944 00135	∂14-Jul-86  1008	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[ANDY: dedication]  
C00946 00136	∂14-Jul-86  1337	@MC.LCS.MIT.EDU:RPG@SU-AI.ARPA 	Use of DO in Common Lisp Code    
C00950 00137	∂14-Jul-86  1448	@MC.LCS.MIT.EDU:goodhart%cod@nosc.ARPA 	Scheme Request 
C00952 00138	∂14-Jul-86  1514	@MC.LCS.MIT.EDU:andy@sun3.ads.ARPA 	Scheme vs. Common Lisp, #1: Politics   
C00966 00139	∂14-Jul-86  1607	@MC.LCS.MIT.EDU:RPG@SU-AI.ARPA 	Politics     
C00971 00140	∂14-Jul-86  1702	@MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA 	call-with-xput-port vs. call-with-xput-file 
C00976 00141	∂14-Jul-86  1814	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Scheme Request 
C00979 00142	∂14-Jul-86  2156	@MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA 	the colon (:) in identifier syntax
C00981 00143	∂14-Jul-86  2159	@MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA 	exp versus expt    
C00983 00144	∂15-Jul-86  0951	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	convergence    
C00985 00145	∂15-Jul-86  1807	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: Scheme's DO construct 
C00996 00146	∂15-Jul-86  2019	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	rrrs-authors   
C01000 00147	∂15-Jul-86  2105	@MC.LCS.MIT.EDU:jleech@sun6.ads 	the rrrs authors 
C01002 00148	∂16-Jul-86  1731	@MC.LCS.MIT.EDU:brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA 	Substring & friends 
C01005 00149	∂16-Jul-86  1732	@MC.LCS.MIT.EDU:Bartley%TI-CSL.CSNET@CSNET-RELAY.ARPA 	Re: number syntax   
C01014 00150	∂16-Jul-86  1921	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	July 15 draft sent  
C01016 00151	∂17-Jul-86  0851	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	Substring & friends 
C01019 00152	∂17-Jul-86  1217	@MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	Re: Substring & friends  
C01021 00153	∂17-Jul-86  1412	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[jtv%fingate.bitnet: Scheme Request]    
C01023 00154	∂17-Jul-86  1442	@MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: Substring & friends   
C01026 00155	∂18-Jul-86  0012	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: Substring & friends   
C01029 00156	∂18-Jul-86  1428	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[jtv%fingate.bitnet: Scheme Request]    
C01031 00157	∂21-Jul-86  0448	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	typos    
C01034 00158	∂21-Jul-86  0737	@MC.LCS.MIT.EDU:Mike←Wilson%CARLETON.BITNET@WISCVM.WISC.EDU 	Performance and Evaluation of Scheme Systems...  
C01037 00159	∂21-Jul-86  0808	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	schedule  
C01040 00160	∂21-Jul-86  0827	@MC.LCS.MIT.EDU:CLOWNEY@BLUE.RUTGERS.EDU 	Logic Continuations (Abstract)   
C01042 00161	∂21-Jul-86  1014	@MC.LCS.MIT.EDU:gls@Think.COM 	Scheme's DO construct   
C01046 00162	∂21-Jul-86  1057	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: Performance and Evaluation of Scheme Systems...    
C01050 00163	∂21-Jul-86  1143	@MC.LCS.MIT.EDU:bc@MEDIA-LAB.MIT.EDU 	Bobcat scheme    
C01052 00164	∂21-Jul-86  1228	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Logic Continuations (Abstract)
C01069 00165	∂21-Jul-86  1325	@MC.LCS.MIT.EDU:gls@Think.COM 	Re: Scheme's DO construct    
C01071 00166	∂21-Jul-86  1357	@MC.LCS.MIT.EDU:YEKTA@AI.AI.MIT.EDU 	Bobcat scheme
C01073 00167	∂22-Jul-86  0710	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	title wars
C01076 00168	∂22-Jul-86  0717	@MC.LCS.MIT.EDU:HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	title wars
C01077 00169	∂22-Jul-86  1143	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	title wars
C01079 00170	∂22-Jul-86  1157	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	title wars
C01081 00171	∂22-Jul-86  1243	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: title wars 
C01083 00172	∂22-Jul-86  1252	@MC.LCS.MIT.EDU,@YALE-BULLDOG.ARPA:hudak@YALE.ARPA 	Re: Performance and Evaluation of Scheme Systems...  
C01089 00173	∂22-Jul-86  1529	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: title wars 
C01092 00174	∂22-Jul-86  1755	@MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	title
C01093 00175	∂24-Jul-86  1244	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	call-with-xput-port vs. call-with-xput-file  
C01098 00176	∂25-Jul-86  0022	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: July 15 draft sent   
C01107 00177	∂25-Jul-86  1026	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: number syntax    
C01116 00178	∂25-Jul-86  1127	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	(eqv? #e1 #i1) 
C01119 00179	∂25-Jul-86  1346	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	July 15th draft    
C01125 00180	∂26-Jul-86  2137	@MC.LCS.MIT.EDU:cth%iuvax.indiana.edu@CSNET-RELAY.ARPA 	corrections and suggestions  
C01133 00181	∂28-Jul-86  0810	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Fault logic in eq? comment   
C01136 00182	∂28-Jul-86  1616	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: corrections and suggestions
C01142 00183	∂29-Jul-86  1331	@MC.LCS.MIT.EDU:dyb@iuvax.indiana.edu 	critical problems with call---file, with---file    
C01149 00184	∂29-Jul-86  1423	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	schedule  
C01152 00185	∂29-Jul-86  1814	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: critical problems with call---file, with---file
C01157 00186	∂31-Jul-86  0732	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	rrrs authors meeting, lunch Tuesday
C01160 00187	∂31-Jul-86  1111	@MC.LCS.MIT.EDU:fateman@DALI.BERKELEY.EDU 	Re:  Performance and Evaluation of Scheme Systems...
C01162 00188	∂04-Aug-86  0107	@MC.LCS.MIT.EDU:facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA   
C01164 00189	∂04-Aug-86  0158	@MC.LCS.MIT.EDU:facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA   
C01166 00190	∂06-Aug-86  0150	@MC.LCS.MIT.EDU:facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA   
C01168 00191	∂07-Aug-86  0136	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	non-list arguments 
C01171 00192	∂07-Aug-86  0301	@MC.LCS.MIT.EDU:Pase@DOCKMASTER.ARPA 	Scheme for the Atari ST    
C01173 00193	∂07-Aug-86  0730	@MC.LCS.MIT.EDU:jcm@ORNL-MSR.ARPA 	Re: Scheme for the Atari ST   
C01177 00194	∂08-Aug-86  0819	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU  
C01182 00195	∂08-Aug-86  1230	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[Masinter.pa: synonym streams..]   
C01184 00196	∂08-Aug-86  1712	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	"Final" comments on RRRRS
C01187 00197	∂11-Aug-86  0855	@MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:SRAUCH@UNBMVS1.BITNET 	Instructor's manual for S&ICP by Julie Sussman  
C01189 00198	∂13-Aug-86  0238	NET-ORIGIN@MC.LCS.MIT.EDU 	Re: define   
C01192 00199	∂14-Aug-86  1728	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Minutes from lunch 5 August 1986    
C01202 00200	∂14-Aug-86  1855	@MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU 	Re: Minutes from lunch 5 August 1986   
C01204 00201	∂14-Aug-86  2053	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	substring indexes    
C01207 00202	∂14-Aug-86  2233	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	r-cubed syntax (nits)
C01210 00203	∂15-Aug-86  0902	@MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA 	Re:  Minutes from lunch 5 August 1986  
C01211 00204	∂15-Aug-86  1106	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	r-cubed syntax (nits)    
C01214 00205	∂15-Aug-86  1112	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	scheme report tar file   
C01216 00206	∂15-Aug-86  1223	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	"Final" comments on RRRRS
C01220 00207	∂15-Aug-86  2150	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	"Final" comments on RRRRS
C01224 00208	∂18-Aug-86  0051	@MC.LCS.MIT.EDU:ram@YALE.ARPA 	Re:  The generality of define
C01229 00209	∂18-Aug-86  1650	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	define syntax (an apology)
C01233 00210	∂20-Aug-86  2002	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	numbers    
C01241 00211	∂22-Aug-86  0555	@MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA 	a few more comments
C01245 00212	∂22-Aug-86  1208	@MC.LCS.MIT.EDU,@SEBASTIAN.THINK.COM:gls@AQUINAS.THINK.COM 	1986 Lisp conference bibliography  
C01284 00213	∂23-Aug-86  1738	@MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	Re: numbers    
C01286 00214	∂25-Aug-86  2008	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Another nit my favorite numbers    
C01291 00215	∂28-Aug-86  0849	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	Minutes from lunch 5 August 1986  
C01293 00216	∂28-Aug-86  0908	@MC.LCS.MIT.EDU:mhwu%hplmhw@hplabs.HP.COM 	Minutes/Standardize Graphics    
C01295 00217	∂28-Aug-86  2012	@MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	Re: Minutes from lunch 5 August 1986    
C01297 00218	∂29-Aug-86  1503	@MC.LCS.MIT.EDU:andy@ads.ARPA 	graphics for Scheme
C01302 00219	∂02-Sep-86  1519	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	substring-vector-null-fill!, colitis, etc.   
C01310 00220	∂03-Sep-86  0424	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	call-with-xxput-port    
C01312 00221	∂03-Sep-86  0625	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	substring-vector-null-fill!, colitis, etc.  
C01316 00222	∂04-Sep-86  0858	@MC.LCS.MIT.EDU:F95THOMP%CARLETON.BITNET@WISCVM.WISC.EDU 	Scheme Books?    
C01318 00223	∂04-Sep-86  1828	@MC.LCS.MIT.EDU:wecker%cookie.DEC@decwrl.DEC.COM 	Please delete me from this distribution list, thanks - dave 
C01319 00224	∂05-Sep-86  1947	@MC.LCS.MIT.EDU:mh@BU-CS.BU.EDU 	list   
C01320 00225	∂08-Sep-86  0330	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA 	Beginners question: Advising methods in TI scheme 
C01323 00226	∂08-Sep-86  0826	@MC.LCS.MIT.EDU:philbin-jim@YALE.ARPA 	Re: [THOMAS: Scheme Books?]    
C01325 00227	∂08-Sep-86  0848	@MC.LCS.MIT.EDU:carr%utah-orion@utah-cs.arpa 	scoops   
C01327 00228	∂08-Sep-86  1334	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA 	Beginners question: Advising methods in TI scheme 
C01330 00229	∂08-Sep-86  1509	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Good & bad news
C01333 00230	∂08-Sep-86  1614	@MC.LCS.MIT.EDU:wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA 	substring-vector-null-fill!, coliti  
C01335 00231	∂08-Sep-86  2212	@MC.LCS.MIT.EDU:asrivast%tilde%ti-csl.csnet@CSNET-RELAY.ARPA 	Advising methods in TI Scheme    
C01338 00232	∂09-Sep-86  0429	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Slade's book in bib?    
C01340 00233	∂13-Sep-86  2054	@MC.LCS.MIT.EDU:fowler@rochester.arpa 	Re:  Prolog in Scheme?    
C01342 00234	∂14-Sep-86  0204	@MC.LCS.MIT.EDU:MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU 	Prolog in Scheme? 
C01344 00235	∂15-Sep-86  0450	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Prolog in Scheme?   
C01346 00236	∂15-Sep-86  1223	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Begin in the Formal Semantics
C01348 00237	∂15-Sep-86  1237	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Begin in the Formal Semantics 
C01351 00238	∂15-Sep-86  1243	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Begin in the Formal Semantics 
C01353 00239	∂15-Sep-86  1910	@MC.LCS.MIT.EDU:asrivast%tilde%ti-csl.csnet@CSNET-RELAY.ARPA 	Advising methods in TI Scheme    
C01356 00240	∂17-Sep-86  1224	@MC.LCS.MIT.EDU:prlb2!vauclair@seismo.CSS.GOV 	Request for information on new releases.   
C01361 00241	∂22-Sep-86  1441	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Revised↑3 Report on Scheme    
C01363 00242	∂24-Sep-86  0739	@MC.LCS.MIT.EDU:DLW@ALDERAAN.SCRC.Symbolics.COM 	[MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU: Prolog in Scheme?] 
C01366 00243	∂24-Sep-86  0936	@MC.LCS.MIT.EDU:searfus@lll-icdc.arpa 	please add me ...    
C01367 00244	∂25-Sep-86  0750	@MC.LCS.MIT.EDU:TIM@cis.upenn.edu 	prolog in scheme    
C01370 00245	∂25-Sep-86  1309	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	prolog in scheme   
C01373 00246	∂28-Sep-86  0818	@MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Prolog in Scheme   
C01375 00247	∂30-Sep-86  0507	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Refering to the Revised↑3 Report on Scheme  
C01377 00248	∂01-Oct-86  1416	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	R↑3RS sources  
C01379 00249	∂02-Oct-86  0803	@MC.LCS.MIT.EDU:GOERZ@SUMEX-AIM.ARPA 	Lost mail   
C01381 00250	∂02-Oct-86  1013	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Lost mail 
C01383 00251	∂02-Oct-86  1114	@MC.LCS.MIT.EDU:mohammad%utah-orion@utah-cs.arpa 	Can anyone hear me? 
C01385 00252	∂02-Oct-86  1714	@MC.LCS.MIT.EDU:zorn@kim.Berkeley.EDU 	I am interested in gathering `significant' Scheme programs...
C01388 00253	∂06-Oct-86  2336	@MC.LCS.MIT.EDU:dan%umass-boston.csnet@CSNET-RELAY.ARPA 	SCHEME implementations 
C01390 00254	∂15-Oct-86  0606	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Object-Oriented Schemes 
C01393 00255	∂16-Oct-86  1410	@MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Public Domain 
C01396 00256	∂20-Oct-86  0417	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Re:  Public Domain 
C01398 00257	∂20-Oct-86  1205	@MC.LCS.MIT.EDU:mhwu%hplmhw@hplabs.HP.COM 	[harris@hplwhh: Re: [ramsdell%faron@mitre-bedford.ARPA: Object-Oriented Schemes]] 
C01400 00258	∂27-Oct-86  1824	@MC.LCS.MIT.EDU:brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA 	Multiple Values: A Survey 
C01414 00259	∂27-Oct-86  1859	@MC.LCS.MIT.EDU:brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA 	Multiple Values 
C01417 00260	∂27-Oct-86  2205	@MC.LCS.MIT.EDU:brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA 	Multiple Values: An Opinion    
C01432 00261	∂28-Oct-86  0556	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Multiple values    
C01436 00262	∂28-Oct-86  0615	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	Multiple values
C01438 00263	∂28-Oct-86  1358	@MC.LCS.MIT.EDU:andy@hobbes.ARPA 	Re:  Multiple values 
C01441 00264	∂30-Oct-86  0139	@MC.LCS.MIT.EDU:harris%hplwhh@HPLABS.HP.COM 	Re: Multiple Values: An Opinion    
C01449 00265	∂30-Oct-86  1228	@MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA 	multiple values 
C01452 00266	∂30-Oct-86  1339	@MC.LCS.MIT.EDU:jinx%geneva.ai.mit.edu@CSNET-RELAY.ARPA 	Multiple Values: An Opinion 
C01460 00267	∂30-Oct-86  1520	@MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU 	Re: multiple values
C01464 00268	∂30-Oct-86  2204	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple values
C01474 00269	∂31-Oct-86  1840	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple values
C01479 00270	∂31-Oct-86  1916	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Journal of Lisp and Symbolic Computation -- call for papers 
C01486 00271	∂03-Nov-86  0855	@MC.LCS.MIT.EDU:gls@Think.COM 	Marvel?  
C01490 00272	∂03-Nov-86  1221	@MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU 	gls@AQUINAS/cc  
C01494 00273	∂05-Nov-86  0305	@MC.LCS.MIT.EDU:GOERZ@SUMEX-AIM.ARPA 	[Gunther Goerz <GOERZ@SUMEX-AIM.ARPA>: CScheme for 68K]  
C01496 00274	∂07-Nov-86  0351	@MC.LCS.MIT.EDU:enea!tut!jh@seismo.CSS.GOV 	eval and orbit  
C01499 00275	∂07-Nov-86  1716	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Automatic removal from list...
C01502 00276	∂07-Nov-86  1817	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	MIT AIM 848a   
C01503 00277	∂07-Nov-86  1839	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Hot off the press...
C01507 00278	∂08-Nov-86  1121	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple  
C01508 00279	∂08-Nov-86  1303	@MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:REMARCK@UCLASSCF.BITNET 	This account is scheduled to be deleted soon...    
C01510 00280	∂09-Nov-86  0851	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	eval and orbit
C01513 00281	∂10-Nov-86  1301	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@RELAY.CS.NET 	Re: multiple values 
C01519 00282	∂10-Nov-86  1904	@MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU 	silly multiple values   
C01523 00283	∂11-Nov-86  0853	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Scheme errors? 
C01526 00284	∂13-Nov-86  0752	@MC.LCS.MIT.EDU:sieber-john@YALE.ARPA 	Add me to the list   
C01528 00285	∂15-Nov-86  1839	@MC.LCS.MIT.EDU:reddy@a.cs.uiuc.edu 	make-environment  
C01530 00286	∂15-Nov-86  1913	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@RELAY.CS.NET 	question: S&ICP teacher's manual and query language   
C01532 00287	∂15-Nov-86  1951	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@RELAY.CS.NET 	question: S&ICP teacher's manual and query language   
C01535 00288	∂16-Nov-86  1021	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	make-environment (long)  
C01540 00289	∂18-Nov-86  0915	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Scheme reports information request 
C01543 00290	∂22-Nov-86  1845	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	truncate  
C01545 00291	∂25-Nov-86  1315	@MC.LCS.MIT.EDU:camp%home%ti-csl.csnet@RELAY.CS.NET 	PC Scheme Utilities   
C01549 00292	∂03-Dec-86  1055	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Scheme redistribution for BITNET   
C01551 00293	∂08-Dec-86  0049	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	Ambiguity in number syntax    
C01553 00294	∂08-Dec-86  0835	@MC.LCS.MIT.EDU:muller@BU-CS.BU.EDU 	IBM PC Scheme
C01555 00295	∂08-Dec-86  0934	@MC.LCS.MIT.EDU:HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	IBM PC Scheme  
C01557 00296	∂08-Dec-86  1016	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	Ambiguity in number syntax    
C01559 00297	∂09-Dec-86  0812	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	(define foo)   
C01563 00298	∂17-Dec-86  0712	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	What is comma-dot? 
C01565 00299	∂31-Dec-86  1100	@MC.LCS.MIT.EDU:NETWORK%FRSAC11.BITNET@WISCVM.WISC.EDU 	SCOOPS   
C01568 00300	∂31-Dec-86  1319	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	What is comma-dot?  
C01570 00301	∂31-Dec-86  1333	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[COMSAT: Msg of Monday, 22 December 1986 16:31-EST]    
C01578 00302	∂05-Jan-87  0803	@MC.LCS.MIT.EDU:NETWORK%FRSAC11.BITNET@WISCVM.WISC.EDU 	SYMBOLIC COMPUTATION.   
C01581 00303	∂05-Jan-87  2047	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	Re: What is comma-dot?
C01583 00304	∂06-Jan-87  0824	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	What is comma-dot? 
C01586 00305	∂10-Jan-87  1130	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	2nd test  
C01587 00306	∂16-Jan-87  0850	@MC.LCS.MIT.EDU:dfried%iuvax.cs.indiana.edu@RELAY.CS.NET 	multiple values and T 
C01594 00307	∂16-Jan-87  1400	@MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA 	Re: multiple values and T  
C01598 00308	∂16-Jan-87  1645	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple values
C01606 00309	∂16-Jan-87  1656	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[vanroggen%bizet.DEC: LISP POINTERS newsletter announcement]
C01612 00310	∂18-Jan-87  2027	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Scheme time   
C01615 00311	∂25-Jan-87  1837	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[vanroggen%bach.DEC: Looking for Lisps...]   
C01620 00312	∂02-Feb-87  1040	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Time Scales   
C01623 00313	∂03-Feb-87  0433	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	X windows
C01625 00314	∂04-Feb-87  0744	@MC.LCS.MIT.EDU:andy@hobbes.ads.ARPA 	Re:  X windows   
C01628 00315	∂05-Feb-87  0742	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Windows  
C01630 00316	∂20-Feb-87  0746	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[hay%ubc.csnet: no mail] 
C01632 00317	∂24-Feb-87  0834	@MC.LCS.MIT.EDU:Larry_Brooks.EdServices@Xerox.COM 	help -- set command
C01635 00318	∂26-Feb-87  0457	@MC.LCS.MIT.EDU:Larry_Brooks.EdServices@Xerox.COM 	Re: help -- set command 
C01637 00319	∂04-Mar-87  0925	@MC.LCS.MIT.EDU:bc@MEDIA-LAB.MEDIA.MIT.EDU 	OOPSs for Scheme, MacScheme    
C01639 00320	∂04-Mar-87  1200	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	r↑2 vs. r↑3    
C01645 00321	∂04-Mar-87  1808	@MC.LCS.MIT.EDU:cpd@CS.UCLA.EDU 	Re:  r↑2 vs. r↑3 
C01659 00322	∂05-Mar-87  1253	@MC.LCS.MIT.EDU:wolfgang%cantuar%math.waterloo.edu@RELAY.CS.NET 	Re:  OOPSs for Scheme, MacScheme   
C01661 00323	∂05-Mar-87  1955	@MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET 	Tiny Object System    
C01673 00324	∂07-Mar-87  0351	@MC.LCS.MIT.EDU:munnari!cidam.oz!mg@seismo.CSS.GOV 	distribution list 
C01675 00325	∂09-Mar-87  0055	@MC.LCS.MIT.EDU:wolfgang%cantuar%math.waterloo.edu@RELAY.CS.NET 	Re:  distribution list   
C01677 00326	∂10-Mar-87  1930	@MC.LCS.MIT.EDU:jar@ZURICH.AI.MIT.EDU 	test suite candidate 
C01680 00327	∂10-Mar-87  2309	@MC.LCS.MIT.EDU:cth%iucs.cs.indiana.edu@RELAY.CS.NET   
C01686 00328	∂11-Mar-87  2251	@MC.LCS.MIT.EDU:cth@IUCS.CS.INDIANA.EDU 	Scheme 84
C01692 00329	∂12-Mar-87  0356	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET 	Question: are theres ANY VIDEO TAPES available for Scheme ?
C01695 00330	∂12-Mar-87  0608	@MC.LCS.MIT.EDU:dyb@IUVAX.CS.INDIANA.EDU 	Re:  test suite candidate   
C01698 00331	∂16-Mar-87  1056	@MC.LCS.MIT.EDU:DAN@cis.upenn.edu 	Revised Revised Revised Report on Scheme
C01700 00332	∂16-Mar-87  1517	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Revised↑3 Report on Scheme administrivia    
C01704 00333	∂16-Mar-87  2003	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Request for public domain Scheme programs    
C01706 00334	∂17-Mar-87  0847	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Revised↑3 Report on Scheme administrivia    
C01708 00335	∂17-Mar-87  1405	@MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU 	eqv?   
C01710 00336	∂17-Mar-87  1526	@MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM 	Re: Question: are theres ANY VIDEO TAPES available for Scheme ?  
C01712 00337	∂22-Mar-87  1714	@MC.LCS.MIT.EDU:munnari!cidam.oz!mg@seismo.CSS.GOV 	dump-world problem on 4.2BSD vax (version 4 C-scheme)
C01715 00338	∂23-Mar-87  0752	@MC.LCS.MIT.EDU:muller@bu-cs.bu.edu 	Scheme mode in GNU Emacs    
C01717 00339	∂23-Mar-87  0850	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	Scheme mode in GNU Emacs 
C01720 00340	∂23-Mar-87  2309	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET 	Looking for comments on an introductory article about Scheme    
C01724 00341	∂24-Mar-87  1029	@MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET 	Scheme mode in GNU Emacs   
C01726 00342	∂25-Mar-87  0925	@MC.LCS.MIT.EDU:mcvax!crcge1!adams@seismo.CSS.GOV 	scheme mailing list
C01728 00343	∂26-Mar-87  0235	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET 	Private message to Cynthia Mason. (mail problem) 
C01730 00344	∂26-Mar-87  0356	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET 	Correction mistake: Looking for comments on an introductory article ..    
C01733 00345	∂27-Mar-87  1850	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	multiple return values
C01743 00346	∂27-Mar-87  1858	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	Let's get together again   
C01747 00347	∂27-Mar-87  2120	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple return values   
C01750 00348	∂28-Mar-87  1146	@MC.LCS.MIT.EDU:KMP@YUKON.SCRC.Symbolics.COM 	Let's get together again
C01753 00349	∂28-Mar-87  1400	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	Let's get together again 
C01755 00350	∂28-Mar-87  2023	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	a modest macro proposal  
C01796 00351	∂29-Mar-87  1558	@MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	meeting   
C01797 00352	∂30-Mar-87  0917	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[ALAN: multiple return values]
C01800 00353	∂30-Mar-87  1023	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	[ALAN: multiple return values]
C01804 00354	∂30-Mar-87  1136	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	almost scheme in common lisp  
C01807 00355	∂30-Mar-87  1455	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	Re: multiple return values 
C01810 00356	∂30-Mar-87  1509	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	Re: Let's get together again    
C01813 00357	∂30-Mar-87  1858	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Let's get together again 
C01815 00358	∂30-Mar-87  2026	@MC.LCS.MIT.EDU:adams%tekchips.tek.com@RELAY.CS.NET 	Re: multiple return values 
C01818 00359	∂30-Mar-87  2112	@MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU 	A Couple of Fun Programs  
C01821 00360	∂31-Mar-87  1146	@MC.LCS.MIT.EDU:gls@Think.COM 	A Couple of Fun Programs
C01824 00361	∂31-Mar-87  1703	@MC.LCS.MIT.EDU:allen@bfly-vax.bbn.com 	Re: A Couple of Fun Programs  
C01826 00362	∂31-Mar-87  1743	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Scheme Numbers
C01828 00363	∂31-Mar-87  1829	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	multiple return values  
C01835 00364	∂31-Mar-87  2009	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple return values   
C01839 00365	∂31-Mar-87  2025	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple return values   
C01841 00366	∂31-Mar-87  2037	@MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU 	More on Fun Programs      
C01843 00367	∂01-Apr-87  0215	@MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:ETSTMOL@HDETUD1.BITNET 	NOTE from ETSTMOL
C01845 00368	∂01-Apr-87  0546	@MC.LCS.MIT.EDU:kwh@ 	multiple return values 
C01847 00369	∂01-Apr-87  1030	@MC.LCS.MIT.EDU:gls@Think.COM 	A Couple of Fun Programs
C01849 00370	∂01-Apr-87  1142	@MC.LCS.MIT.EDU:gls@Think.COM 	multiple return values  
C01852 00371	∂01-Apr-87  1158	@MC.LCS.MIT.EDU:gls@Think.COM 	Apologies
C01854 00372	∂01-Apr-87  1907	@MC.LCS.MIT.EDU:allen@bfly-vax.bbn.com 	Re: A Couple of Fun Programs  
C01857 00373	∂01-Apr-87  1953	@MC.LCS.MIT.EDU:allen@bfly-vax.bbn.com 	Re: A Couple of Fun Programs  
C01860 00374	∂01-Apr-87  2232	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	multiple return values   
C01863 00375	∂01-Apr-87  2333	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	multiple return values (LONG) 
C01876 00376	∂02-Apr-87  0714	@MC.LCS.MIT.EDU:hoey@nrl-aic.ARPA 	More bum code  
C01878 00377	∂02-Apr-87  1129	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	multiple return values (LONG)
C01888 00378	∂02-Apr-87  1138	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	multiple return values  
C01893 00379	∂03-Apr-87  1043	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	optional arguments 
C01906 00380	∂03-Apr-87  1415	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	optional arguments  
C01910 00381	∂04-Apr-87  2028	@MC.LCS.MIT.EDU:RMACHUCA@SIMTEL20.ARPA 	TIPC windows   
C01912 00382	∂04-Apr-87  2330	@MC.LCS.MIT.EDU:tim@linc.cis.upenn.edu 	scheme in prolog    
C01917 00383	∂06-Apr-87  0927	@MC.LCS.MIT.EDU:RMACHUCA@SIMTEL20.ARPA 	Need consultant
C01919 00384	∂06-Apr-87  1044	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	optional arguments 
C01924 00385	∂06-Apr-87  1232	@MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU 	Optionals  
C01926 00386	∂06-Apr-87  1241	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	current membership  
C01931 00387	∂06-Apr-87  1319	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	optional arguments  
C01939 00388	∂06-Apr-87  1404	@MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU 	Taste      
C01943 00389	∂06-Apr-87  1431	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Optionals 
C01946 00390	∂07-Apr-87  0542	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	macros   
C01948 00391	∂07-Apr-87  0825	@MC.LCS.MIT.EDU:gls@Think.COM 	Optionals
C01952 00392	∂07-Apr-87  1337	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	macros    
C01955 00393	∂07-Apr-87  1710	@MC.LCS.MIT.EDU:mike%acorn@LIVE-OAK.LCS.MIT.EDU 	scheme in prolog
C01962 00394	∂07-Apr-87  1944	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Taste     
C01968 00395	∂08-Apr-87  0803	@MC.LCS.MIT.EDU:VERACSD@A.ISI.EDU 	Concurrency in Scheme    
C01970 00396	∂08-Apr-87  0917	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	macros   
C01974 00397	∂08-Apr-87  1025	@MC.LCS.MIT.EDU:Kahn.pa@Xerox.COM 	Re: scheme in prolog
C01978 00398	∂08-Apr-87  1532	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	towards an agenda  
C01982 00399	∂08-Apr-87  2121	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	multiple values
C01987 00400	∂08-Apr-87  2219	@MC.LCS.MIT.EDU:munnari!goanna.oz!hal@seismo.CSS.GOV 	towards an agenda    
C01989 00401	∂08-Apr-87  2243	@MC.LCS.MIT.EDU:tim@linc.cis.upenn.edu 	scheme in prolog    
C01992 00402	∂09-Apr-87  0052	@MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA 	Re: scheme in prolog  
C01996 00403	∂09-Apr-87  0732	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	towards an agenda   
C01998 00404	∂09-Apr-87  1001	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	readers & tokenizers
C02005 00405	∂09-Apr-87  1012	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	readers & tokenizers
C02007 00406	∂09-Apr-87  1324	@MC.LCS.MIT.EDU:gls@Think.COM 	readers & tokenizers    
C02010 00407	∂09-Apr-87  1412	@MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM 	multiple return values 
C02015 00408	∂09-Apr-87  1420	@MC.LCS.MIT.EDU:andy@hobbes.ads.ARPA 	readers & tokenizers  
C02022 00409	∂09-Apr-87  1638	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	number syntax 
C02025 00410	∂09-Apr-87  1648	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	readers & tokenizers    
C02028 00411	∂09-Apr-87  1803	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	number syntax  
C02033 00412	∂09-Apr-87  1848	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	yellow pages   
C02036 00413	∂09-Apr-87  1921	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	readers & tokenizers
C02043 00414	∂09-Apr-87  2348	@MC.LCS.MIT.EDU:andy@hobbes.ads.ARPA 	Re:  readers & tokenizers  
C02052 00415	∂10-Apr-87  0734	@MC.LCS.MIT.EDU:jmiller@MEPHISTOPHELES.AI.MIT.EDU 	yellow pages  
C02054 00416	∂10-Apr-87  0944	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	macros   
C02061 00417	∂10-Apr-87  1000	@MC.LCS.MIT.EDU:gls@Think.COM 	number syntax 
C02063 00418	∂10-Apr-87  1238	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	number syntax  
C02066 00419	∂10-Apr-87  1637	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	macros    
C02077 00420	∂10-Apr-87  1646	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	meeting dates/times/places    
C02080 00421	∂10-Apr-87  1653	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	number syntax 
C02083 00422	∂10-Apr-87  2103	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	Re: number syntax
C02092 00423	∂11-Apr-87  0814	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	towards an agenda - yeller pages   
C02096 00424	∂12-Apr-87  1158	@MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:LISP@BROWNVM.BITNET 	Scheme85 interpreter from Indiana...    
C02098 00425	∂12-Apr-87  1724	@MC.LCS.MIT.EDU:harris%hplwhh@hplabs.HP.COM 	Re: number syntax   
C02102 00426	∂12-Apr-87  2125	@MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET 	Re:  meeting dates/times/places 
C02104 00427	∂13-Apr-87  0951	@MC.LCS.MIT.EDU:larus@paris.Berkeley.EDU 	Scheme programs   
C02106 00428	∂13-Apr-87  1346	@MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu 	Pattern matching, not optional arguments    
C02115 00429	∂13-Apr-87  2114	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	towards an agenda - yeller pages   
C02119 00430	∂13-Apr-87  2343	@MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu 	meeting dates  
C02122 00431	∂14-Apr-87  0048	@MC.LCS.MIT.EDU:mcvax!inria!crcge1.cge.fr!adams@seismo.CSS.GOV 	Scheme85 interpreter from Indiana...
C02124 00432	∂15-Apr-87  0952	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Pattern matching, not optional arguments
C02131 00433	∂16-Apr-87  1319	@MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu 	Pattern matching, not optional arguments    
C02143 00434	∂16-Apr-87  1329	@MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu 	Pattern matching, not optional arguments    
C02155 00435	∂16-Apr-87  1646	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	meeting dates/times 
C02158 00436	∂20-Apr-87  0906	@MC.LCS.MIT.EDU:bartley%Home%ti-csl.csnet@RELAY.CS.NET 	Re: meeting dates/times 
C02160 00437	∂22-Apr-87  1357	@MC.LCS.MIT.EDU:unido!gmdzi!LISPM-1.GMD!@lispm-1.gmd.jc 	Please add ...    
C02162 00438	∂22-Apr-87  1510	@MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu 	match questions    
C02168 00439	∂22-Apr-87  1746	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	match questions     
C02173 00440	∂23-Apr-87  0957	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	match questions     
C02175 00441	∂23-Apr-87  1143	@MC.LCS.MIT.EDU:andy%hobbes@ads.ARPA 	Re:  match questions  
C02178 00442	∂23-Apr-87  1324	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	Re: match questions   
C02186 00443	∂23-Apr-87  1343	@MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu 	Scheme pattern matcher  
C02196 00444	∂23-Apr-87  1433	@MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu 	match questions    
C02200 00445	∂23-Apr-87  1726	@MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU 	Re: match questions     
C02205 00446	∂23-Apr-87  2014	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	The verdict: 27-28 June  
C02207 00447	∂24-Apr-87  1720	@MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET 	match questions  
C02214 00448	∂24-Apr-87  1854	@MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU 	Re: match questions     
C02218 00449	∂26-Apr-87  1256	@MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM 	match questions   
C02222 00450	∂27-Apr-87  1241	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	match questions     
C02224 00451	∂28-Apr-87  0645	@MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:MDEBAR@BNANDP11.BITNET 	Scoops 
C02226 00452	∂29-Apr-87  1108	@MC.LCS.MIT.EDU:cth@iucs.cs.indiana.edu 	Engine operating system (long msg)
C02250 00453	∂30-Apr-87  1603	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	another set of primitives for concurrency 
C02256 00454	∂30-Apr-87  1928	@MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu 	environment networks  
C02258 00455	∂09-May-87  1206	@MC.LCS.MIT.EDU:VERACSD@A.ISI.EDU 	Re: Engine operating system (long msg)  
C02260 00456	∂14-May-87  1244	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	Scheme for lisp machines   
C02261 00457	∂18-May-87  1745	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET 	Should ":" be an extended alphabetic character? 
C02264 00458	∂18-May-87  1910	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  Should ":" be an extended alphabetic character? 
C02266 00459	∂18-May-87  1929	@MC.LCS.MIT.EDU:andy%hobbes@ads.ARPA 	Re:  Should ":" be an extended alphabetic character?
C02270 00460	∂19-May-87  0654	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	Should ":" be an extended alphabetic character?   
C02275 00461	∂19-May-87  0818	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Should ":" be an extended alphabetic character?   
C02278 00462	∂19-May-87  0918	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET 	Should ":" be an extended alphabetic character? 
C02281 00463	∂19-May-87  1645	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com 	Re: Should ":" be an extended alphabetic character?
C02287 00464	∂19-May-87  2117	@MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU 	Should ":" be an extended alphabetic character?  
C02289 00465	∂20-May-87  1001	 	June meeting 
C02291 00466	∂20-May-87  1949	@MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu    
C02294 00467	∂21-May-87  0900	@MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu    
C02297 00468	∂21-May-87  1027	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	June meeting -- accommodations
C02302 00469	∂21-May-87  1112	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	who will be there   
C02306 00470	∂21-May-87  1300	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	correction
C02307 00471	∂21-May-87  2155	@MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu    
C02309 00472	∂21-May-87  2314	@MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu 	Getting scoops... (Please give arpa pathway back.)  
C02311 00473	∂22-May-87  0732	@MC.LCS.MIT.EDU,@MIT-Multics.ARPA:NETWORK@FRSAC11.BITNET 	CScheme Rel 5    
C02314 00474	∂22-May-87  1043	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	CScheme Rel 5  
C02317 00475	∂23-May-87  2256	@MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu 	Scoops bug fix   
C02319 00476	∂25-May-87  0853	@MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu 	scoops bug found 
C02321 00477	∂26-May-87  1413	@MC.LCS.MIT.EDU,@RELAY.CS.NET:janeta@albatross.uss.tek.com 	Forwarded Mail 
C02326 00478	∂01-Jun-87  1824	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com 	customizable reader  
C02336 00479	∂03-Jun-87  0832	@MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU 	OOPSLA Lisp and Object-Oriented Programming Workshop    
C02339 00480	∂03-Jun-87  1121	@MC.LCS.MIT.EDU:RMACHUCA@SIMTEL20.ARPA 	Edwin source   
C02340 00481	∂03-Jun-87  1622	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	Edwin source   
C02343 00482	∂04-Jun-87  2032	@MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu 	error-handler    
C02345 00483	∂05-Jun-87  0703	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	message passing
C02349 00484	∂05-Jun-87  1612	@MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu 	error handler for cscheme (MIT) 
C02351 00485	∂06-Jun-87  2108	@MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu 	scoops--bug fixes 6/6 
C02355 00486	∂08-Jun-87  1920	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET 	number syntax and exactness 
C02366 00487	∂09-Jun-87  0226	@MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU 	Better late than never  
C02389 00488	∂09-Jun-87  1603	@MC.LCS.MIT.EDU:ucdavis!iris!windley@ucbvax.Berkeley.EDU 	Scheme Source    
C02391 00489	∂10-Jun-87  1945	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET 	Agenda  
C02398 00490	∂10-Jun-87  2055	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	attending 
C02401 00491	∂11-Jun-87  1013	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	on-campus accommodations 
C02402 00492	∂11-Jun-87  1755	@MC.LCS.MIT.EDU:ucdavis!iris!windley@ucbvax.Berkeley.EDU 	Compiling Scheme on a hp200
C02405 00493	∂11-Jun-87  2347	@MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	Re: number syntax and exactness    
C02414 00494	∂12-Jun-87  1204	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	Compiling Scheme on a hp200   
C02417 00495	∂12-Jun-87  1501	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	no free lunch  
C02419 00496	∂12-Jun-87  1513	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	directions
C02421 00497	∂12-Jun-87  2016	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	no free lunch  
C02423 00498	∂14-Jun-87  0942	@MC.LCS.MIT.EDU:sherin@linc.cis.upenn.edu 	SCOOPS bug-fixes 
C02431 00499	∂15-Jun-87  1132	@MC.LCS.MIT.EDU:NETWORK%FRSAC11.BITNET@MITVMA.MIT.EDU 	Books on Scheme
C02433 00500	∂15-Jun-87  1437	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com 	Session chair   
C02435 00501	∂18-Jun-87  0452	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	SCOOPS newsgroup?  RSVP
C02438 00502	∂18-Jun-87  1908	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley%home@TI-CSL.CSNET 	number syntax and exactness 
C02447 00503	∂23-Jun-87  1955	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	sundry    
C02452 00504	∂30-Jun-87  1800	@MC.LCS.MIT.EDU:matthias@iucs.cs.indiana.edu 	Macros   
C02457 00505	∂01-Jul-87  0728	@MC.LCS.MIT.EDU:matthias@iucs.cs.indiana.edu 	Macros   
C02462 00506	∂01-Jul-87  0836	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Macros    
C02464 00507	∂01-Jul-87  1046	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	test message, ignore
C02466 00508	∂03-Jul-87  0737	@MC.LCS.MIT.EDU:matthias@iucs.cs.indiana.edu 	Macros again: read first
C02474 00509	∂06-Jul-87  0517	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Tigger on Scheme   
C02477 00510	∂06-Jul-87  0530	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Tigger on Scheme   
C02479 00511	∂06-Jul-87  0845	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Macros again: read first
C02482 00512	∂06-Jul-87  1147	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Tigger on Scheme 
C02484 00513	∂08-Jul-87  1607	@MC.LCS.MIT.EDU,@RELAY.CS.NET:adams@tekchips.tek.com 	structures 
C02493 00514	∂09-Jul-87  0853	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	re: structures   
C02495 00515	∂09-Jul-87  1935	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	structures  
C02497 00516	∂09-Jul-87  2321	@MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU 	re: structures
C02501 00517	∂10-Jul-87  2311	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com 	Minutes of the Scheme meeting etc.  
C02527 00518	∂12-Jul-87  1702	@MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU 	(DELAYED? <obj>) predicate 
C02528 00519	∂12-Jul-87  1711	@MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU 	DELAYED? predicate    
C02533 00520	∂15-Jul-87  1303	@MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu 	optional arguments    
C02556 00521	∂21-Jul-87  1512	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Recognizing QUOTE deemed harmful to EVAL's laziness  
C02585 00522	∂21-Jul-87  1956	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Recognizing QUOTE deemed harmful to EVAL's laziness    
C02589 00523	∂22-Jul-87  0919	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	modules  
C02597 00524	∂22-Jul-87  1259	@MC.LCS.MIT.EDU:reddy@b.cs.uiuc.edu 	Recognizing QUOTE deemed harmful to EVAL's laziness  
C02609 00525	∂23-Jul-87  0018	@MC.LCS.MIT.EDU,@RELAY.CS.NET:stevev@tekchips.tek.com 	
C02612 00526	∂23-Jul-87  0905	@MC.LCS.MIT.EDU:mike%acorn@LIVE-OAK.LCS.MIT.EDU 	Recognizing QUOTE deemed harmful to EVAL's laziness
C02617 00527	∂23-Jul-87  1017	@MC.LCS.MIT.EDU:reddy@b.cs.uiuc.edu 	Recognizing QUOTE deemed harmful to EVAL's laziness  
C02620 00528	∂23-Jul-87  1207	@MC.LCS.MIT.EDU:kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu 	futures in cscheme
C02624 00529	∂23-Jul-87  1420	@MC.LCS.MIT.EDU:pierson@multimax.ARPA 	futures in cscheme   
C02675 00530	∂23-Jul-87  2003	@MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Recognizing QUOTE deemed harmful to EVAL's laziness   
C02677 00531	∂24-Jul-87  0337	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Recognising QUOTE deemed harmful to EVAL's laziness   
C02682 00532	∂24-Jul-87  0415	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Recognising QUOTE deemed harmful to EVAL's laziness   
C02703 00533	∂24-Jul-87  2128	@MC.LCS.MIT.EDU:narain%pluto@rand-unix.ARPA 	Quotation regarding QUOTE
C02706 00534	∂29-Jul-87  0642	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	backquote semantics 
C02709 00535	∂12-Aug-87  1601	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com 	Gabriel benchmarks in Scheme   
C02713 00536	∂12-Aug-87  1648	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com 	MacScheme+Toolsmith Version 1.0
C02718 00537	∂12-Aug-87  1853	@MC.LCS.MIT.EDU:fateman@renoir.Berkeley.EDU 	Re: Gabriel benchmarks in Scheme   
C02721 00538	∂12-Aug-87  2227	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Gabriel benchmarks in Scheme    
C02723 00539	∂13-Aug-87  0900	@MC.LCS.MIT.EDU:jrl@ZERMATT.LCS.MIT.EDU 	Re: MacScheme+Toolsmith Version 1.0    
C02725 00540	∂13-Aug-87  1041	@MC.LCS.MIT.EDU:KSWANSON%SUNRISE.BITNET@MITVMA.MIT.EDU 	C Scheme 
C02727 00541	∂13-Aug-87  1528	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	Gabriel benchmarks in Scheme   
C02731 00542	∂13-Aug-87  2355	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com 	FRPOLY philosophy of benchmarking  
C02735 00543	∂14-Aug-87  0034	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com 	selective linking in Lisp 
C02740 00544	∂14-Aug-87  0128	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Gabriel benchmarks in Scheme 
C02743 00545	∂14-Aug-87  1757	@MC.LCS.MIT.EDU,@dewey.udel.edu,@localhost:saunders@UDEL.EDU 	Re: FRPOLY philosophy of benchmarking     
C02745 00546	∂14-Aug-87  1847	@MC.LCS.MIT.EDU:gjc@bucsf.bu.edu 	Re:  selective linking in Lisp 
C02747 00547	∂16-Aug-87  1804	@MC.LCS.MIT.EDU:gjc@bucsf.bu.edu 	Re:  Gabriel benchmarks in Scheme   
C02750 00548	∂16-Aug-87  1931	@MC.LCS.MIT.EDU:masinter.pa@Xerox.COM 	Re: selective linking in Lisp  
C02753 00549	∂17-Aug-87  0257	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Pausing garbage collection   
C02755 00550	∂18-Aug-87  0759	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Pausing garbage collection    
C02757 00551	∂19-Aug-87  1233	@MC.LCS.MIT.EDU:DOMAHONY%IRLEARN.BITNET@MITVMA.MIT.EDU 	Scheme Instructors Guide
C02759 00552	∂20-Aug-87  1019	@MC.LCS.MIT.EDU:KURT%sungod.nsc.syr.edu@amax.npac.syr.edu 	C Scheme   
C02761 00553	∂22-Aug-87  2122	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme tutorial   
C02764 00554	∂27-Aug-87  0956	@MC.LCS.MIT.EDU:JELROBN%YALEVM.BITNET@MITVMA.MIT.EDU 	Please remove me from the mailing list.  
C02766 00555	∂27-Aug-87  2006	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	On-line Documentation  
C02768 00556	∂28-Aug-87  0533	@MC.LCS.MIT.EDU:DEMOL%NUSVM.BITNET@MITVMA.MIT.EDU 	info file
C02770 00557	∂28-Aug-87  1102	@MC.LCS.MIT.EDU:wtm@buengc.bu.edu 	Please remove me from the mailing list  
C02772 00558	∂01-Sep-87  1825	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	getting scheme up on a 3B1  
C02776 00559	∂02-Sep-87  2333	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Looking for Scheme implementation
C02778 00560	∂03-Sep-87  0013	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Thanks for comments about S&ICP book  
C02780 00561	∂03-Sep-87  0409	@MC.LCS.MIT.EDU:gjc@bucsf.bu.edu   
C02782 00562	∂03-Sep-87  0623	@MC.LCS.MIT.EDU:alpert@bu-cs.bu.edu 	Please remove this address from the mailing list
C02784 00563	∂03-Sep-87  0730	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Looking for Scheme implementation  
C02786 00564	∂03-Sep-87  1147	@MC.LCS.MIT.EDU:ab@bu-cs.bu.edu 	Please remove my address from the mailing list 
C02788 00565	∂08-Sep-87  0845	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Preemptive garbage collection
C02791 00566	∂09-Sep-87  2235	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	test message, ignore
C02792 00567	∂10-Sep-87  0549	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	On-line documentation on T and/or CSCHEME. 
C02794 00568	∂10-Sep-87  1444	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Wanted: Cscheme5 (In English)    
C02797 00569	∂14-Sep-87  1121	@MC.LCS.MIT.EDU:ADLER1%BRANDEIS.BITNET@MITVMA.MIT.EDU 	subscription   
C02799 00570	∂15-Sep-87  0209	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Wanted: SCHEME/COMMON-LISP compiler documentation    
C02803 00571	∂15-Sep-87  2042	@MC.LCS.MIT.EDU:munnari!cidam.oz.au!mg@uunet.UU.NET 	prolog in scheme 
C02805 00572	∂21-Sep-87  1400	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	Wanted: Cscheme5 (In English) 
C02808 00573	∂22-Sep-87  0121	@MC.LCS.MIT.EDU:ADLER1%BRANDEIS.BITNET@MITVMA.MIT.EDU 	scoop wanted   
C02811 00574	∂24-Sep-87  2114	@MC.LCS.MIT.EDU:windley@iris.ucdavis.edu 	using editors
C02813 00575	∂25-Sep-87  2254	@MC.LCS.MIT.EDU,@RELAY.CS.NET:shneider@cui.unige.chunet 	Any Scheme for Atari and/or Amiga ?   
C02816 00576	∂28-Sep-87  0922	@MC.LCS.MIT.EDU:EDH%HNYKUN52.BITNET@MITVMA.MIT.EDU 	Scheme on Atari   
C02819 00577	∂28-Sep-87  1109	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	Any Scheme for Atari and/or Amiga ?
C02821 00578	∂30-Sep-87  0121	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Wanted Scoops for MacSheme (or help in porting) 
C02824 00579	∂02-Oct-87  0818	@MC.LCS.MIT.EDU:STCS8004%IRUCCVAX.BITNET@MITVMA.MIT.EDU 	FreeWare Scheme - IBM PS/2 or AT 
C02827 00580	∂03-Oct-87  0411	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	ibm-pc compatible CScheme compiler    
C02829 00581	∂03-Oct-87  2309	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme needed for the VAX-780    
C02833 00582	∂04-Oct-87  1113	@MC.LCS.MIT.EDU:KSWANSON%SUNRISE.BITNET@MITVMA.MIT.EDU 	R↑3RS    
C02835 00583	∂05-Oct-87  0936	@MC.LCS.MIT.EDU:RMACHUCA@SIMTEL20.ARPA 	Tex and Scheme 
C02836 00584	∂05-Oct-87  1941	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	R↑3RS
C02838 00585	∂06-Oct-87  0753	@MC.LCS.MIT.EDU:U04Z%CBEBDA3T.BITNET@MITVMA.MIT.EDU 	Re: TeX and Scheme    
C02840 00586	∂06-Oct-87  1808	@MC.LCS.MIT.EDU:RKIRCHNE%carleton.edu@RELAY.CS.NET 	R↑3RS   
C02844 00587	∂07-Oct-87  0031	NET-ORIGIN@MC.LCS.MIT.EDU 	Re: TeX and Scheme
C02846 00588	∂08-Oct-87  2114	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  R↑3RS   
C02850 00589	∂09-Oct-87  1738	@MC.LCS.MIT.EDU,@RELAY.CS.NET:RKIRCHNE@carleton.edu 	Some corrections 
C02853 00590	∂13-Oct-87  1006	@MC.LCS.MIT.EDU:esosun!vor!jackson@sdcsvax.ucsd.edu 	Tao, Sues...
C02855 00591	∂14-Oct-87  1850	@MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@BRANDEIS.CSNET 	MultiScheme
C02858 00592	∂16-Oct-87  0402	@MC.LCS.MIT.EDU,@RELAY.CS.NET:sasha@COLGATE.CSNET 	visit on 11/9?
C02860 00593	∂17-Oct-87  2226	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	CScheme question  
C02864 00594	∂17-Oct-87  2324	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: MultiScheme   
C02867 00595	∂19-Oct-87  1350	@MC.LCS.MIT.EDU:bartlett@decwrl.dec.com 	Type inference in Scheme
C02869 00596	∂20-Oct-87  0023	@MC.LCS.MIT.EDU,@RELAY.CS.NET:wand@corwin.ccs.northeastern.edu 	Type inference in Scheme  
C02873 00597	∂21-Oct-87  1244	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	Scheme84 and SPS ftp    
C02874 00598	∂21-Oct-87  1357	@MC.LCS.MIT.EDU,@RELAY.CS.NET:wand@corwin.ccs.northeastern.edu 	Semantic Prototyping System    
C02877 00599	∂21-Oct-87  1831	@MC.LCS.MIT.EDU:bartlett@decwrl.dec.com 	Type Inference in Scheme Summary  
C02881 00600	∂22-Oct-87  2305	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Where can I get C-Scheme?   
C02883 00601	∂23-Oct-87  0604	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Where can I get C-Scheme?    
C02885 00602	∂23-Oct-87  1035	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	C Scheme  
C02887 00603	∂23-Oct-87  2121	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme in the real world    
C02890 00604	∂25-Oct-87  1905	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu  	Re: Scheme in the real world    
C02893 00605	∂26-Oct-87  0853	@MC.LCS.MIT.EDU:andy%hobbes@ADS.ARPA  	applicability of "syntax" constructs
C02899 00606	∂26-Oct-87  1526	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU  	applicability of "syntax" constructs   
C02908 00607	∂26-Oct-87  1544	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com  	Re: Scheme in the real world  
C02910 00608	∂27-Oct-87  0814	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu  	Re:  applicability of "syntax" constructs 
C02912 00609	∂27-Oct-87  0947	@MC.LCS.MIT.EDU:gls@Think.COM  	applicability of "syntax" constructs  
C02914 00610	∂27-Oct-87  1039	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu  	Re: Tao, Sues... 
C02917 00611	∂27-Oct-87  1259	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU  	applicability of "syntax" constructs   
C02919 00612	∂27-Oct-87  1323	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU  	1988 LISP & FUNCTIONAL PROGRAMMING - CALL FOR PAPERS  
C02927 00613	∂27-Oct-87  1414	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu  	Re:  applicability of "syntax" constructs 
C02930 00614	∂28-Oct-87  0937	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu  	FX-87 is born    
C02935 00615	∂28-Oct-87  1726	@MC.LCS.MIT.EDU,@RELAY.CS.NET:wand@corwin.ccs.northeastern.edu  	applicability of "syntax" constructs    
C02937 00616	∂28-Oct-87  1834	@MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU  	RE: applicability of "syntax" mumble
C02939 00617	∂28-Oct-87  1857	@MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU  	CALL    
C02941 00618	∂28-Oct-87  1921	@MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU  	Where can I get C-Scheme? 
C02943 00619	∂29-Oct-87  1003	@MC.LCS.MIT.EDU:JAR@ML.AI.MIT.EDU  	policy   
C02949 00620	∂29-Oct-87  1654	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu  	Re: Where can I get C-Scheme?   
C02952 00621	∂30-Oct-87  1014	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:EDH@HNYKUN52.BITNET 	portability of SCHEME 
C02955 00622	∂30-Oct-87  1138	@MC.LCS.MIT.EDU:jdevries@ads.arpa 	Extend-Syntax for MacScheme   
C02959 00623	∂30-Oct-87  1407	@MC.LCS.MIT.EDU:sas@bfly-vax.bbn.com 	Extend-Syntax for MacScheme
C02960 00624	∂31-Oct-87  1650	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Revised(3) report: could MIT post tex source for it ??    
C02963 00625	∂01-Nov-87  0928	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	Revised(3) report: could MIT post tex source for it ?? 
C02966 00626	∂02-Nov-87  1048	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	documentation?    
C02968 00627	∂03-Nov-87  1812	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Source for Scheme?
C02970 00628	∂03-Nov-87  2205	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Tigger on Scheme   
C02973 00629	∂04-Nov-87  1702	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Tigger on Scheme / correction    
C02976 00630	∂05-Nov-87  0426	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Tigger on Scheme / correction
C02979 00631	∂06-Nov-87  0655	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Need refs for low-level (c/pascal) implementation of scheme    
C02983 00632	∂07-Nov-87  1221	@MC.LCS.MIT.EDU,@AI.AI.MIT.EDU,@REAGAN.AI.MIT.EDU,@BU-CS.BU.EDU:gjc@bucsf.bu.edu 	low level "how to scheme"   
C02985 00633	∂08-Nov-87  0241	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: low level "how to scheme"    
C02987 00634	∂08-Nov-87  1737	@MC.LCS.MIT.EDU:springer@iuvax.cs.indiana.edu 	Re:  low level "how to scheme"   
C02989 00635	∂09-Nov-87  0112	@MC.LCS.MIT.EDU:mcvax!tcdcs!omahony@uunet.UU.NET 	Solution to Exercise 1.9 
C02991 00636	∂09-Nov-87  0151	@MC.LCS.MIT.EDU:trainor@CS.UCLA.EDU 	Re: Solution to Exercise 1.9     
C02993 00637	∂09-Nov-87  1033	@MC.LCS.MIT.EDU,@AI.AI.MIT.EDU:dan@mitre-bedford.ARPA 	Removal from mailing list
C02995 00638	∂09-Nov-87  1920	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme Text  
C02997 00639	∂10-Nov-87  0953	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Wanted: SCOOPS info    
C03000 00640	∂10-Nov-87  2257	@MC.LCS.MIT.EDU:lls@mimsy.umd.edu 	Please remove me from the mailing list  
C03002 00641	∂12-Nov-87  2255	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	What is Scheme?   
C03004 00642	∂15-Nov-87  0159	NET-ORIGIN@MC.LCS.MIT.EDU 	Extend-Syntax for Everybody!
C03028 00643	∂23-Nov-87  1739	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[net%TUB.BITNET: Pretty printer]   
C03031 00644	∂23-Nov-87  1816	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[net%TUB.BITNET: Questions]   
C03034 00645	∂24-Nov-87  0006	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	SICP Sources 
C03036 00646	∂24-Nov-87  0415	@MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU 	[net%TUB.BITNET: Questions]
C03040 00647	∂24-Nov-87  1018	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  [net%TUB.BITNET: Questions] 
C03044 00648	∂24-Nov-87  1414	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[dyb: [net%TUB.BITNET: Questions]] 
C03047 00649	∂27-Nov-87  2137	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	SCHEME interpreter in Common Lisp?    
C03050 00650	∂30-Nov-87  1451	@MC.LCS.MIT.EDU:MUSE@XX.LCS.MIT.EDU 	PC Scheme    
C03051 00651	∂01-Dec-87  1234	@MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:MUSE@OZ.AI.MIT.EDU 	PC Scheme hardware interfacing   
C03054 00652	∂01-Dec-87  1510	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	The mini-SCHEME interpreter I've sent to some people 
C03057 00653	∂01-Dec-87  1610	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Lisp is Crisp! Lisp is Crisp! Lisp is Crisp! Lisp is Crisp!    
C03059 00654	∂01-Dec-87  1645	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com 	two questions   
C03063 00655	∂02-Dec-87  1640	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: (Lisp is Crisp!)↑4 
C03066 00656	∂02-Dec-87  1858	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	data structures <--> functions   
C03070 00657	∂02-Dec-87  1953	@MC.LCS.MIT.EDU:gjc@bucsf.bu.edu 	in reply to "nested parens - just say no"
C03073 00658	∂02-Dec-87  2130	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	data structures <--> functions
C03075 00659	∂03-Dec-87  1405	@MC.LCS.MIT.EDU:carr%car@cs.utah.edu 	scheme benchmarks
C03077 00660	∂03-Dec-87  1534	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Applicative languages?  Anyone?  
C03083 00661	∂04-Dec-87  0219	@MC.LCS.MIT.EDU,@RELAY.CS.NET:csnet@bernina.uucp 	Re: (Lisp is Crisp!)↑4   
C03086 00662	∂04-Dec-87  0254	@MC.LCS.MIT.EDU,@RELAY.CS.NET:csnet@bernina.uucp 	in reply to "nested parens - just say no"    
C03089 00663	∂04-Dec-87  0327	@MC.LCS.MIT.EDU,@RELAY.CS.NET:csnet@bernina.uucp 	data structures <--> functions
C03093 00664	∂04-Dec-87  0401	@MC.LCS.MIT.EDU,@RELAY.CS.NET:csnet@bernina.uucp 	data structures <--> functions
C03096 00665	∂04-Dec-87  0911	@MC.LCS.MIT.EDU:reddy@b.cs.uiuc.edu 	Applicative languages?  Anyone?  
C03099 00666	∂04-Dec-87  1400	@MC.LCS.MIT.EDU:sullivan@marge.math.binghamton.edu 	ML 
C03101 00667	∂04-Dec-87  1455	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@MITVMA.MIT.EDU:PS33@MCGILLA.NETNORTH 
C03104 00668	∂04-Dec-87  1544	@MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU 	ML implementations   
C03108 00669	∂05-Dec-87  0210	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: data structures <--> functions    
C03111 00670	∂05-Dec-87  1042	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	data structures <--> functions
C03115 00671	∂07-Dec-87  2309	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: ML  
C03118 00672	∂07-Dec-87  2309	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: ML  
C03121 00673	∂08-Dec-87  1620	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	data structures <--> functions
C03125 00674	∂09-Dec-87  0932	@MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU 	data structures <--> functions  
C03128 00675	∂10-Dec-87  0750	@MC.LCS.MIT.EDU:bruggema@iuvax.cs.indiana.edu 	Request for MacScheme source for SCOOPS    
C03130 00676	∂10-Dec-87  1152	@MC.LCS.MIT.EDU:bruggema@iuvax.cs.indiana.edu 	Request for MacScheme source for SCOOPS    
C03132 00677	∂14-Dec-87  2214	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Applicative languages?  Anyone?   
C03137 00678	∂14-Dec-87  2316	@MC.LCS.MIT.EDU,@RELAY.CS.NET:scheme-request@mc.lcs.mit.edu 	Re: Applicative languages?  Anyone?    
C03142 00679	∂14-Dec-87  2354	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Request for MacScheme source for SCOOPS
C03144 00680	∂15-Dec-87  1839	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Looking for C-Scheme   
C03146 00681	∂17-Dec-87  0430	@MC.LCS.MIT.EDU:bruggema@iuvax.cs.indiana.edu 	Re: SCOOPS for MacScheme    
C03148 00682	∂17-Dec-87  0642	@MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:ZZZO@DHVRRZN1.BITNET 	NOTE from ZZZO 
C03150 00683	∂17-Dec-87  0958	@MC.LCS.MIT.EDU:brando%linus@mitre-bedford.ARPA 	SCOOPS for MacScheme 
C03152 00684	∂17-Dec-87  1215	@MC.LCS.MIT.EDU:Esler.Opus@BCO-MULTICS.ARPA 	"box" data type in Chez Scheme.    
C03154 00685	∂18-Dec-87  0715	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET 	Byte code speed.   
C03157 00686	∂18-Dec-87  0830	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[ericson: MacScheme]
C03159 00687	∂18-Dec-87  1024	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET 	Speed    
C03163 00688	∂18-Dec-87  1401	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@home.csc.ti.com 	Byte code speed
C03168 00689	∂19-Dec-87  0739	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Speed
C03170 00690	∂19-Dec-87  0932	@MC.LCS.MIT.EDU:bruggema@iuvax.cs.indiana.edu 	MacScheme SCOOPS Update
C03173 00691	∂19-Dec-87  1310	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	Scheme Standard    
C03181 00692	∂19-Dec-87  1453	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Common Lisp in Scheme? 
C03184 00693	∂23-Dec-87  1553	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:U09254@UICVM.BITNET 	Scheme on CMS?   
C03186 00694	∂23-Dec-87  1554	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Quasiquotation
C03188 00695	∂23-Dec-87  1555	@MC.LCS.MIT.EDU,@RELAY.CS.NET:adams@tekchips.tek.com 	Object oriented programming in Scheme    
C03192 00696	∂23-Dec-87  1555	@MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK 	Re: Object oriented programming in Scheme    
C03199 00697	∂23-Dec-87  1555	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Scheme on CMS?
C03202 00698	∂23-Dec-87  1556	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com 	Re: Byte code speed  
C03206 00699	∂23-Dec-87  1556	@MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU 	Some Remarks on Standardization (by someone who has been there)   
C03223 00700	∂23-Dec-87  1555	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Quasiquotation 
C03225 00701	∂23-Dec-87  1555	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com 	Re: Speed (of byte code interpreters)    
C03228 00702	∂23-Dec-87  1556	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Scheme on CMS? 
C03231 00703	∂23-Dec-87  1556	@MC.LCS.MIT.EDU,@RELAY.CS.NET:feeley%iro.udem.cdn@UBC.CSNET 	Small Scheme compiler in Prolog...
C03234 00704	∂23-Dec-87  1553	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Byte code speed    
C03236 00705	∂23-Dec-87  1554	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET 	RE: Scheme on Atari ST. 
C03240 00706	∂23-Dec-87  2218	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Why are case implementations so slow? 
C03243 00707	∂24-Dec-87  0656	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	A vote against standardization    
C03246 00708	∂24-Dec-87  1105	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  Why are case implementations so slow? 
C03249 00709	∂27-Dec-87  1007	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	skim (a low fat implementation of Scheme)    
C03252 00710	∂27-Dec-87  1406	@MC.LCS.MIT.EDU:Alan@AI.AI.MIT.EDU 	A vote against standardization    
C03256 00711	∂27-Dec-87  2214	@MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU 	A vote against standardization  
C03258 00712	∂28-Dec-87  1109	@MC.LCS.MIT.EDU:KMP@Riverside.SCRC.Symbolics.COM 	My vote against standardization    
C03264 00713	∂31-Dec-87  0150	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	problem bringing up Scheme 6.1   
C03268 00714	∂31-Dec-87  1010	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Question about load.
C03272 00715	∂02-Jan-88  1250	@MC.LCS.MIT.EDU:ericson@csd16.nyu.edu 	Optimizing tail-recursive operations using jumps   
C03276 00716	∂05-Jan-88  1540	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	standardization    
C03281 00717	∂06-Jan-88  1117	@MC.LCS.MIT.EDU,@RELAY.CS.NET:camp@mips.csc.ti.com 	Scheme Standardization 
C03305 00718	∂06-Jan-88  1330	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	getting C-Scheme running on Sun-3 / want Scoops info 
C03308 00719	∂06-Jan-88  1913	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	who contributes?    
C03313 00720	∂07-Jan-88  0508	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:MDEBAR@BNANDP11.BITNET 	Scoops ? 
C03315 00721	∂07-Jan-88  1732	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Scoops ? 
C03317 00722	∂07-Jan-88  1848	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme for the Amiga   
C03319 00723	∂08-Jan-88  1659	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Scheme for the Amiga    
C03322 00724	∂11-Jan-88  0520	@MC.LCS.MIT.EDU:AHAAS@G.BBN.COM 	leaving
C03323 00725	∂11-Jan-88  1355	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Problem with MIT-Scheme
C03328 00726	∂13-Jan-88  1724	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Request for C-Scheme info   
C03331 00727	∂13-Jan-88  1808	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme for Unix 4.3 BSD, Ultrix 2.0, or Sys V 3.0 ???
C03333 00728	∂15-Jan-88  1911	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: SYSV Scheme was Re: Request for C-Scheme info    
C03341 00729	∂20-Jan-88  0207	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Problems bringing up CScheme 6.1 
C03346 00730	∂21-Jan-88  1949	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Question: Are the GABRIEL-benchmarks translated into SCHEME already?
C03349 00731	∂22-Jan-88  0903	@MC.LCS.MIT.EDU:rnoss%isis.educ.lon.ac.uk@NSS.Cs.Ucl.AC.UK  
C03351 00732	∂22-Jan-88  1116	@MC.LCS.MIT.EDU,@RELAY.CS.NET:tjfs@HPLB.CSNET 	Problems bringing up CScheme 6.1 
C03357 00733	∂22-Jan-88  1428	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc@tekchips.tek.com 	Re: Are the GABRIEL-benchmarks translated into SCHEME already?    
C03360 00734	∂23-Jan-88  0008	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	suggestions for the next revision of scheme
C03363 00735	∂23-Jan-88  1209	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Next R*RS meeting...   
C03365 00736	∂25-Jan-88  0040	@MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@BRANDEIS.CSNET 	Next R*RS meeting... 
C03367 00737	∂27-Jan-88  0648	@MC.LCS.MIT.EDU:philbin-jim@YALE.ARPA 	T a dialect of Scheme
C03373 00738	∂27-Jan-88  0912	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET 	Cleanup needed.    
C03376 00739	∂27-Jan-88  1933	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Parallel Versions of Scheme 
C03378 00740	∂28-Jan-88  0842	@MC.LCS.MIT.EDU:allen@lisperanto.bbn.com 	Parallel Versions of Scheme 
C03380 00741	∂28-Jan-88  0951	@MC.LCS.MIT.EDU:SGR@STONY-BROOK.SCRC.Symbolics.COM 	Parallel Versions of Scheme 
C03384 00742	∂28-Jan-88  1633	@MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM 	Some RRRS comments/corrections
C03386 00743	∂29-Jan-88  1423	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme for Amiga? 
C03388 00744	∂30-Jan-88  0554	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	testing, please ignore    
C03389 00745	∂30-Jan-88  0652	@MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU 	"Well, Stanley,here's another nice mess you've gotten us into."    
C03393 00746	∂30-Jan-88  1239	@MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU 	forwarded message from Dick Gabriel  
C03399 00747	∂30-Jan-88  1252	@MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU 	questions about X3 and Scheme   
C03401 00748	∂30-Jan-88  1447	@MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU 	Clarifications  
C03411 00749	∂30-Jan-88  1517	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	ISO vs. ANSII vs. IEEE vs. X3 vs. The Sons of Hercules  
C03413 00750	∂30-Jan-88  1739	RPG 	ISO vs. ANSII vs. IEEE vs. X3 vs. The Sons of Hercules 
C03415 00751	∂30-Jan-88  1740	@MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU 	Bizarre Story   
C03418 00752	∂01-Feb-88  1550	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	test message   
C03419 00753	∂01-Feb-88  1753	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com 	re: Next R*RS metting... 
C03422 00754	∂02-Feb-88  1809	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com 	Re: ISO vs ANSI vs IEEE vs X3 vs The Sons of Hercules    
C03434 00755	∂02-Feb-88  2101	@MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU 	Scheme Standardization    
C03438 00756	∂03-Feb-88  0445	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	[jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK: Scheme standardization] 
C03443 00757	∂03-Feb-88  0556	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	"Well, Stanley,here's another nice mess you've gotten us into." 
C03445 00758	∂03-Feb-88  0626	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Bizarre Story      
C03448 00759	∂03-Feb-88  1238	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	[camp@mips.csc.ti.com: [RPG@SAIL.Stanford.EDU: Proposal to Handle All Possible Decisions on Scheme Standardization     
C03460 00760	∂03-Feb-88  1537	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com 	Scheme Standardization   
C03466 00761	∂03-Feb-88  2039	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Scheme Standardization
C03468 00762	∂04-Feb-88  0649	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	I modify my vote on Scheme standardization  
C03470 00763	∂04-Feb-88  0736	@MC.LCS.MIT.EDU:gls@Think.COM 	Scheme Standardization  
C03473 00764	∂04-Feb-88  1220	@MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU 	Standardization 
C03476 00765	∂04-Feb-88  1310	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Little Lisper
C03479 00766	∂04-Feb-88  1443	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	more from Clyde Camp    
C03481 00767	∂04-Feb-88  1449	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	from Clyde Camp    
C03489 00768	∂04-Feb-88  1709	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com 	Standardization
C03496 00769	∂05-Feb-88  0053	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Scheme for the Amiga, size constraints 
C03499 00770	∂05-Feb-88  0743	@MC.LCS.MIT.EDU:gjc%bucsf.bu.edu@bu-it.BU.EDU 	different lisp implementations confused.   
C03502 00771	∂05-Feb-88  1249	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	from Clyde Camp    
C03507 00772	∂05-Feb-88  1503	@MC.LCS.MIT.EDU,@RELAY.CS.NET:wand@corwin.ccs.northeastern.edu 	Standardization 
C03513 00773	∂05-Feb-88  1612	@MC.LCS.MIT.EDU:gls@Think.COM 	Standardization    
C03519 00774	∂05-Feb-88  1621	@MC.LCS.MIT.EDU,@RELAY.CS.NET:adams%tekchips.CRL@tektronix.tek.com 	Standardization  
C03527 00775	∂05-Feb-88  1912	@MC.LCS.MIT.EDU,@RELAY.CS.NET:camp@mips.csc.ti.com 	Critical summary  
C03530 00776	∂06-Feb-88  1715	@MC.LCS.MIT.EDU:HAL@AI.AI.MIT.EDU 	Can we standardize Scheme without killing it?
C03544 00777	∂06-Feb-88  1957	@MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU 	Re: Standardization
C03552 00778	∂06-Feb-88  2255	@MC.LCS.MIT.EDU:gls@Think.COM 	Can we standardize Scheme without killing it?    
C03557 00779	∂07-Feb-88  0849	@MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU 	can we properly standardize a philosophy? 
C03562 00780	∂07-Feb-88  0940	@MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu 	Minimal Standard    
C03564 00781	∂07-Feb-88  0951	@MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu 	A vote for a minimal standard 
C03566 00782	∂07-Feb-88  1554	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Yale T (compiling)
C03569 00783	∂07-Feb-88  1839	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Standardization  
C03571 00784	∂07-Feb-88  1855	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Can we standardize Scheme without killing it?  
C03573 00785	∂08-Feb-88  0637	@MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM 	Scheme number notation   
C03575 00786	∂08-Feb-88  0649	@MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM 	Wording to fix for LETREC
C03577 00787	∂08-Feb-88  1449	@MC.LCS.MIT.EDU:Alan@AI.AI.MIT.EDU@AI.AI.MIT.EDU 	!    
C03579 00788	∂08-Feb-88  1552	@MC.LCS.MIT.EDU:DEATH@XX.LCS.MIT.EDU 	Scheme number notation
C03583 00789	∂08-Feb-88  1619	@MC.LCS.MIT.EDU,@RELAY.CS.NET:oxley@home.csc.ti.com 	A Minimalist Standard 
C03587 00790	∂08-Feb-88  1652	@MC.LCS.MIT.EDU:DEATH@XX.LCS.MIT.EDU 	Scheme number notation
C03589 00791	∂08-Feb-88  1659	@MC.LCS.MIT.EDU,@RELAY.CS.NET:oxley@home.csc.ti.com 	Scheme Standardization
C03594 00792	∂08-Feb-88  1840	@MC.LCS.MIT.EDU:Alan@AI.AI.MIT.EDU@AI.AI.MIT.EDU 	!    
C03596 00793	∂08-Feb-88  2203	@MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU 	!   
C03599 00794	∂08-Feb-88  2250	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com 	Can we standardize Scheme without killing it?
C03602 00795	∂09-Feb-88  0715	@MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%mephi@BRANDEIS.CSNET 	Can we standardize Scheme without killing it?
C03606 00796	∂09-Feb-88  1831	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@mips.csc.ti.com 	A Minimalist Standard    
C03611 00797	∂10-Feb-88  0125	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Standardization (meetings and relation to CL)    
C03618 00798	∂10-Feb-88  0641	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Standardization (A conservative approach)   
C03621 00799	∂10-Feb-88  0734	@MC.LCS.MIT.EDU,@RELAY.CS.NET:oxley@home.csc.ti.com 	A Minimalist Standard 
C03624 00800	∂11-Feb-88  0758	@MC.LCS.MIT.EDU:hal@ZOHAR.AI.MIT.EDU 	call for standardization meeting
C03628 00801	∂11-Feb-88  1020	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	call for standardization meeting  
C03630 00802	∂11-Feb-88  1101	@MC.LCS.MIT.EDU:philbin-jim@YALE.ARPA 	Meeting    
C03632 00803	∂11-Feb-88  1543	@MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu 	meeting   
C03633 00804	∂11-Feb-88  1558	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	is make-environment really necessary for packages?   
C03637 00805	∂11-Feb-88  1631	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	is make-environment really necessary for packages?   
C03641 00806	∂11-Feb-88  1948	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Yale T (compiling) 
C03644 00807	∂12-Feb-88  0357	@MC.LCS.MIT.EDU:HAL@AI.AI.MIT.EDU 	KMP's reply to standardizaiotn meeting note  
C03646 00808	∂12-Feb-88  1508	@MC.LCS.MIT.EDU,@RELAY.CS.NET:adams%tekchips.CRL@tektronix.tek.com 	Re: call for standardization meeting 
C03648 00809	∂15-Feb-88  0756	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	[hudak-paul@YALE.ARPA: Re: call for standardization meeting] 
C03654 00810	∂15-Feb-88  1012	NET-ORIGIN@MC.LCS.MIT.EDU 	Re:  call for standardization    
C03656 00811	∂15-Feb-88  1725	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@home.csc.ti.com 	(rationalize x y)   
C03661 00812	∂15-Feb-88  2019	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Scheme for the Amiga, size constraints 
C03666 00813	∂15-Feb-88  2156	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com 	Gabriel benchmarks in Scheme    
C03670 00814	∂16-Feb-88  0252	@MC.LCS.MIT.EDU:iuvax!dyb@ee.ecn.purdue.edu 	Re:  call for standardization meeting   
C03672 00815	∂16-Feb-88  1242	@MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU 	(rationalize x y)  
C03682 00816	∂16-Feb-88  1440	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	DO in Scheme
C03686 00817	∂16-Feb-88  1721	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	Standardization meeting on March 26 
C03688 00818	∂16-Feb-88  1756	@MC.LCS.MIT.EDU:HAL@AI.AI.MIT.EDU 	standardization meeting March 26   
C03690 00819	∂16-Feb-88  1839	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: DO in Scheme   
C03692 00820	∂16-Feb-88  1910	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Standardization meeting on March 26  
C03694 00821	∂16-Feb-88  1923	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	DO in Scheme   
C03696 00822	∂17-Feb-88  0606	@MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU 	Standardization meeting on March 26   
C03699 00823	∂17-Feb-88  0904	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	Named-let   
C03700 00824	∂17-Feb-88  1031	@MC.LCS.MIT.EDU,@RELAY.CS.NET:brooks@mips.csc.ti.com 	standardization meeting March 26    
C03702 00825	∂17-Feb-88  1044	@MC.LCS.MIT.EDU,@RELAY.CS.NET:bartley@home.csc.ti.com 	standardization meeting March 26   
C03704 00826	∂17-Feb-88  1103	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	standardization meeting March 26   
C03706 00827	∂17-Feb-88  1806	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  standardization meeting March 26 
C03708 00828	∂18-Feb-88  0025	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme for a 3B15/3B2  
C03710 00829	∂18-Feb-88  0057	@MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%mephi@BRANDEIS.CSNET 	Standardization meeting on March 26
C03712 00830	∂18-Feb-88  0119	@MC.LCS.MIT.EDU,@RELAY.CS.NET:adams%tekchips.CRL@tektronix.tek.com 	standardization meeting March 26
C03715 00831	∂18-Feb-88  0742	@MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu 	standardization meeting March 26   
C03717 00832	∂18-Feb-88  0756	@MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu 	standardization meeting    
C03719 00833	∂18-Feb-88  1055	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	Scheme standardization meeting vote    
C03721 00834	∂18-Feb-88  1207	@MC.LCS.MIT.EDU:Fischer.pa@Xerox.COM 	Common Lisp functions for Scheme?    
C03723 00835	∂19-Feb-88  0416	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Standardization meeting on March 26 and teleconferencing   
C03725 00836	∂19-Feb-88  1431	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Common Lisp functions for Scheme? 
C03728 00837	∂20-Feb-88  0053	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Lisp Innards Wanted!   
C03734 00838	∂21-Feb-88  1021	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	standardization meeting -- vote early, vote often  
C03736 00839	∂21-Feb-88  1124	@MC.LCS.MIT.EDU:rabin.pa@Xerox.COM 	Re: Lisp Innards Wanted!
C03738 00840	∂22-Feb-88  1008	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	nonorthogonality among list/vector/string procedures   
C03740 00841	∂22-Feb-88  1756	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme for Amiga  
C03743 00842	∂23-Feb-88  0726	@MC.LCS.MIT.EDU:bsg@STONY-BROOK.SCRC.Symbolics.COM 	Lisp representation data.   
C03746 00843	∂23-Feb-88  0803	@MC.LCS.MIT.EDU:bsg@STONY-BROOK.SCRC.Symbolics.COM 	As I was saying (superseding letter)  
C03749 00844	∂23-Feb-88  1115	@MC.LCS.MIT.EDU:iuvax!chaynes@ee.ecn.purdue.edu 	comments on recent remarks     
C03757 00845	∂23-Feb-88  1142	@MC.LCS.MIT.EDU:iuvax!chaynes@ee.ecn.purdue.edu 	standardization mtg agenda     
C03763 00846	∂23-Feb-88  1233	@MC.LCS.MIT.EDU:iuvax!duba@ee.ecn.purdue.edu 	standardization meeting 
C03764 00847	∂23-Feb-88  1837	@MC.LCS.MIT.EDU,@RELAY.CS.NET:manis%instr.camosun.bcc.cdn@ean.ubc.ca 	Scheme as an introductory programming language    
C03768 00848	∂24-Feb-88  1722	@MC.LCS.MIT.EDU,@RELAY.CS.NET:oxley@home.csc.ti.com 	Standardization Mtg   
C03771 00849	∂25-Feb-88  0940	@MC.LCS.MIT.EDU:kempf@Sun.COM 	New Address   
C03773 00850	∂25-Feb-88  1140	@MC.LCS.MIT.EDU:HAILPERIN@Sushi.Stanford.EDU 	SICP query lang. compiler    
C03775 00851	∂25-Feb-88  1244	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	New Address    
C03777 00852	∂25-Feb-88  1710	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Lisp Innards Wanted!    
C03779 00853	∂25-Feb-88  2323	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme book request    
C03782 00854	∂26-Feb-88  0002	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Info needed on scheme research    
C03788 00855	∂26-Feb-88  0137	@MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU 	Scheme for a 3B15/3B2 
C03791 00856	∂26-Feb-88  0938	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: !   
C03794 00857	∂26-Feb-88  1944	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	standardization meeting, March 26   
C03796 00858	∂26-Feb-88  2248	@MC.LCS.MIT.EDU:mcvax!crcge3.cge.fr!adams@uunet.UU.NET 	SICP query lang. compiler    
C03798 00859	∂27-Feb-88  0710	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	SCOOPS  
C03800 00860	∂27-Feb-88  1707	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	xscheme 
C03802 00861	∂28-Feb-88  0857	@MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%mephi@BRANDEIS.CSNET 	Standards 
C03806 00862	∂28-Feb-88  1211	@MC.LCS.MIT.EDU:mhs@HT.AI.MIT.EDU 	Info needed on Scheme research
C03808 00863	∂28-Feb-88  1857	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	standardization meeting---travel and local arrangements   
C03813 00864	∂28-Feb-88  2236	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	looking for Cscheme on 3b1  
C03815 00865	∂29-Feb-88  2146	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	CScheme5.0 Availability (Was: Scheme for Amiga) 
C03818 00866	∂01-Mar-88  0056	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	does c scheme support X windows? 
C03820 00867	∂03-Mar-88  1009	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	xscheme
C03822 00868	∂05-Mar-88  0717	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	moderator    
C03824 00869	∂06-Mar-88  0647	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: SCOOPS   
C03826 00870	∂07-Mar-88  1603	@MC.LCS.MIT.EDU,@RELAY.CS.NET:manis%instr.camosun.bcc.cdn@ean.ubc.ca 	Scheme as an introductory programming language    
C03852 00871	∂07-Mar-88  2003	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Eugene Kohlbecker's net address    
C03854 00872	∂08-Mar-88  1605	@MC.LCS.MIT.EDU:mcvax!cwi.nl!uucp@uunet.UU.NET 	standardization meeting    
C03856 00873	∂08-Mar-88  1624	@MC.LCS.MIT.EDU:mcvax!cwi.nl!uucp@uunet.UU.NET 	next report on Scheme 
C03860 00874	∂10-Mar-88  0550	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	search for IBM-PC (compatible) scheme 
C03863 00875	∂10-Mar-88  1722	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com 	false  
C03874 00876	∂10-Mar-88  1747	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: false
C03877 00877	∂11-Mar-88  0910	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	false
C03882 00878	∂11-Mar-88  0953	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	(SYMBOL? #t) ==> ?  
C03888 00879	∂11-Mar-88  1014	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[cmb%DERRZE0.BITNET: Clyde Camp's PC Scheme utilities?]
C03891 00880	∂11-Mar-88  1053	@MC.LCS.MIT.EDU:ALAN@AI.AI.MIT.EDU 	false    
C03893 00881	∂11-Mar-88  1132	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	Re: false   
C03895 00882	∂11-Mar-88  1203	@MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU 	next report on Scheme 
C03903 00883	∂11-Mar-88  1326	@MC.LCS.MIT.EDU:andy%hobbes@ads.com 	Re:  (SYMBOL? #t) ==> ?
C03908 00884	∂11-Mar-88  1543	@MC.LCS.MIT.EDU,@RELAY.CS.NET:manis%instr.camosun.bcc.cdn@ean.ubc.ca 	Paging Simon Kaplan <kaplan@kaplan.cs.uiuc.edu>   
C03910 00885	∂11-Mar-88  1855	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	(SYMBOL? #t) ==> ?  
C03914 00886	∂11-Mar-88  1920	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: (SYMBOL? #t) ==> ?  
C03918 00887	∂11-Mar-88  1943	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	(SYMBOL? #t) ==> ?  
C03920 00888	∂11-Mar-88  2006	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: (SYMBOL? #t) ==> ?  
C03926 00889	∂11-Mar-88  2208	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re: (SYMBOL? #t) ==> ? 
C03931 00890	∂11-Mar-88  2218	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  false   
C03934 00891	∂12-Mar-88  0942	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme on IBM PC  
C03936 00892	∂12-Mar-88  1123	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	travel plans 
C03939 00893	∂12-Mar-88  1459	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme and C 
C03941 00894	∂14-Mar-88  0529	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Scheme and C  
C03943 00895	∂14-Mar-88  1001	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	Types in Scheme  
C03946 00896	∂14-Mar-88  1037	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	false  
C03948 00897	∂14-Mar-88  1055	@MC.LCS.MIT.EDU:daniel@mojave.stanford.edu 	Types in Scheme 
C03951 00898	∂14-Mar-88  1917	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Types in Scheme
C03956 00899	∂16-Mar-88  1201	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com 	Re: false, (symbol #t), etc
C03964 00900	∂16-Mar-88  1201	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	t and nil 
C03967 00901	∂16-Mar-88  1201	@MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU 	Types in Scheme  
C03970 00902	∂16-Mar-88  1230	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	t and nil
C03973 00903	∂17-Mar-88  2338	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	ML 
C03975 00904	∂18-Mar-88  0525	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	standardization meeting   
C03977 00905	∂18-Mar-88  0717	@MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU 	ML    
C03979 00906	∂18-Mar-88  0930	@MC.LCS.MIT.EDU:dbm%research@att.arpa 	ML compiler -- Standard ML of NJ    
C03982 00907	∂19-Mar-88  1104	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme for the PC 
C03984 00908	∂20-Mar-88  0847	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Scheme for the PC
C03986 00909	∂20-Mar-88  1224	@MC.LCS.MIT.EDU:dybvig@silver.bacs.indiana.edu 	meeting
C03988 00910	∂21-Mar-88  0956	@MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU 	Meeting    
C03992 00911	∂21-Mar-88  1503	NET-ORIGIN@MC.LCS.MIT.EDU 	Read Macros's in Scheme ?   
C03994 00912	∂22-Mar-88  0647	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[OMAHONY: Clyde Camp's Utilities]  
C03996 00913	∂22-Mar-88  0722	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	editing   
C03998 00914	∂22-Mar-88  1235	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: xscheme  
C04000 00915	∂23-Mar-88  1510	NET-ORIGIN@MC.LCS.MIT.EDU 	How can you do things like ?X -> (*var* x) without Read Macros ?    
C04003 00916	∂24-Mar-88  0933	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[camp: [OMAHONY: Clyde Camp's Utilities]]    
C04007 00917	∂24-Mar-88  1009	@MC.LCS.MIT.EDU,@dewey.udel.edu,@localhost:saunders@UDEL.EDU 	Re: Scheme as an introductory programming language   
C04010 00918	∂24-Mar-88  1213	@MC.LCS.MIT.EDU:bh@ernie.Berkeley.EDU 	How many Schemes can your Vax take? 
C04013 00919	∂24-Mar-88  1420	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: How can you do things like ?X -> (*var* x) without Read Macros ? 
C04015 00920	∂24-Mar-88  1616	@MC.LCS.MIT.EDU:gjc%bucsf.bu.edu@buita.BU.EDU 	How can you do things like ?X -> (*var* x) without Read Macros ?    
C04019 00921	∂26-Mar-88  1627	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Saving a continuation  
C04021 00922	∂26-Mar-88  1700	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	MIT C-Scheme design info    
C04024 00923	∂27-Mar-88  1046	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: T operations, etc  
C04028 00924	∂27-Mar-88  1202	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Where can I get Scheme?
C04030 00925	∂27-Mar-88  1421	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	T operations, etc 
C04035 00926	∂28-Mar-88  0728	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	T discussion and newsgroups   
C04039 00927	∂28-Mar-88  1117	@MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU 	CLOS Error Terminology    
C04048 00928	∂28-Mar-88  1240	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	More for R4RS 
C04051 00929	∂30-Mar-88  1005	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: MIT C Scheme design info
C04064 00930	∂31-Mar-88  0022	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	availability of Scheme on Atari STs   
C04066 00931	∂31-Mar-88  0619	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:MIKEMAC@UNB.BITNET 	Porting Scheme to our IBM3090 running MVS/XA    
C04069 00932	∂03-Apr-88  2327	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: MIT C Scheme design info
C04083 00933	∂05-Apr-88  1304	@MC.LCS.MIT.EDU:SCHREQ@AI.AI.MIT.EDU 	test message, ignore  
C04085 00934	∂05-Apr-88  1908	@MC.LCS.MIT.EDU:uunet!utai!calgary!vaxb!jameson@rutgers.edu 
C04087 00935	∂05-Apr-88  1937	@MC.LCS.MIT.EDU:uunet!utai!calgary!vaxb!jameson@rutgers.edu 
C04089 00936	∂06-Apr-88  1652	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	forwarded message from Clyde Camp   
C04094 00937	∂08-Apr-88  1544	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	Scheme standarization   
C04099 00938	∂09-Apr-88  0911	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	emacs/scheme 
C04102 00939	∂10-Apr-88  2052	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme Bibliography database (BIB/REFER format) 
C04125 00940	∂18-Apr-88  0629	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	SchemeTeX---Simple support for literate programming in Lisp.    
C04128 00941	∂19-Apr-88  0021	@MC.LCS.MIT.EDU:gleicher@cs.duke.edu 	Scheme Implementation for Macintosh 2
C04130 00942	∂19-Apr-88  0905	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	Scheme Implementation for Macintosh 2
C04132 00943	∂20-Apr-88  0129	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET 	Scheme on SysVr2   
C04135 00944	∂20-Apr-88  0932	@MC.LCS.MIT.EDU:mimsy!cvl!dolqci!irs3!spl1!richp1!richsun!craig@rutgers.edu 	Scheme Implementation for Macintosh 2 
C04138 00945	∂20-Apr-88  1149	@MC.LCS.MIT.EDU:eric%s3landrew@scubed.ARPA 	Read Macros in PC-Scheme??
C04140 00946	∂20-Apr-88  1234	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Is there a new version of T ?    
C04142 00947	∂20-Apr-88  2027	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	On Beyond Abelson & Sussman 
C04145 00948	∂20-Apr-88  2335	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Lisp according to one Pascal programmer
C04150 00949	∂21-Apr-88  0010	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Scheme Implementation for Macintosh 2  
C04154 00950	∂21-Apr-88  1030	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	C Scheme Documentation 
C04158 00951	∂21-Apr-88  1121	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Engines/SCOOPS in T?   
C04161 00952	∂21-Apr-88  1448	@MC.LCS.MIT.EDU:gls@Think.COM 	Scheme Implementation for Macintosh 2  
C04164 00953	∂21-Apr-88  1548	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Scheme Implementation for Macintosh 2  
C04167 00954	∂21-Apr-88  2032	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Where to mail bugs?    
C04169 00955	∂21-Apr-88  2339	@MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU 	Where to mail bugs?   
C04171 00956	∂22-Apr-88  2216	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Followup to Stoy's book?    
C04174 00957	∂22-Apr-88  2249	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Scheme Implementation for Macintosh 2  
C04178 00958	∂23-Apr-88  2239	@MC.LCS.MIT.EDU:gjc%bucsf.bu.edu@bu-it.BU.EDU 	small scheme implementation.
C04182 00959	∂24-Apr-88  1313	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	collect macro
C04184 00960	∂25-Apr-88  1933	@MC.LCS.MIT.EDU:gjc@bu-it.BU.EDU 	SIOD release 1.1
C04187 00961	∂26-Apr-88  0510	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET 	SIOD 1.1 
C04189 00962	∂26-Apr-88  1435	SCHREQ@MC.LCS.MIT.EDU 	Cross mailing between UseNet and the ArpaNet   
C04191 00963	∂26-Apr-88  1525	 	``Update functions'' in Scheme.  
C04196 00964	∂27-Apr-88  1109	 	``Update functions'' in Scheme.  
C04201 00965	∂27-Apr-88  1607	@MC.LCS.MIT.EDU:jrm@GENEVA.AI.MIT.EDU 	SIOD release 1.1
C04202 00966	∂27-Apr-88  1923	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	R3RS number syntax 
C04206 00967	∂27-Apr-88  1952	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Proposals for R4RS 
C04209 00968	∂27-Apr-88  2212	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Scheme Implementation for Macintosh 2  
C04212 00969	∂28-Apr-88  0247	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Where to mail bugs?
C04215 00970	∂28-Apr-88  0844	@MC.LCS.MIT.EDU:sdawkins%hpda@hplabs.HP.COM 	delete from list    
C04217 00971	∂28-Apr-88  1957	@MC.LCS.MIT.EDU:gjc@bu-it.BU.EDU 	SIOD release 1.2 (28-APR-88).  
C04220 00972	∂29-Apr-88  1136	@MC.LCS.MIT.EDU:ALBERGA@IBM.COM 	TI-scheme on PS/2
C04222 00973	∂29-Apr-88  1733	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	Extending the address space of MIT Cscheme
C04225 00974	∂29-Apr-88  1828	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Questions on Scheme treatment of numbers   
C04229 00975	∂30-Apr-88  1352	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme Biblio.    
C04232 00976	∂01-May-88  1340	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: collect macro 
C04236 00977	∂01-May-88  1918	@MC.LCS.MIT.EDU:gjc@bu-it.BU.EDU 	siod release 1.3
C04239 00978	∂02-May-88  0302	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	SIOD release 1.1  
C04242 00979	∂02-May-88  0332	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: R3RS number syntax 
C04247 00980	∂02-May-88  1132	@MC.LCS.MIT.EDU:Fischer.pa@Xerox.COM 	Re: Extending the address space of MIT Cscheme 
C04249 00981	∂03-May-88  1121	@MC.LCS.MIT.EDU:lyn@BASEL.AI.MIT.EDU 	``Update functions'' in Scheme. 
C04252 00982	∂03-May-88  2313	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Extending the address space of MIT Cscheme  
C04255 00983	∂04-May-88  0051	@MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU 	Extending the address space of MIT Cscheme (long reply)  
C04266 00984	∂04-May-88  0808	@MC.LCS.MIT.EDU:mhwu@DUMBO.AI.MIT.EDU 	More flames about CScheme 
C04271 00985	∂04-May-88  0929	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	``Update functions'' in Scheme.  
C04275 00986	∂04-May-88  1506	@MC.LCS.MIT.EDU:shebs%defun@cs.utah.edu 	Re: Extending the address space of MIT Cscheme (long reply)
C04293 00987	∂04-May-88  1622	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: R3RS number syntax 
C04296 00988	∂04-May-88  1917	@MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU 	Extending the address space of MIT Cscheme (long reply)  
C04313 00989	∂04-May-88  2010	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Unpleasantness   
C04323 00990	∂05-May-88  0713	@MC.LCS.MIT.EDU:Stever@WAIKATO.S4CC.Symbolics.COM 	Re: Extending the address space of MIT Cscheme (long reply)
C04329 00991	∂05-May-88  0819	@MC.LCS.MIT.EDU:Stever@WAIKATO.S4CC.Symbolics.COM 	Extending the address space of MIT Cscheme (long reply)    
C04332 00992	∂05-May-88  0913	@MC.LCS.MIT.EDU:shebs%defun@cs.utah.edu 	Re: Extending the address space of MIT Cscheme (long reply)
C04338 00993	∂05-May-88  0947	@MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK 	Re: Extending the address space of MIT Cscheme    
C04341 00994	∂05-May-88  1025	@MC.LCS.MIT.EDU:gls@Think.COM 	Extending the address space of MIT Cscheme (semi-long reply)    
C04346 00995	∂05-May-88  1113	@MC.LCS.MIT.EDU:shebs%defun@cs.utah.edu 	Re: Unpleasantness 
C04350 00996	∂05-May-88  1153	@MC.LCS.MIT.EDU:gls@Think.COM 	Extending the address space of MIT Cscheme (long reply)    
C04354 00997	∂05-May-88  1406	@MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU 	[jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)]   
C04359 00998	∂05-May-88  1447	@MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU 	[jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)]   
C04368 00999	∂05-May-88  1542	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Extending the address space of MIT Cscheme  
C04371 01000	∂05-May-88  1702	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Unpleasantness
C04375 01001	∂05-May-88  1745	@MC.LCS.MIT.EDU:HAILPERIN@SUMEX-AIM.Stanford.EDU 	Thanks for CScheme I like it 
C04377 01002	∂05-May-88  2110	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Extending the address space of MIT Cscheme (semi-long reply)   
C04382 01003	∂05-May-88  2145	@MC.LCS.MIT.EDU:edsel!jonl@labrea.stanford.edu 	Extending the address space of MIT Cscheme (long reply)  
C04387 01004	∂05-May-88  2319	@MC.LCS.MIT.EDU:gjc%bucsf.BU.EDU@bu-it.BU.EDU 	Maclisp revisited.
C04391 01005	∂05-May-88  2353	@MC.LCS.MIT.EDU:gjc%bucsf.BU.EDU@bu-it.BU.EDU 	C and Cscheme.    
C04394 01006	∂06-May-88  0151	@MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK 	Re: Extending the address space of MIT Cscheme (long reply) 
C04396 01007	∂06-May-88  0249	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	set in Scheme?    
C04398 01008	∂06-May-88  0326	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: compatibility/elegance & *theory* 
C04407 01009	∂06-May-88  0455	@MC.LCS.MIT.EDU:edsel!jonl@labrea.stanford.edu 	[jinx@CHAMARTIN.AI.MIT.EDU: Extending the address space of MIT Cscheme (long reply)]   
C04412 01010	∂06-May-88  1130	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: set in Scheme? 
C04416 01011	∂06-May-88  1225	@MC.LCS.MIT.EDU:allen@LISPERANTO.BBN.COM 	Thanks for CScheme I like it    
C04420 01012	∂06-May-88  1408	@MC.LCS.MIT.EDU:fischer.pa@Xerox.COM 	Re: Declarations and speed 
C04423 01013	∂06-May-88  1521	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	set in Scheme? 
C04426 01014	∂07-May-88  0232	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re : set in Scheme
C04429 01015	∂07-May-88  1503	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re : set in Scheme
C04432 01016	∂07-May-88  1644	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: siod release 1.3   
C04435 01017	∂08-May-88  1917	@MC.LCS.MIT.EDU:cire@clash.cisco.com 	Please remove me.
C04437 01018	∂09-May-88  1317	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Re : set in Scheme 
C04439 01019	∂09-May-88  1537	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: ``Update functions'' in Scheme.   
C04444 01020	∂09-May-88  1918	@MC.LCS.MIT.EDU:lyn@BASEL.AI.MIT.EDU 	``Update functions'' in Scheme. 
C04451 01021	∂10-May-88  0109	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Re : set in Scheme 
C04455 01022	∂10-May-88  0321	@MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU 	``Update functions'' in Scheme.   
C04460 01023	∂10-May-88  0822	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: ``Update functions'' in Scheme.   
C04465 01024	∂10-May-88  0925	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: set in Scheme?
C04471 01025	∂10-May-88  1020	@MC.LCS.MIT.EDU:Stever@WAIKATO.S4CC.Symbolics.COM 	``Update functions'' in Scheme.   
C04479 01026	∂10-May-88  1111	@MC.LCS.MIT.EDU,@WAIKATO.S4CC.Symbolics.COM,@JEWEL-CAVE.S4CC.Symbolics.COM:Stever@WAIKATO.S4CC.Symbolics.COM 	``Update functions'' in Scheme.    
C04482 01027	∂10-May-88  1203	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NET@DB0TUI6.BITNET 	Re:  ``Update functions'' in Scheme.  
C04486 01028	∂10-May-88  1716	@MC.LCS.MIT.EDU:Barak.Pearlmutter@F.GP.CS.CMU.EDU 	Re: Update functions in Scheme.   
C04492 01029	∂10-May-88  1917	@MC.LCS.MIT.EDU:lyn@BASEL.AI.MIT.EDU 	``Update functions'' in Scheme. 
C04496 01030	∂10-May-88  1953	@MC.LCS.MIT.EDU:lyn@BASEL.AI.MIT.EDU 	``Update functions'' in Scheme. 
C04501 01031	∂10-May-88  2256	@MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU 	``Update functions'' in Scheme. 
C04503 01032	∂11-May-88  0506	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:IS7397@JPNSUT30.BITNET 
C04505 01033	∂11-May-88  1331	@MC.LCS.MIT.EDU:Stever@WAIKATO.S4CC.Symbolics.COM 	``Update functions'' in Scheme.   
C04509 01034	∂11-May-88  1913	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	``Update functions'' in POP2. 
C04511 01035	∂11-May-88  2010	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	cells
C04515 01036	∂11-May-88  2149	@MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU 	``Update functions'' in Scheme.   
C04519 01037	∂12-May-88  0004	@MC.LCS.MIT.EDU:Barak.Pearlmutter@F.GP.CS.CMU.EDU 	Re: cells
C04522 01038	∂12-May-88  0225	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.CRL@tektronix.tek.com 	Meeting 24 July 1988  
C04526 01039	∂12-May-88  0418	@MC.LCS.MIT.EDU:sas@alice.bbn.com 	``Update functions'' in POP2. 
C04528 01040	∂12-May-88  0721	@MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET 	Meeting 24 July 1988  
C04531 01041	∂12-May-88  0848	@MC.LCS.MIT.EDU:mac@uvacs.cs.virginia.edu 	Re: ``Update functions'' in Scheme.  
C04534 01042	∂12-May-88  1138	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	CPS    
C04536 01043	∂12-May-88  1545	@MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK 	Re:  ``Update functions'' in POP2. 
C04543 01044	∂12-May-88  1732	@MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU 	Cells 
C04547 01045	∂12-May-88  1815	@MC.LCS.MIT.EDU:aarons%cvaxa.sussex.ac.uk@NSS.Cs.Ucl.AC.UK 	updaters in POP-11/POP-2 
C04557 01046	∂12-May-88  1915	@MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU 	Cells    
C04561 01047	∂12-May-88  2106	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Updaters in Pop (reply to query) 
C04566 01048	∂13-May-88  0358	@MC.LCS.MIT.EDU:dfried@iuvax.cs.indiana.edu 	Snowbird  
C04567 01049	∂13-May-88  0732	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:EDH@HNYKUN52.BITNET 	readable code to SET recordfields    
C04571 01050	∂13-May-88  0840	@MC.LCS.MIT.EDU:gls@Think.COM 	cells    
C04575 01051	∂13-May-88  1052	@MC.LCS.MIT.EDU:gls@Think.COM 	Cells    
C04577 01052	∂13-May-88  1202	@MC.LCS.MIT.EDU:jrm@GENEVA.AI.MIT.EDU 	Cells 
C04579 01053	∂13-May-88  1418	@MC.LCS.MIT.EDU:gls@Think.COM 	Cells    
C04582 01054	∂13-May-88  1503	@MC.LCS.MIT.EDU:edsel!jlm@labrea.stanford.edu 	Cells   
C04584 01055	∂13-May-88  1617	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Change proposals    
C04587 01056	∂15-May-88  0019	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	MIT Scheme for Unix    
C04589 01057	∂15-May-88  1750	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: MIT Scheme for Unix
C04592 01058	∂16-May-88  1258	@MC.LCS.MIT.EDU:Barak.Pearlmutter@F.GP.CS.CMU.EDU 	Re: cells
C04595 01059	∂16-May-88  1337	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Re : set in Scheme 
C04599 01060	∂16-May-88  1446	@MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU 	MIT Scheme for Unix   
C04602 01061	∂16-May-88  1446	@MC.LCS.MIT.EDU:probertson@MEAD.SCRC.Symbolics.COM 	Re: cells    
C04604 01062	∂16-May-88  1645	@MC.LCS.MIT.EDU:bard@THEORY.LCS.MIT.EDU 	Re : set in Scheme 
C04607 01063	∂17-May-88  1336	@MC.LCS.MIT.EDU:ALBERGA@IBM.COM 	Uses of SET 
C04612 01064	∂17-May-88  1336	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: MIT Scheme for Unix
C04615 01065	∂17-May-88  1542	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	Scheme standardization meeting    
C04620 01066	∂17-May-88  2034	@MC.LCS.MIT.EDU:windley@iris.ucdavis.edu 	scheme on AIX
C04622 01067	∂18-May-88  1932	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:met9i7n@bostonu.BITNET 	Boston Sigplan Seminar on Continuation Semantics 
C04630 01068	∂19-May-88  0832	@MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET 	Re: Cells   
C04632 01069	∂19-May-88  0908	@MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET 	Re: ''Update functions'' in Scheme.  
C04635 01070	∂20-May-88  0959	@MC.LCS.MIT.EDU:hes@VALLECITO.SCRC.Symbolics.COM 	Re: ''Update functions'' in Scheme.
C04638 01071	∂20-May-88  1146	@MC.LCS.MIT.EDU:gls@Think.COM 	''Update functions'' in Scheme.   
C04641 01072	∂20-May-88  1224	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	A Proposal for Environments in Scheme  
C04671 01073	∂20-May-88  1305	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:WROGERS@UDCVAX.BITNET 	Sources to C-Scheme 
C04673 01074	∂23-May-88  0824	@MC.LCS.MIT.EDU:bartley@mips.csc.ti.com 	A Proposal for Environments in Scheme  
C04678 01075	∂23-May-88  1101	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	first class variables. 
C04682 01076	∂23-May-88  1147	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: A Proposal for Environments in Scheme   
C04688 01077	∂23-May-88  1210	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: A Proposal for Environments in Scheme   
C04713 01078	∂23-May-88  1315	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	A Proposal for Environments in Scheme   
C04716 01079	∂23-May-88  1323	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[Pavel.pa: A Proposal for Environments in Scheme] 
C04746 01080	∂23-May-88  1349	@MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU 	A Proposal for Environments in Scheme   
C04748 01081	∂23-May-88  1404	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: A Proposal for Environments in Scheme   
C04752 01082	∂23-May-88  1421	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: A Proposal for Environments in Scheme   
C04755 01083	∂23-May-88  1508	@MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET 	Floyd-Hoare Verification Harmful??   
C04759 01084	∂23-May-88  1620	@MC.LCS.MIT.EDU:hes@VALLECITO.SCRC.Symbolics.COM 	Floyd-Hoare Verification Harmful?? 
C04765 01085	∂23-May-88  1717	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	Re: A Proposal for Environments in Scheme 
C04771 01086	∂23-May-88  1807	@MC.LCS.MIT.EDU:gjc%bucsf.BU.EDU@bu-it.BU.EDU 	"Same Problem all these years" in Floyd-Hoare Verification
C04774 01087	∂23-May-88  1904	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: A Proposal for Environments in Scheme   
C04777 01088	∂24-May-88  0906	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	A Proposal for Environments in Scheme  
C04780 01089	∂24-May-88  1019	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	Proposed modifications to R3RS  
C04788 01090	∂25-May-88  0554	@MC.LCS.MIT.EDU:bartley@mips.csc.ti.com 	Proposed modifications to R3RS    
C04793 01091	∂25-May-88  0758	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	HELP ME!!!   
C04797 01092	∂25-May-88  0901	@MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK 	Re: Proposed modifications to R3RS 
C04800 01093	∂25-May-88  0924	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: HELP ME!!!    
C04806 01094	∂25-May-88  2134	@MC.LCS.MIT.EDU:gls@Think.COM 	[wand@corwin.ccs.northeastern.edu: ''Update functions'' in Scheme.]  
C04809 01095	∂26-May-88  0053	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NET@DB0TUI6.BITNET 	Macros lexcial scope  
C04813 01096	∂26-May-88  0207	@MC.LCS.MIT.EDU:gls@Think.COM 	Proposed modifications to R3RS    
C04816 01097	∂26-May-88  0257	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Omission in R↑3.5 LETREC description?   
C04819 01098	∂26-May-88  0307	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Proposed modifications to R3RS
C04826 01099	∂26-May-88  0930	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Macros lexcial scope   
C04829 01100	∂26-May-88  1045	@MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU 	Macros lexcial scope 
C04834 01101	∂26-May-88  1140	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	Re: Proposed modifications to RRRS   
C04838 01102	∂26-May-88  1151	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	Re: Proposed modifications to R3RS   
C04841 01103	∂26-May-88  1207	@MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU 	Proposed modifications to RRRS  
C04844 01104	∂26-May-88  1329	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	opaque type proposal
C04855 01105	∂26-May-88  2005	@MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU 	A Proposal for Environments in Scheme
C04860 01106	∂27-May-88  0025	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	modules   
C04871 01107	∂27-May-88  0529	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: HELP ME!!!    
C04873 01108	∂27-May-88  0628	@MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK 	Re: Proposed modifications to RRRS 
C04876 01109	∂27-May-88  1422	@MC.LCS.MIT.EDU:reddy%reddy.cs.uiuc.edu@a.cs.uiuc.edu 	Floyd-Hoare Verification Harmful?? 
C04881 01110	∂27-May-88  1614	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Miranda (functional programming system)    
C04884 01111	∂30-May-88  1727	@MC.LCS.MIT.EDU:amgreene@athena.MIT.EDU 	PLEASE remove me from this list   
C04886 01112	∂31-May-88  0901	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	collect special form for streams 
C04889 01113	∂31-May-88  1340	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:C24880RL@WUVMD.BITNET 	Request for information  
C04891 01114	∂31-May-88  2124	@MC.LCS.MIT.EDU:ALBERGA@IBM.COM 	Macros in lexically scoped lisps
C04896 01115	∂31-May-88  2206	@MC.LCS.MIT.EDU:howell%community-chest.mitre.org@gateway.mitre.org 	Miranda
C04898 01116	∂01-Jun-88  0016	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: collect special form for streams  
C04901 01117	∂01-Jun-88  1417	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: collect special form for streams  
C04906 01118	∂01-Jun-88  1525	@MC.LCS.MIT.EDU:MKATZ@A.ISI.EDU 	Bug in R3RS 
C04909 01119	∂01-Jun-88  1925	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: opaque type proposal
C04913 01120	∂01-Jun-88  1943	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: opaque type proposal
C04915 01121	∂02-Jun-88  1252	@MC.LCS.MIT.EDU:JRL%RTS-10.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Re: A Proposal for Environments in Scheme  
C04925 01122	∂03-Jun-88  0738	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:NETWORK@FRSAC11.BITNET 	Oaklisp  
C04927 01123	∂03-Jun-88  1114	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	opaque type proposal
C04932 01124	∂03-Jun-88  1227	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: opaque type proposal
C04937 01125	∂03-Jun-88  1650	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: collect special form for streams  
C04941 01126	∂03-Jun-88  1726	@MC.LCS.MIT.EDU:JRL%RTS-10.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU 	Re: opaque type proposal    
C04946 01127	∂03-Jun-88  1741	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: opaque type proposal
C04948 01128	∂03-Jun-88  2338	@MC.LCS.MIT.EDU:jrl@VX.LCS.MIT.EDU 	Re: Re: opaque type proposal 
C04951 01129	∂04-Jun-88  0132	@MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU 	sleazoid programming 
C04953 01130	∂04-Jun-88  0850	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	opaque type proposal
C04956 01131	∂04-Jun-88  1236	ALAN@MC.LCS.MIT.EDU 	opaque type proposal    
C04958 01132	∂06-Jun-88  1151	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: opaque type proposal
C04963 01133	∂06-Jun-88  1904	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	report sources 
C04965 01134	∂06-Jun-88  1935	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: A Proposal for Environments in Scheme   
C04975 01135	∂06-Jun-88  2011	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	On Modules in Scheme: Principles and Proposals   
C04991 01136	∂06-Jun-88  2049	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	R(3.5)RS Question  
C04993 01137	∂07-Jun-88  1433	@MC.LCS.MIT.EDU:gls@Think.COM 	Re: opaque type proposal
C04997 01138	∂07-Jun-88  2046	@MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU 	Re: opaque type proposal 
C05002 01139	∂07-Jun-88  2046	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: opaque type proposal
C05006 01140	∂08-Jun-88  1126	@MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU 	report sources   
C05008 01141	∂08-Jun-88  1519	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Call for publishable code!   
C05012 01142	∂09-Jun-88  0417	@MC.LCS.MIT.EDU:gjc@bu-it.BU.EDU 	siod-v1.3 now in comp.sources.unix  
C05015 01143	∂09-Jun-88  1443	@MC.LCS.MIT.EDU:Leo_Vetter.WBST207V@Xerox.COM 	Remove from Distribution    
C05017 01144	∂11-Jun-88  1953	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Scheme modules using HERALD, MODULE, and IMPORT. 
C05024 01145	∂13-Jun-88  0756	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	(define x)
C05026 01146	∂13-Jun-88  0945	@MC.LCS.MIT.EDU:bartley@mips.csc.ti.com 	(define x)    
C05028 01147	∂13-Jun-88  1235	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: (define x)
C05030 01148	∂13-Jun-88  1420	@MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu 	Full Specification    
C05039 01149	∂13-Jun-88  1446	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	(define x)
C05042 01150	∂13-Jun-88  1650	@MC.LCS.MIT.EDU:bartley@mips.csc.ti.com 	Full Specification 
C05046 01151	∂13-Jun-88  1946	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: Full Specification  
C05051 01152	∂14-Jun-88  0108	@MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU 	Full Specification    
C05057 01153	∂14-Jun-88  1104	@MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA 	Re: Full Specification
C05063 01154	∂14-Jun-88  1204	@MC.LCS.MIT.EDU:Stever@IVORY.S4CC.Symbolics.COM 	Online copy of the RR..R report?    
C05065 01155	∂14-Jun-88  1250	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Scheme modules using HERALD, MODULE, and IMPORT. 
C05068 01156	∂14-Jun-88  2031	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	char-ready? => read-char-ready?  
C05070 01157	∂15-Jun-88  0643	@MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU 	(define x)   
C05073 01158	∂15-Jun-88  0711	@MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU 	char-ready? => read-char-ready? 
C05075 01159	∂15-Jun-88  0755	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	seconds-after-J2000.0   
C05077 01160	∂15-Jun-88  0911	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	seconds-after-J2000.0
C05081 01161	∂15-Jun-88  1044	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	days-after-J2000.0 
C05084 01162	∂15-Jun-88  1259	@MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu 	More on Full Specification 
C05092 01163	∂15-Jun-88  1614	@MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM 	alternate track on the char-ready? issue   
C05097 01164	∂15-Jun-88  1645	@MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU 	alternate track on the char-ready? issue  
C05100 01165	∂15-Jun-88  1658	@MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU 	Re:  More on Full Specification
C05104 01166	∂15-Jun-88  1850	@MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM 	A couple more details  
C05110 01167	∂15-Jun-88  1952	@MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA 	Re:  More on Full Specification 
C05115 01168	∂15-Jun-88  2004	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	days-after-J2000.0  
C05118 01169	∂16-Jun-88  0216	@MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU 	Re:  More on Full Specification
C05122 01170	∂16-Jun-88  0653	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Dependency analysis on internal DEFINE's    
C05126 01171	∂16-Jun-88  1058	@MC.LCS.MIT.EDU:kessler%cons@cs.utah.edu 	L&FP 88 Registration Forms  
C05130 01172	∂16-Jun-88  1131	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	days-after-J2000.0 
C05133 01173	∂16-Jun-88  1316	@MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA 	Re:  More on Full Specification 
C05137 01174	∂16-Jun-88  1332	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com 	new wording for eqv?  
C05145 01175	∂16-Jun-88  1346	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com 	formal semantics of numeric constants
C05154 01176	∂16-Jun-88  1422	@MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU 	Re:  More on Full Specification
C05157 01177	∂17-Jun-88  0530	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	days-after-J2000.0 
C05160 01178	∂17-Jun-88  0811	@MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU 	parallel argument evaluation
C05164 01179	∂17-Jun-88  0833	@MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA 	Re: parallel argument evaluation
C05167 01180	∂17-Jun-88  0908	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	parallel argument evaluation  
C05170 01181	∂17-Jun-88  0946	@MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA 	Re: parallel argument evaluation
C05172 01182	∂17-Jun-88  1005	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	char-ready? => read-char-ready?    
C05174 01183	∂17-Jun-88  1017	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Online copy of the RR..R report?   
C05176 01184	∂17-Jun-88  1056	@MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU 	Re: parallel argument evaluation 
C05179 01185	∂17-Jun-88  1148	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	new wording for eqv?
C05183 01186	∂17-Jun-88  1204	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  char-ready? => read-char-ready?  
C05185 01187	∂17-Jun-88  1214	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  char-ready? => read-char-ready?  
C05188 01188	∂17-Jun-88  1314	@MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM 	new wording for eqv?   
C05195 01189	∂17-Jun-88  1350	@MC.LCS.MIT.EDU:gls@Think.COM 	days-after-J2000.0 
C05198 01190	∂17-Jun-88  1537	@MC.LCS.MIT.EDU:gls@Think.COM 	new wording for eqv?    
C05201 01191	∂17-Jun-88  1718	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com 	Re: Dependency analysis on internal DEFINE's   
C05207 01192	∂17-Jun-88  1729	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com 	Re: More on Full Specification  
C05215 01193	∂17-Jun-88  1740	@MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:willc@tekchips.crl 	Re: days-after-J2000.0    
C05217 01194	∂18-Jun-88  0057	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Parallel Lisps for Parallel Machines  
C05224 01195	∂18-Jun-88  0417	@MC.LCS.MIT.EDU:tiedeman@acf3.NYU.EDU 	Re: Dependency analysis on internal DEFINE's  
C05230 01196	∂20-Jun-88  0810	@MC.LCS.MIT.EDU:RPG@SAIL.Stanford.EDU 	Meetings   
C05231 01197	∂21-Jun-88  0943	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com 	Optionals, version 1  
C05237 01198	∂21-Jun-88  0953	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com 	Multiple values, version 1 
C05242 01199	∂21-Jun-88  1004	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com 	eqv? version 2   
C05252 01200	∂21-Jun-88  1713	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Oaklisp  
C05255 01201	∂22-Jun-88  0030	@MC.LCS.MIT.EDU:Barak.Pearlmutter@f.gp.cs.cmu.edu 	Re: Oaklisp   
C05258 01202	∂22-Jun-88  1348	@MC.LCS.MIT.EDU:bartley@mips.csc.ti.com 	More on Full Specification   
C05265 01203	∂22-Jun-88  1400	@MC.LCS.MIT.EDU:bartley@mips.csc.ti.com 	(define x)    
C05268 01204	∂22-Jun-88  1629	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com 	List of attendees (tentative)   
C05272 01205	∂22-Jun-88  1934	@MC.LCS.MIT.EDU,@HELIOS.NORTHEASTERN.EDU:wand@corwin.ccs.northeastern.edu 	new wording for eqv?
C05276 01206	∂23-Jun-88  0006	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Oaklisp  
C05279 01207	∂23-Jun-88  0853	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  (define x)   
C05281 01208	∂23-Jun-88  0934	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	(define x)
C05283 01209	∂24-Jun-88  0733	@MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu 	formal proposal: A Modified Procedural Interface    
C05302 01210	∂24-Jun-88  0745	@MC.LCS.MIT.EDU:hieb@iuvax.cs.indiana.edu 	informal proposal: A Modified Procedural Interface  
C05316 01211	∂25-Jun-88  1451	@MC.LCS.MIT.EDU,@ZERMATT.LCS.MIT.EDU:rhh@VX.LCS.MIT.EDU 	(define x)   
C05319 01212	∂25-Jun-88  1519	@MC.LCS.MIT.EDU:Barak.Pearlmutter@f.gp.cs.cmu.edu 	FTPing Oaklisp
C05322 01213	∂26-Jun-88  0233	@MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%mephi@cs.brandeis.edu 	More on Full Specification   
C05326 01214	∂27-Jun-88  0847	@MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM 	(define x)   
C05330 01215	∂29-Jun-88  0121	@MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:UHRZB001@DBIUNI11.BITNET   
C05332 01216	∂29-Jun-88  1135	@MC.LCS.MIT.EDU:Fischer.pa@Xerox.COM 	Production quality Scheme compilers  
C05334 01217	∂02-Jul-88  1304	@MC.LCS.MIT.EDU:windley@iris.ucdavis.edu 	ML info 
C05336 01218	∂03-Jul-88  1328	@MC.LCS.MIT.EDU,@RELAY.CS.NET:RKIRCHNE@carleton.edu 	Scheme for SUN 386i   
C05338 01219	∂04-Jul-88  1653	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: ML info  
C05341 01220	∂04-Jul-88  2357	@MC.LCS.MIT.EDU:goldberg@goldberg.cs.nyu.edu 	Re:  ML info  
C05343 01221	∂06-Jul-88  0938	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Miranda (correction)   
C05345 01222	∂06-Jul-88  1439	@MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:willc@tekchips.crl 	sanity check: <=, >= 
C05348 01223	∂06-Jul-88  1543	@MC.LCS.MIT.EDU:gls@Think.COM 	sanity check: <=, >=    
C05351 01224	∂07-Jul-88  1929	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	Re: Multiple values, Version 1    
C05353 01225	∂08-Jul-88  0047	@MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU 	informal proposal: A Modified Procedural Interface (LONG)
C05362 01226	∂10-Jul-88  1405	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	Re: Multiple values, Version 1    
C05364 01227	∂11-Jul-88  1011	@MC.LCS.MIT.EDU:jar@VOID.AI.MIT.EDU 	duplicated formals
C05366 01228	∂11-Jul-88  1416	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Documentation for T    
C05368 01229	∂12-Jul-88  0947	@MC.LCS.MIT.EDU:kessler%cons@cs.utah.edu 	L&FP Registration -- FINAL CALL  
C05373 01230	∂14-Jul-88  1526	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com 	agenda 
C05392 01231	∂14-Jul-88  2021	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Proposals compendium
C05394 01232	∂14-Jul-88  2043	@MC.LCS.MIT.EDU,@RELAY.CS.NET:willc%tekchips.crl@tektronix.tek.com 	time & place of R*RS authors' meeting
C05397 01233	∂15-Jul-88  0457	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Replace LETREC with "relaxed" internal DEFINES.  
C05400 01234	∂15-Jul-88  1855	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	OBJ3 Release 
C05410 01235	∂16-Jul-88  1003	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme shellscripts    
C05418 01236	∂16-Jul-88  2044	@MC.LCS.MIT.EDU:aab@CADDR.AI.MIT.EDU 	RE: agenda  
C05420 01237	∂17-Jul-88  1252	@MC.LCS.MIT.EDU:jar@VOID.AI.MIT.EDU 	agenda  
C05422 01238	∂18-Jul-88  0712	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Extended local defines. 
C05451 01239	∂18-Jul-88  1111	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Extended local defines. 
C05456 01240	∂18-Jul-88  1231	@MC.LCS.MIT.EDU:james@ZERMATT.LCS.MIT.EDU 	Re:  Scheme shellscripts   
C05460 01241	∂18-Jul-88  1757	@MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:willc@tekchips.crl 	Re: Replace LETREC with "relaxed" internal DEFINES.
C05466 01242	∂19-Jul-88  0018	@MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA    
C05469 01243	∂20-Jul-88  1120	@MC.LCS.MIT.EDU:kessler%cons@cs.utah.edu 	L&FP Transportation    
C05472 01244	∂20-Jul-88  2359	@MC.LCS.MIT.EDU,@RELAY.CS.NET:shin@carcvax.uconn  
C05475 01245	∂21-Jul-88  0442	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re:  Scheme shellscripts    
C05484 01246	∂21-Jul-88  0613	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Replace LETREC with "relaxed" internal definitions.   
C05488 01247	∂21-Jul-88  1526	@MC.LCS.MIT.EDU:HAILPERIN@SUMEX-AIM.Stanford.EDU 	rec definition 
C05491 01248	∂21-Jul-88  1705	@MC.LCS.MIT.EDU:wagle@iuvax.cs.indiana.edu 	RE:  lisp conf scheme agenda   
C05536 01249	∂22-Jul-88  0738	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Making local definitions more like top-level definitions.  
C05540 01250	∂22-Jul-88  0937	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	On Modules in Scheme: Principles and Proposals   
C05543 01251	∂24-Jul-88  1517	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Non-upward-compatibility of Chez Scheme versions
C05547 01252	∂24-Jul-88  1848	@MC.LCS.MIT.EDU:Olin.Shivers@centro.soar.cs.cmu.edu 	Non-upward-compatibility of Chez Scheme versions    
C05549 01253	∂25-Jul-88  1422	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Non-upward-compatibility of Chez Scheme versions 
C05552 01254	∂26-Jul-88  0917	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	binding and assignment 
C05559 01255	∂27-Jul-88  0035	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re:  Scheme shellscripts    
C05562 01256	∂27-Jul-88  2000	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re:  Scheme shellscripts    
C05565 01257	∂28-Jul-88  0358	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:ZTUBTFAL@DB0TUI6.BITNET 	Re: binding and assignment  
C05574 01258	∂29-Jul-88  2328	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Amiga C-Scheme?   
C05576 01259	∂31-Jul-88  0001	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Amiga C-Scheme?   
C05580 01260	∂02-Aug-88  0539	@MC.LCS.MIT.EDU:gls@Think.COM 	Continuations and multiple values 
C05588 01261	∂09-Aug-88  1520	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	"rabbit" report needed.
C05591 01262	∂10-Aug-88  0212	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme for the Mac?    
C05593 01263	∂10-Aug-88  1029	@MC.LCS.MIT.EDU:kaplan%kaplan.cs.uiuc.edu@a.cs.uiuc.edu 	Scheme for the Mac?    
C05595 01264	∂10-Aug-88  1318	@MC.LCS.MIT.EDU:maddox@renoir.Berkeley.EDU 	XSCHEME    
C05597 01265	∂12-Aug-88  0333	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: XSCHEME  
C05601 01266	∂14-Aug-88  0033	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Scheme for the Mac?
C05603 01267	∂14-Aug-88  1102	@MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:SCHREQ@MC.LCS.MIT.EDU 	Periodic noise message list policy reiterated 
C05609 01268	∂16-Aug-88  1356	@MC.LCS.MIT.EDU:kessler%cons@cs.utah.edu 	A Quick Note on the Last L&FP Conference   
C05612 01269	∂17-Aug-88  0426	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme Bibliography (Aug. 1988)  
C05679 01270	∂19-Aug-88  0335	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme biblio. (acknowledgements)
C05682 01271	∂20-Aug-88  0350	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Rabbit report. (NTIS)   
C05685 01272	∂22-Aug-88  1135	@MC.LCS.MIT.EDU:gls@Think.COM 	Scheme Bibliography (Aug. 1988)   
C05687 01273	∂22-Aug-88  1622	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Snowbird minutes?  
C05689 01274	∂22-Aug-88  2107	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Parallel Scheme(Lisp) on Sequent 
C05692 01275	∂23-Aug-88  0808	SCHREQ@MC.LCS.MIT.EDU 	info-cscheme-request  
C05694 01276	∂24-Aug-88  0731	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	named let -> ???   
C05696 01277	∂24-Aug-88  0951	@MC.LCS.MIT.EDU:gls@Think.COM 	named let -> ???   
C05698 01278	∂24-Aug-88  1416	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  named let -> ???  
C05699 01279	∂24-Aug-88  1454	@MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU 	Named LET -> RECLET   
C05701 01280	∂24-Aug-88  1612	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: named let -> ???    
C05703 01281	∂24-Aug-88  1703	@MC.LCS.MIT.EDU:markf@montreux 	Re: named let -> ???   
C05704 01282	∂24-Aug-88  1703	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: named let -> ???    
C05706 01283	∂24-Aug-88  1750	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re: named let -> ???   
C05709 01284	∂24-Aug-88  1933	@MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU 	Named LET -> RECLET   
C05711 01285	∂25-Aug-88  0817	@MC.LCS.MIT.EDU:gls@Think.COM 	named let -> ???   
C05714 01286	∂25-Aug-88  0835	@MC.LCS.MIT.EDU:bartley@mips.csc.ti.com 	named let -> ???   
C05719 01287	∂25-Aug-88  0901	@MC.LCS.MIT.EDU,@STONY-BROOK.SCRC.Symbolics.COM,@GRYPHON.SCRC.Symbolics.COM:KMP@STONY-BROOK.SCRC.Symbolics.COM 	Re: named let -> ???   
C05721 01288	∂25-Aug-88  0917	@MC.LCS.MIT.EDU:markf@montreux 	named let -> ???  
C05723 01289	∂25-Aug-88  0930	@MC.LCS.MIT.EDU:springer@iuvax.cs.indiana.edu 	named-let proposal
C05726 01290	∂25-Aug-88  0948	@MC.LCS.MIT.EDU:arthur@DUMBO.AI.MIT.EDU 	named let -> ???   
C05728 01291	∂25-Aug-88  1040	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re: named let -> ???   
C05730 01292	∂25-Aug-88  1239	@MC.LCS.MIT.EDU:arthur@DUMBO.AI.MIT.EDU 	Yet more Named Let flamage   
C05732 01293	∂25-Aug-88  1301	@MC.LCS.MIT.EDU:ziggy%RTS-8.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re: named LET -> RECLET 
C05733 01294	∂25-Aug-88  1741	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Summarizing the named-let debate  
C05737 01295	∂25-Aug-88  2350	@MC.LCS.MIT.EDU:springer@iuvax.cs.indiana.edu 	Clarification on named let  
C05742 01296	∂26-Aug-88  0623	@MC.LCS.MIT.EDU:jinx@CHAMARTIN.AI.MIT.EDU 	Clarification on named let 
C05745 01297	∂26-Aug-88  0917	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Named-let squabble: Kiss and make up!
C05748 01298	∂26-Aug-88  0943	@MC.LCS.MIT.EDU:daniel@mojave.Stanford.EDU 	Summarizing the named-let debate    
C05751 01299	∂26-Aug-88  1137	@MC.LCS.MIT.EDU:gls@Think.COM 	Clarification on named let   
C05755 01300	∂26-Aug-88  1149	@MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU 	Why named LET anyway? 
C05758 01301	∂26-Aug-88  1213	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: Clarification on named let    
C05763 01302	∂26-Aug-88  1233	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: Why named LET anyway?    
C05767 01303	∂28-Aug-88  0839	@MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@cs.brandeis.edu 	named-let proposal  
C05771 01304	∂29-Aug-88  2324	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	named let again   
C05775 01305	∂29-Aug-88  2337	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  named-let proposal
C05778 01306	∂31-Aug-88  1634	@MC.LCS.MIT.EDU:gls@Think.COM 	Scheme Bibliography (Aug. 1988)   
C05780 01307	∂31-Aug-88  1748	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Bibliography database  
C05806 01308	∂31-Aug-88  1749	@MC.LCS.MIT.EDU:carr%car@cs.utah.edu 	Gabriel benchmarks in Scheme    
C05808 01309	∂01-Sep-88  0852	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	named let -> ???   
C05811 01310	∂01-Sep-88  1146	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	named let -> ???
C05813 01311	∂01-Sep-88  1221	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	NAMED-LET sounds good to me. 
C05816 01312	∂01-Sep-88  1254	@MC.LCS.MIT.EDU:arthur@DUMBO.AI.MIT.EDU 	NAMED-LET sounds good to me, too. 
C05818 01313	∂01-Sep-88  1838	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  named let -> ???  
C05821 01314	∂02-Sep-88  1048	@MC.LCS.MIT.EDU:gls@Think.COM 	named let -> ???   
C05824 01315	∂02-Sep-88  1145	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	named let ::: call it A-LET-NAMED 
C05826 01316	∂03-Sep-88  1329	NET-ORIGIN@MC.LCS.MIT.EDU 	Scheme Bibliography (Sept. 1988) Notes, Additions.   
C05842 01317	∂04-Sep-88  1112	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	named let -> ???
C05844 01318	∂04-Sep-88  1124	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	problems with named-let   
C05847 01319	∂04-Sep-88  2249	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  problems with named-let
C05851 01320	∂04-Sep-88  2312	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Scheme standard group: anything happening ??    
C05854 01321	∂05-Sep-88  1345	@MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@cs.brandeis.edu 	problems with named-let  
C05856 01322	∂05-Sep-88  1530	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	Re: problems with named-let  
C05859 01323	∂05-Sep-88  1708	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	minutes from Utah    
C05861 01324	∂06-Sep-88  1402	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:met9i7n@buacca.BITNET 	Seminar announcement
C05870 01325	∂06-Sep-88  1937	@MC.LCS.MIT.EDU:springer@iuvax.cs.indiana.edu 	Compromise   
C05873 01326	∂07-Sep-88  0720	@MC.LCS.MIT.EDU:hal@MURREN.AI.MIT.EDU 	demur on recur  
C05877 01327	∂09-Sep-88  0204	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@cs.brandeis.edu 	Compromise    
C05880 01328	∂09-Sep-88  0204	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Intermediate Lambda Calculus --> Machine code  
C05883 01329	∂09-Sep-88  0205	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Intermediate Lambda Calculus --> Machine code   
C05886 01330	∂09-Sep-88  0352	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Intermediate Lambda Calculus --> Machine code    
C05890 01331	∂09-Sep-88  1444	@MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU 	"DEFLET"? 
C05893 01332	∂10-Sep-88  0231	@MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:adams@tekchips.crl 	re- named-let   
C05896 01333	∂11-Sep-88  1353	@MC.LCS.MIT.EDU:ziggy@VX.LCS.MIT.EDU 	Re:  "DEFLET"?   
C05898 01334	∂12-Sep-88  0523	@MC.LCS.MIT.EDU,@RELAY.CS.NET:SEB1525@draper.com 	Lambda Calculus Books    
C05900 01335	∂12-Sep-88  0744	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Lambda Calculus Books 
C05902 01336	∂12-Sep-88  0852	@MC.LCS.MIT.EDU:windley@cheetah.ucdavis.edu 	Re: Lambda Calculus Books     
C05904 01337	∂12-Sep-88  1809	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Question on Combinator Reduction 
C05907 01338	∂13-Sep-88  0215	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Proceedings on Lisp and Functional Programming  
C05910 01339	∂13-Sep-88  1332	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Lambda Calculus Books   
C05916 01340	∂13-Sep-88  1605	@MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU 	Implementation of functional languages   
C05941 01341	∂14-Sep-88  1334	@MC.LCS.MIT.EDU:wand@corwin.ccs.northeastern.edu 	"DEFLET"? 
C05945 01342	∂14-Sep-88  1516	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Implementation of functional languages 
C05949 01343	∂14-Sep-88  1800	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Lambda Calculus Books   
C05951 01344	∂14-Sep-88  1840	@MC.LCS.MIT.EDU:cph@kleph.AI.MIT.EDU 	"DEFLET"?   
C05954 01345	∂14-Sep-88  2014	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Functional Programming Implementation  
C05957 01346	∂15-Sep-88  1238	@MC.LCS.MIT.EDU:wilson@uicbert.eecs.uic.edu 	dynamic compilation for scheme, with inlining, etc?    
C05962 01347	∂15-Sep-88  1715	@MC.LCS.MIT.EDU:larus%paris.Berkeley.EDU@ginger.Berkeley.EDU 	Plea for Scheme Code   
C05965 01348	∂15-Sep-88  1902	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Plea for Scheme Code   
C05968 01349	∂16-Sep-88  0902	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  "DEFLET"?    
C05971 01350	∂16-Sep-88  1542	@MC.LCS.MIT.EDU:NIKHIL@XX.LCS.MIT.EDU 	Errata for Simon Peyton Jones' book 
C05980 01351	∂17-Sep-88  1517	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Functional Programming Implementation  
C05983 01352	∂19-Sep-88  1413	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	IEEE Scheme Standardization Meeting    
C05988 01353	∂21-Sep-88  0109	@MC.LCS.MIT.EDU:tyan@gwusun.gwu.edu 	scheme ATT 5 
C05990 01354	∂21-Sep-88  1010	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: dynamic compilation for scheme, with inlining, etc?   
C05998 01355	∂21-Sep-88  1354	@MC.LCS.MIT.EDU:wilson@uicbert.eecs.uic.edu 	request for info on scheme (or subset) for MVS (or portable)
C06001 01356	∂21-Sep-88  1433	@MC.LCS.MIT.EDU:wilson@uicbert.eecs.uic.edu 	Status of XScheme   
C06003 01357	∂22-Sep-88  0755	@MC.LCS.MIT.EDU:ACW@IVORY.S4CC.Symbolics.COM 	Re: dynamic compilation for scheme, with inlining, etc?    
C06006 01358	∂22-Sep-88  0838	@MC.LCS.MIT.EDU:ACW@IVORY.S4CC.Symbolics.COM 	Re: dynamic compilation for scheme, with inlining, etc?    
C06008 01359	∂22-Sep-88  1209	@MC.LCS.MIT.EDU:hbs@lucid.com 	dynamic compilation for scheme, with inlining, etc?   
C06011 01360	∂24-Sep-88  0353	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	space/time in byte code/native code (was dynamic compilation)  
C06015 01361	∂24-Sep-88  0622	@MC.LCS.MIT.EDU:bard@THEORY.lcs.mit.edu 	space/time in byte code/native code (was dynamic compilation)   
C06017 01362	∂01-Oct-88  1803	@MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:HANCHE@NORUNIT.BITNET 	Re: Status of XScheme   
C06020 01363	∂01-Oct-88  2153	NET-ORIGIN@MC.LCS.MIT.EDU 	Scheme for a Sun 4/280 OS 4.0    
C06023 01364	∂01-Oct-88  2319	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:mjk@jupiter.risc.com 	Plea for Scheme Code 
C06026 01365	∂02-Oct-88  0736	@MC.LCS.MIT.EDU:gjc%bucsf.BU.EDU@bu-it.bu.edu 	Plea for Scheme Code   
C06028 01366	∂02-Oct-88  1645	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	example of dynamic optimization  
C06034 01367	∂02-Oct-88  1708	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	dynamic compilation/optimization II   
C06040 01368	∂03-Oct-88  0127	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	unwind-protect    
C06042 01369	∂03-Oct-88  0230	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re : unwind-protect    
C06045 01370	∂03-Oct-88  0456	@MC.LCS.MIT.EDU,@MCC.COM,@PELE.ACA.MCC.COM:maeda@MCC.COM 	Re : unwind-protect   
C06048 01371	∂04-Oct-88  0322	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Re : unwind-protect
C06051 01372	∂04-Oct-88  1530	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	scheme-standard mailing list 
C06053 01373	∂07-Oct-88  1237	@MC.LCS.MIT.EDU:carr%car@cs.utah.edu 	self reproducing code 
C06055 01374	∂07-Oct-88  1411	@MC.LCS.MIT.EDU:stoller%morgan@cs.utah.edu 	Re: self reproducing code 
C06057 01375	∂07-Oct-88  1445	@MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU 	self reproducing code    
C06059 01376	∂07-Oct-88  1529	@MC.LCS.MIT.EDU:carr%car@cs.utah.edu 	Re: self reproducing code  
C06062 01377	∂07-Oct-88  1650	@MC.LCS.MIT.EDU,@IVORY.S4CC.Symbolics.COM:Zippy@QUABBIN.SCRC.Symbolics.COM 	self reproducing code   
C06065 01378	∂08-Oct-88  0042	NET-ORIGIN@MC.LCS.MIT.EDU 	re: Unwind-Protect and Continuations  
C06067 01379	∂08-Oct-88  0429	NET-ORIGIN@MC.LCS.MIT.EDU 	Scheme for 386/ix?
C06070 01380	∂08-Oct-88  0430	@MC.LCS.MIT.EDU:hal@murren.ai.mit.edu 	1989 Conference on Lisp and History of Lisp -- Advance Notice
C06074 01381	∂08-Oct-88  1500	@MC.LCS.MIT.EDU:mcvax!diku.dk!danvy@uunet.UU.NET 	Re: self reproducing code
C06076 01382	∂08-Oct-88  2020	@MC.LCS.MIT.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM 	Re: self reproducing code   
C06079 01383	∂09-Oct-88  0739	NET-ORIGIN@MC.LCS.MIT.EDU 	Re: Unwind-Protect and Continuations (Ref) 
C06082 01384	∂09-Oct-88  1330	@MC.LCS.MIT.EDU:cti@mimsy.umd.edu 	Scheme mailing list 
C06084 01385	∂10-Oct-88  0629	@MC.LCS.MIT.EDU:ALBERGA@IBM.COM 	Self replicating code 
C06086 01386	∂10-Oct-88  0711	@MC.LCS.MIT.EDU:cti@mimsy.umd.edu 	Scheme Mailing List 
C06088 01387	∂11-Oct-88  0425	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:STCS8004@IRUCCVAX.UCC.IE 	self-replicating code 
C06093 01388	∂11-Oct-88  0807	@MC.LCS.MIT.EDU:jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK 	Re: self reproducing code
C06095 01389	∂11-Oct-88  2055	NET-ORIGIN@MC.LCS.MIT.EDU 	Re: self reproducing code   
C06100 01390	∂11-Oct-88  2055	NET-ORIGIN@MC.LCS.MIT.EDU 	Re: Scheme mailing list
C06103 01391	∂11-Oct-88  2056	NET-ORIGIN@MC.LCS.MIT.EDU 	Re: self-replicating code   
C06107 01392	∂12-Oct-88  0224	@MC.LCS.MIT.EDU:gyro@kestrel.arpa 	self reproducing code    
C06109 01393	∂12-Oct-88  0917	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:STCS8004@IRUCCVAX.UCC.IE 	Self-reproducing code (correction)   
C06113 01394	∂12-Oct-88  1002	@MC.LCS.MIT.EDU:daniel@mojave.Stanford.EDU 	self reproducing messages.
C06115 01395	∂12-Oct-88  1042	NET-ORIGIN@MC.LCS.MIT.EDU 	Re: Self-reproduction  
C06118 01396	∂13-Oct-88  1256	@MC.LCS.MIT.EDU:carr%car@cs.utah.edu 	Re: self reproducing messages.  
C06120 01397	∂13-Oct-88  1327	@MC.LCS.MIT.EDU:hoey@aic.nrl.navy.mil 	Automatic programming
C06122 01398	∂13-Oct-88  1819	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	report on Snowbird authors' meeting
C06146 01399	∂13-Oct-88  1903	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	report on Snowbird authors' meeting
C06170 01400	∂13-Oct-88  1934	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	report on Snowbird authors' meeting
C06194 01401	∂13-Oct-88  1946	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	report on Snowbird authors' meeting
C06218 01402	∂13-Oct-88  2044	@MC.LCS.MIT.EDU:cph@kleph.ai.mit.edu 	self reproducing messages. 
C06221 01403	∂13-Oct-88  2126	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	report on Snowbird authors' meeting
C06245 01404	∂14-Oct-88  0056	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Self-reproducing code  
C06248 01405	∂14-Oct-88  0126	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Help!   
C06251 01406	∂17-Oct-88  1725	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:carr%car@cs.utah.edu 	Re: self reproducing messages. 
C06253 01407	∂17-Oct-88  1805	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:mkatz@sesame.stanford.edu 	Regularization of Procedures in Scheme   
C06265 01408	∂19-Oct-88  1407	@MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:HANCHE@NORUNIT.BITNET 	Self reference in objects    
C06268 01409	∂19-Oct-88  1516	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:STCS8004@IRUCCVAX.UCC.IE 	Unknown host
C06270 01410	∂19-Oct-88  1556	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Limitation with lambda
C06273 01411	∂19-Oct-88  1633	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Peek-char for R4RS?
C06275 01412	∂19-Oct-88  1723	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Peek-char for R4RS?
C06277 01413	∂19-Oct-88  1742	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Peek-char for R4RS?
C06279 01414	∂19-Oct-88  1805	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Peek-char for R4RS?
C06281 01415	∂19-Oct-88  1816	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Peek-char for R4RS?
C06283 01416	∂19-Oct-88  1958	NET-ORIGIN@MC.LCS.MIT.EDU 	case-lambda syntax in Chez Scheme
C06288 01417	∂19-Oct-88  2044	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Peek-char for R4RS?
C06290 01418	∂19-Oct-88  2122	@MC.LCS.MIT.EDU,@CUNYVM.CUNY.EDU:HANCHE@NORUNIT.BITNET 	Self reference in objects    
C06293 01419	∂19-Oct-88  2206	@MC.LCS.MIT.EDU,@MCC.COM,@PELE.ACA.MCC.COM:maeda@MCC.COM 	Self reference in objects (Adventure)
C06295 01420	∂19-Oct-88  2236	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Peek-char for R4RS?
C06297 01421	∂20-Oct-88  0405	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Limitation with lambda 
C06301 01422	∂20-Oct-88  1416	@MC.LCS.MIT.EDU:FWHITE@G.BBN.COM 	Re: Limitation with lambda
C06303 01423	∂20-Oct-88  1457	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Peek-char for R4RS?
C06305 01424	∂20-Oct-88  1557	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Lisp, Xlisp, Prolog and Scheme   
C06307 01425	∂20-Oct-88  1939	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Peek-char for R4RS?
C06309 01426	∂20-Oct-88  2005	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Peek-char for R4RS?
C06311 01427	∂21-Oct-88  1420	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Where/how to get Scheme for Suns?    
C06313 01428	∂21-Oct-88  1502	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	case-lambda and interpreter environments  
C06317 01429	∂21-Oct-88  1655	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Where/how to get Scheme for Suns?
C06320 01430	∂21-Oct-88  2031	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: Regularization of Procedures in Scheme 
C06323 01431	∂21-Oct-88  2043	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	Re: Regularization of Procedures in Scheme   
C06331 01432	∂21-Oct-88  2142	@MC.LCS.MIT.EDU,@RELAY.CS.NET:stumpf@cogsys.psychologie.uni-freiburg.dbp.de 	Re: self reproducing messages.   
C06334 01433	∂22-Oct-88  1219	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Limitation with lambda  
C06338 01434	∂22-Oct-88  1543	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:jar@void.ai.mit.edu 	Where/how to get Scheme for Suns?    
C06341 01435	∂22-Oct-88  1617	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	Re: Regularization of Procedures in Scheme   
C06349 01436	∂22-Oct-88  1959	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Peek-char for R4RS?
C06351 01437	∂24-Oct-88  1546	@ZERMATT.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	previously failed mail   
C06358 01438	∂25-Oct-88  0824	@MC.LCS.MIT.EDU:kranz@WHEATIES.AI.MIT.EDU 	Where/how to get Scheme for Suns?    
C06361 01439	∂25-Oct-88  0824	NET-ORIGIN@MC.LCS.MIT.EDU 	Re: Wanted:  most recent xscheme 
C06364 01440	∂25-Oct-88  0825	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:mkatz@sesame.stanford.edu 	Regularization of Procedures in Scheme   
C06368 01441	∂25-Oct-88  0846	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	null begin forms   
C06370 01442	∂25-Oct-88  1541	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:ZTUBTFAL@DB0TUI6.BITNET 	Re: self-replicating-code, self-replicating-messages 
C06375 01443	∂26-Oct-88  0440	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	-------------------------- call for votes -------------------  
C06378 01444	∂26-Oct-88  1020	@MC.LCS.MIT.EDU,@MITVMA.MIT.EDU:ZTUBTFAL@DB0TUI6.BITNET 	self-replicating-code, self-replicating-messages
C06383 01445	∂27-Oct-88  1318	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Regularization of Procedures in Scheme (pair setters) 
C06385 01446	∂27-Oct-88  1333	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Regularization of Procedures in Scheme (pair setters)
C06388 01447	∂27-Oct-88  1344	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Regularization of Procedures in Scheme (pair setters)
C06391 01448	∂27-Oct-88  1415	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: self-replicating-code, self-replicating-messages 
C06394 01449	∂27-Oct-88  1513	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	MacScheme Manual! 
C06396 01450	∂27-Oct-88  2059	@MC.LCS.MIT.EDU:jinx@altdorf.ai.mit.edu 	Regularization of Procedures in Scheme (pair setters) 
C06398 01451	∂27-Oct-88  2244	@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Regularization of Procedures in Scheme (pair setters)
C06401 01452	∂28-Oct-88  0455	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: Regularization of Procedures in Scheme (pair setters)  
C06403 01453	∂28-Oct-88  0526	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: MacScheme Manual!  
C06405 01454	∂28-Oct-88  0915	@MC.LCS.MIT.EDU:arthur@DUMBO.AI.MIT.EDU 	Regularization of Procedures in Scheme (pair setters) 
C06408 01455	∂28-Oct-88  1517	@MC.LCS.MIT.EDU:gls@Think.COM 	Regularization of Procedures in Scheme (pair setters) 
C06411 01456	∂28-Oct-88  1716	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: MacScheme Manual!  
C06413 01457	∂31-Oct-88  0946	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	debuggers for teaching 
C06416 01458	∂31-Oct-88  1812	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Internal definitions as a combination of LETREC's and LET*'s.  
C06422 01459	∂31-Oct-88  1946	@MC.LCS.MIT.EDU:scheme-request@mc.lcs.mit.edu 	Re: Internal definitions as a combination of LETREC's and LET*'s.   
C06427 01460	∂01-Nov-88  0550	@MC.LCS.MIT.EDU:ramsdell%linus@MITRE-BEDFORD.ARPA 	Regularization of Procedures in Scheme (pair setters) 
C06430 01461	∂02-Nov-88  2114	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #1   
C06432 01462	∂03-Nov-88  2157	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #2   
C06437 01463	∂04-Nov-88  2115	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #3   
C06439 01464	∂06-Nov-88  1500	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	R4RS number syntax   
C06445 01465	∂08-Nov-88  2131	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #4   
C06449 01466	∂09-Nov-88  2158	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #5   
C06453 01467	∂10-Nov-88  2152	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #6   
C06455 01468	∂12-Nov-88  0008	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #7   
C06532 01469	∂14-Nov-88  2147	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #8   
C06538 01470	∂15-Nov-88  2211	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #9   
C06561 01471	∂17-Nov-88  0200	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #10  
C06573 01472	∂17-Nov-88  2131	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #11  
C06606 01473	∂18-Nov-88  2110	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #12  
C06616 01474	∂19-Nov-88  2212	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #13  
C06628 01475	∂22-Nov-88  0200	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #14  
C06632 01476	∂22-Nov-88  2154	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #15  
C06637 01477	∂23-Nov-88  2140	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #16  
C06640 01478	∂24-Nov-88  2153	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #17  
C06647 01479	∂25-Nov-88  2137	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #18  
C06649 01480	∂29-Nov-88  2117	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #19  
C06651 01481	∂30-Nov-88  2202	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #20  
C06656 01482	∂01-Dec-88  2120	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #21  
C06659 01483	∂02-Dec-88  2119	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #22  
C06663 01484	∂03-Dec-88  2155	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #23  
C06671 01485	∂04-Dec-88  2112	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #24  
C06674 01486	∂05-Dec-88  2202	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #25  
C06677 01487	∂06-Dec-88  2339	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #26  
C06688 01488	∂07-Dec-88  2300	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #27  
C06701 01489	∂08-Dec-88  2149	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #28  
C06705 01490	∂09-Dec-88  2146	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #29  
C06713 01491	∂10-Dec-88  2140	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #30  
C06718 01492	∂12-Dec-88  2121	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #31  
C06720 01493	∂13-Dec-88  2220	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #32  
C06723 01494	∂14-Dec-88  2123	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #33  
C06736 01495	∂15-Dec-88  2143	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #34  
C06754 01496	∂16-Dec-88  2152	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #35  
C06761 01497	∂17-Dec-88  2116	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #36  
C06764 01498	∂19-Dec-88  2120	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #37  
C06767 01499	∂22-Dec-88  2142	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #38  
C06771 01500	∂24-Dec-88  2117	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #39  
C06773 01501	∂30-Dec-88  2149	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #40  
C06779 01502	∂01-Jan-89  2147	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #41  
C06784 01503	∂03-Jan-89  2110	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #42  
C06787 01504	∂04-Jan-89  2112	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #43  
C06790 01505	∂06-Jan-89  2120	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #44  
C06795 01506	∂09-Jan-89  2114	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #45  
C06797 01507	∂10-Jan-89  2115	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #46  
C06803 01508	∂11-Jan-89  2134	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #47  
C06811 01509	∂12-Jan-89  1351	@MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%bloom.la.tek.com@tektronix.tek.com 	R4RS Number Syntax 
C06814 01510	∂12-Jan-89  2117	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #48  
C06819 01511	∂13-Jan-89  2240	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #49  
C06826 01512	∂15-Jan-89  2130	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #50  
C06828 01513	∂18-Jan-89  2134	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #51  
C06830 01514	∂19-Jan-89  2215	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #52  
C06833 01515	∂20-Jan-89  2130	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #53  
C06837 01516	∂22-Jan-89  2130	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #54  
C06840 01517	∂24-Jan-89  2203	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #55  
C06849 01518	∂28-Jan-89  0240	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #56  
C06852 01519	∂30-Jan-89  2126	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #57  
C06855 01520	∂31-Jan-89  0756	@MC.LCS.MIT.EDU:jar@void.ai.mit.edu 	truth of '() 
C06857 01521	∂31-Jan-89  0950	@MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU 	truth of '()
C06862 01522	∂31-Jan-89  1202	@MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%bloom.la.tek.com@tektronix.tek.com 	Re: truth of '()   
C06865 01523	∂31-Jan-89  1234	@MC.LCS.MIT.EDU:wand@corwin.ccs.northeastern.edu 	Quoting vectors?    
C06867 01524	∂31-Jan-89  1244	@MC.LCS.MIT.EDU:cph@kleph.ai.mit.edu 	Quoting vectors? 
C06869 01525	∂31-Jan-89  1732	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Quoting vectors? 
C06871 01526	∂31-Jan-89  1748	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	comments on draft IEEE std
C06874 01527	∂31-Jan-89  1840	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	comments on draft IEEE std
C06877 01528	∂31-Jan-89  1850	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	comments on draft IEEE std
C06880 01529	∂31-Jan-89  1901	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	differences between R4RS and draft IEEE std   
C06885 01530	∂31-Jan-89  1911	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	differences between R4RS and draft IEEE std   
C06890 01531	∂31-Jan-89  1921	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	differences between R4RS and draft IEEE std   
C06895 01532	∂31-Jan-89  1931	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	comments on draft IEEE std
C06898 01533	∂31-Jan-89  1943	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	comments on draft IEEE std
C06901 01534	∂31-Jan-89  1954	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	comments on draft IEEE std
C06904 01535	∂31-Jan-89  2017	@MC.LCS.MIT.EDU:cph@murren.ai.mit.edu 	comments on draft IEEE std
C06907 01536	∂31-Jan-89  2250	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #58  
C06911 01537	∂01-Feb-89  0622	@MC.LCS.MIT.EDU:jinx@chamartin.ai.mit.edu 	Quoting vectors? 
C06913 01538	∂01-Feb-89  0907	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	Quoting vectors? 
C06915 01539	∂01-Feb-89  0920	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: Quoting vectors?    
C06917 01540	∂01-Feb-89  0932	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: truth of '()   
C06919 01541	∂01-Feb-89  0944	@MC.LCS.MIT.EDU:cph@kleph.ai.mit.edu 	Quoting vectors? 
C06922 01542	∂01-Feb-89  1018	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	Re:  Quoting vectors?
C06924 01543	∂01-Feb-89  1207	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	Re:  Quoting vectors?  
C06926 01544	∂01-Feb-89  1219	@MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU 	truth of '()
C06930 01545	∂01-Feb-89  1235	@MC.LCS.MIT.EDU:gls@Think.COM 	Quoting vectors?   
C06934 01546	∂01-Feb-89  1255	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	WITH-INPUT-FROM-PORT etc  
C06938 01547	∂01-Feb-89  1319	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	WITH-INPUT-FROM-PORT etc  
C06942 01548	∂01-Feb-89  1508	@MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:kend@bloom.la.tek.com 	Re: Quoting vectors?   
C06945 01549	∂01-Feb-89  1534	@MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU 	Re: truth of '()    
C06948 01550	∂01-Feb-89  1703	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	WITH-INPUT-FROM-PORT etc  
C06952 01551	∂01-Feb-89  1716	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	apology for flamage concerning WITH-INPUT-FROM-PORT etc 
C06955 01552	∂01-Feb-89  1923	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: Quoting vectors?    
C06957 01553	∂01-Feb-89  2015	@MC.LCS.MIT.EDU:jar@void.ai.mit.edu 	Quoting vectors?  
C06959 01554	∂01-Feb-89  2032	@MC.LCS.MIT.EDU:jar@void.ai.mit.edu 	truth of '() 
C06962 01555	∂01-Feb-89  2056	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: Quoting vectors?    
C06965 01556	∂01-Feb-89  2107	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: truth of '()   
C06968 01557	∂01-Feb-89  2125	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	apology for flamage concerning WITH-INPUT-FROM-PORT etc 
C06971 01558	∂01-Feb-89  2136	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	WITH-INPUT-FROM-PORT etc  
C06975 01559	∂01-Feb-89  2146	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	WITH-INPUT-FROM-PORT etc  
C06979 01560	∂01-Feb-89  2156	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	WITH-INPUT-FROM-PORT etc  
C06983 01561	∂01-Feb-89  2209	@MC.LCS.MIT.EDU:dyb@iuvax.cs.indiana.edu 	with-input-from-file and co.
C06986 01562	∂01-Feb-89  2230	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #59  
C06992 01563	∂02-Feb-89  1054	@MC.LCS.MIT.EDU:andy@polya.Stanford.EDU 	Quoting vectors?   
C06996 01564	∂02-Feb-89  1303	@MC.LCS.MIT.EDU,@LCS.MIT.EDU:cph@kleph.ai.mit.edu 	Quoting vectors?   
C06999 01565	∂02-Feb-89  1348	@MC.LCS.MIT.EDU,@LCS.MIT.EDU:jinx@chamartin.ai.mit.edu 	Quoting vectors?   
C07002 01566	∂02-Feb-89  1359	@MC.LCS.MIT.EDU:jinx@chamartin.ai.mit.edu 	truth of '()
C07005 01567	∂02-Feb-89  1618	@MC.LCS.MIT.EDU:jar@void.ai.mit.edu 	rrrs-authors vs. scheme-standard 
C07010 01568	∂02-Feb-89  2126	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #60  
C07016 01569	∂04-Feb-89  2122	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #61  
C07020 01570	∂07-Feb-89  1319	@MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU 	truth of '()
C07024 01571	∂07-Feb-89  2154	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #62  
C07026 01572	∂08-Feb-89  2037	@MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:kend@bloom.la.tek.com 	Portability  
C07033 01573	∂08-Feb-89  2215	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #63  
C07074 01574	∂10-Feb-89  2128	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #64  
C07077 01575	∂11-Feb-89  2134	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #65  
C07079 01576	∂13-Feb-89  2125	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #66  
C07083 01577	∂14-Feb-89  2127	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #67  
C07085 01578	∂17-Feb-89  2200	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #68  
C07102 01579	∂18-Feb-89  1808	@MC.LCS.MIT.EDU:chaynes@iuvax.cs.indiana.edu 	... should be a peculiar identifier    
C07106 01580	∂18-Feb-89  2155	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #69  
C07110 01581	∂20-Feb-89  1050	@MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%bloom.la.tek.com@tektronix.tek.com 	Re: ... should be a peculiar identifier     
C07113 01582	∂20-Feb-89  1141	@MC.LCS.MIT.EDU:gjs@ZOHAR.AI.MIT.EDU 	... should be a peculiar identifier  
C07115 01583	∂20-Feb-89  1158	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: ... should be a peculiar identifier
C07117 01584	∂20-Feb-89  1244	@MC.LCS.MIT.EDU:jar@void.ai.mit.edu 	... should be a peculiar identifier   
C07121 01585	∂20-Feb-89  1441	@MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller%coconut@cs.brandeis.edu 	... should be a peculiar identifier  
C07124 01586	∂20-Feb-89  2142	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #70  
C07126 01587	∂21-Feb-89  2130	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #71  
C07130 01588	∂23-Feb-89  2154	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #72  
C07134 01589	∂24-Feb-89  2140	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #73  
C07139 01590	∂26-Feb-89  2224	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #74  
C07149 01591	∂27-Feb-89  2132	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #75  
C07152 01592	∂01-Mar-89  2136	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #76  
C07154 01593	∂02-Mar-89  2139	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #77  
C07165 01594	∂03-Mar-89  2122	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #78  
C07168 01595	∂05-Mar-89  1344	@MC.LCS.MIT.EDU:ziggy%RTS-8.LCS.MIT.EDU@LCS.MIT.EDU 	Wired numeric predicates?  
C07171 01596	∂07-Mar-89  2138	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #79  
C07174 01597	∂08-Mar-89  2133	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #80  
C07177 01598	∂09-Mar-89  2206	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #81  
C07184 01599	∂10-Mar-89  1559	@MC.LCS.MIT.EDU:ziggy%RTS-8.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Re:  Wired numeric predicates?    
C07188 01600	∂10-Mar-89  2147	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #82  
C07191 01601	∂12-Mar-89  2138	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #83  
C07194 01602	∂13-Mar-89  2138	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #84  
C07199 01603	∂19-Mar-89  1256	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #86  
C07201 01604	∂19-Mar-89  1433	@MC.LCS.MIT.EDU,@REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU 	Weird numeric predicates?
C07205 01605	∂19-Mar-89  1822	@MC.LCS.MIT.EDU:ziggy%RTS-8.LCS.MIT.EDU@XX.LCS.MIT.EDU 	Exactness contagion and wired numeric predicates 
C07210 01606	∂19-Mar-89  1823	@MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%mrloog.la.tek.com@tektronix.tek.com 	"Its the little things that count.  Hundreds of 'em." -- Cliff Shaw 
C07241 01607	∂19-Mar-89  1823	@MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU 	Wired numeric predicates?  
C07245 01608	∂19-Mar-89  1824	@MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU 	"Its the little things that count.  Hundreds of 'em." -- Cliff Shaw
C07255 01609	∂19-Mar-89  2143	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #87  
C07258 01610	∂20-Mar-89  2135	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #88  
C07260 01611	∂21-Mar-89  0325	@MC.LCS.MIT.EDU:gyro@kestrel.arpa 	Weird numeric predicates?
C07268 01612	∂21-Mar-89  1840	@MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.la.tek.com 	Re: "Its the little things that count.  Hundreds of 'em." -- Cliff Shaw 
C07286 01613	∂21-Mar-89  1956	@MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU 	Portability (long)    
C07305 01614	∂21-Mar-89  2143	@MC.LCS.MIT.EDU,@AI.AI.MIT.EDU:Alan@AI.AI.MIT.EDU 	Weird numeric predicates?    
C07310 01615	∂21-Mar-89  2255	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #89  
C07389 01616	∂22-Mar-89  0450	@MC.LCS.MIT.EDU:gyro@kestrel.arpa 	Weird numeric predicates?
C07394 01617	∂22-Mar-89  0946	@MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU 	"Its the little things that count.  Hundreds of 'em." -- Cliff Shaw
C07405 01618	∂22-Mar-89  2136	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #90  
C07407 01619	∂22-Mar-89  2245	@MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%mrloog.la.tek.com@tektronix.tek.com 	Re: "Its the little things that count.  Hundreds of 'em." -- Cliff Shaw  
C07417 01620	∂23-Mar-89  0934	@MC.LCS.MIT.EDU:mkatz@sesame.Stanford.EDU 	"Its the little things that count.  Hundreds of 'em." -- Cliff Shaw
C07422 01621	∂23-Mar-89  1709	@MC.LCS.MIT.EDU,@AI.AI.MIT.EDU:ziggy@VX.LCS.MIT.EDU 	Re:  "Its the little things that count.  Hundreds of 'em." -- Cliff Shaw
C07425 01622	∂23-Mar-89  1715	@MC.LCS.MIT.EDU,@RELAY.CS.NET,@tektronix.tek.com:kend@mrloog.la.tek.com 	Re: Portability (long)
C07438 01623	∂23-Mar-89  1737	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: Portability (long)  
C07442 01624	∂23-Mar-89  1841	@MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU 	Portability (long)    
C07452 01625	∂23-Mar-89  2118	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #91  
C07455 01626	∂24-Mar-89  0348	@MC.LCS.MIT.EDU:gyro@kestrel.arpa 	Standardization of libraries  
C07463 01627	∂24-Mar-89  0721	@MC.LCS.MIT.EDU,@RELAY.CS.NET:jmiller@cs.brandeis.edu 	"Its the little things that count.  Hundreds of 'em." -- Cliff Shaw   
C07471 01628	∂24-Mar-89  1409	@MC.LCS.MIT.EDU,@polya.Stanford.EDU:mkatz@sesame 	Standardization of libraries  
C07481 01629	∂24-Mar-89  2123	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #92  
C07485 01630	∂25-Mar-89  0550	@MC.LCS.MIT.EDU:jh@tut.fi 	Standardization of libraries
C07487 01631	∂25-Mar-89  2128	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #93  
C07510 01632	∂26-Mar-89  1910	@MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%mrloog.la.tek.com@tektronix.tek.com 	Re: Portability (long) 
C07520 01633	∂27-Mar-89  1400	@MC.LCS.MIT.EDU:Pavel.pa@Xerox.COM 	Re: Portability (long)  
C07528 01634	∂27-Mar-89  2021	@MC.LCS.MIT.EDU,@RELAY.CS.NET:kend%mrloog.la.tek.com@tektronix.tek.com 	Re: Portability (long) ...(now short) 
C07535 01635	∂28-Mar-89  1308	@MC.LCS.MIT.EDU:ramsdell@huxley.MITRE.ORG 	copyrights  
C07537 01636	∂28-Mar-89  1541	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	transitive arithmetic comparisons   
C07541 01637	∂28-Mar-89  1559	@MC.LCS.MIT.EDU,@mist.math.uoregon.edu:will@fog.cs.uoregon.edu 	yellow pages    
C07548 01638	∂28-Mar-89  1624	@MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU 	yellow pages
C07552 01639	∂04-Apr-89  2002	@MC.LCS.MIT.EDU:ziggy@hx.lcs.mit.edu 	Consistency 
C07554 01640	∂07-Apr-89  0749	@MC.LCS.MIT.EDU:cph@kleph.ai.mit.edu 	ftp'able R3.95RS 
C07556 01641	∂07-Apr-89  0750	@MC.LCS.MIT.EDU:ziggy@hx.LCS.MIT.EDU 	R↑3.95 non-idealities (anal)    
C07558 01642	∂07-Apr-89  0754	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #95  
C07574 01643	∂07-Apr-89  2125	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #96  
C07578 01644	∂12-Apr-89  2131	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #97  
C07581 01645	∂16-Apr-89  1329	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #98  
C07591 01646	∂17-Apr-89  1605	@MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU 	Comments on the draft standard  
C07615 01647	∂17-Apr-89  2140	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #99  
C07621 01648	∂18-Apr-89  2134	@MC.LCS.MIT.EDU:shap@polya.Stanford.EDU 	Comments on the draft standard    
C07624 01649	∂18-Apr-89  2312	@MC.LCS.MIT.EDU:shap@polya.Stanford.EDU 	Comments on the draft standard    
C07631 01650	∂18-Apr-89  2312	@MC.LCS.MIT.EDU:shap@polya.Stanford.EDU 	Comments on the draft standard    
C07634 01651	∂18-Apr-89  2312	@MC.LCS.MIT.EDU:shap@polya.Stanford.EDU 	Conusion with peek-char and char-ready 
C07639 01652	∂19-Apr-89  0145	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #100 
C07652 01653	∂19-Apr-89  0711	@MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU 	Comments on the draft standard  
C07657 01654	∂19-Apr-89  0723	@MC.LCS.MIT.EDU:jinx@chamartin.AI.MIT.EDU 	Comments on the draft standard  
C07660 01655	∂19-Apr-89  0814	@MC.LCS.MIT.EDU:jar@void.ai.mit.edu 	Confusion with peek-char and char-ready    
C07664 01656	∂19-Apr-89  1247	@MC.LCS.MIT.EDU:jar@void.ai.mit.edu 	test message 
C07665 01657	∂19-Apr-89  2152	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #101 
C07677 01658	∂20-Apr-89  2205	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #102 
C07694 01659	∂22-Apr-89  1248	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #103 
C07708 01660	∂22-Apr-89  2132	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #104 
C07725 01661	∂23-Apr-89  0150	@MC.LCS.MIT.EDU:shap@polya.Stanford.EDU 	Why the interest   
C07728 01662	∂23-Apr-89  0201	@MC.LCS.MIT.EDU:shap@polya.Stanford.EDU 	Rebinding of standard functions   
C07732 01663	∂23-Apr-89  2136	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #105 
C07737 01664	∂24-Apr-89  2130	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #106 
C07745 01665	∂25-Apr-89  2156	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #107 
C07753 01666	∂29-Apr-89  2140	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #108 
C07756 01667	∂30-Apr-89  2149	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #109 
C07761 01668	∂01-May-89  2142	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #110 
C07771 01669	∂02-May-89  2207	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #111 
C07784 01670	∂03-May-89  2136	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #112 
C07802 01671	∂04-May-89  2140	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #113 
C07812 01672	∂07-May-89  2114	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #114 
C07816 01673	∂08-May-89  2129	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #115 
C07829 01674	∂09-May-89  2127	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #116 
C07833 01675	∂10-May-89  2137	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #117 
C07841 01676	∂12-May-89  2121	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #118 
C07845 01677	∂13-May-89  2115	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #119 
C07850 01678	∂14-May-89  2132	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #120 
C07853 01679	∂15-May-89  2120	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #121 
C07858 01680	∂16-May-89  2122	Scheme-REQUEST@MC.LCS.MIT.EDU 	Scheme Digest #122 
C07861 ENDMK
C⊗;
∂26-Apr-86  0738	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	The generality of define
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 Apr 86  07:38:32 PST
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 APR 86  10:38:14 EST
Date: 26 Apr 1986  10:38 EST (Sat)
Message-ID: <JINX.12201925541.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   andy@AIDS-UNIX.ARPA (Andy Cromarty)
Cc:   SCHEME@MC.LCS.MIT.EDU
Subject: The generality of define
In-reply-to: Msg of 23 Apr 1986  19:09-EST from andy at aids-unix (Andy Cromarty)

  (define square (lambda (x) (* x x)))

at all, but rather to

  (define square (rec square (lambda (x) (* x x))))

The new version of RRRS changes this.

(define (square x) (* x x))

will be equivalent to

(define square (lambda (x) (* x x)))

The self recursive form can be obtained by explicitely using LETREC or
wRECk.

∂26-Apr-86  1816	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@xx.lcs.mit.edu 	variata  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 Apr 86  18:15:50 PST
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 26 Apr 86 21:16:52 EST
Received: from 5400000012 by CSNET-RELAY.ARPA id a000769; 26 Apr 86 21:04 EST
Received: from OZ.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 26 Apr 86 10:33-EST
Date: 26 Apr 1986  10:33 EST (Sat)
Message-ID: <JINX.12201924643.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@xx.lcs.mit.edu>
To:   David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Cc:   JAR%mc.lcs.mit.edu@CSNET-RELAY.ARPA, 
      RRRS-AUTHORS%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Subject: variata
In-reply-to: Msg of 25 Apr 1986  19:04-EST from David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>


    To summarize:

     -- We agree that (ELSE) is a no-no and that (COND) and (COND (ELSE exp))
     are valid.

     -- I feel that (BEGIN) should have the same meaning as (COND), but I
    won't push the point.

I don't like this.  Unfortunately JAR did not give me choice c (status
quo, where (COND (ELSE ...)) is legal, but (COND) is not), which I
like best.  I object pretty strongly to (BEGIN) and somewhat less
strongly to (COND).  The usual rationale is that it makes macros
easier to write, but this is just laziness of the same sort as using
(cdr (assq <something> <some-list>)) in a Lisp where (cdr '()) -> '().
(COND (ELSE ...)) although silly has a clear meaning (unless the ELSE
clause is empty, which should be an error, but we agree on this).

     -- We agree on using EQV? for CASE.

I like JAR's proposal too.

     -- We agree that (EQV? "" "") and (EQV? #() #()) are true, but I worry
    about confusion when I mix Scheme and Common LISP programs.

I'm worried about gratuitous differences between EQ? and EQV?.  I
would object (although not terribly strongly) to making 
(eq? '#() '#()) be #T, but I think it is silly to have EQ? and EQV?
behave differently on this.  The reason I object to (eq? '#() '#())
being #T is that inline coding of make-vector would become more
expensive.  Make-vector is very cheap in our implementation and a good
candidate for inline coding (although we don't currently do it), and
having it intern 0 length vectors (strings) would make it more
expensive.

     -- I like warning messages for things like (MAKE-VECTOR 0 exp) more
    than you do.  We can probably agree to provide declarations so you
    won't refuse to buy my system!

I agree with JAR.  I think that (MAKE-VECTOR 0 exp) is reasonable and
no error (warning) message should be given.  I don't understand why
you object to it.  Why not warn about reversing a list with less than 2
elements also?

     -- I'm not apologetic about trying to avoid ``gratuitous''
    differences with Common LISP, but I don't want to burden the
    description of Scheme with constant references to it either.

I agree.  Unless there is strong reason to do otherwise, we should not
differ from Common Lisp.  This should probably be stated early (if we
all agree, of course), and assumed afterwards.  A reference to this
remark in various places might be appropriate.

∂27-Apr-86  1455	@MC.LCS.MIT.EDU:KMP@SCRC-STONY-BROOK.ARPA 	variata
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Apr 86  14:55:43 PDT
Received: from SCRC-STONY-BROOK.ARPA by MC.LCS.MIT.EDU 27 Apr 86 17:56:56 EDT
Received: from HUMMINGBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 473339; Sun 27-Apr-86 17:54:24-EDT
Date: Sun, 27 Apr 86 17:55 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: variata
To: JAR@MIT-MC.ARPA
cc: RRRS-AUTHORS@MIT-MC.ARPA
In-Reply-To: <[MC.LCS.MIT.EDU].895280.860425.JAR>
References: The message of 24 Apr 86 10:43-EST from Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
Message-ID: <860427175526.2.KMP@HUMMINGBIRD.SCRC.Symbolics.COM>

I am absolutely opposed to making (COND) or (COND (ELSE)) or (BEGIN) or 
(LAMBDA ()) illegal. I am content to make them return undefined values but 
I insist that, for example, (LAMBDA () (BEGIN) 3) is a completely well-formed
expression that should neither cause the compiler to say anything nor cause 
an error at runtime.

I am very opposed to requiring ELSE to be the last clause in a COND. It seems 
to me that
 (COND ((FOO)) (ELSE #T) ((BAR)))
is like like
 (OR (FOO) #T (BAR)).
I hope no one is going to insist that the previous form should also be illegal
and/or that it should be warned about by a compiler. The call to BAR is 
obviously not going to get reached for pragmatic reasons, but there may be
legitimate situations where program-writing programs could want to construct 
something like this and I think we'd be shooting ourselves in the foot to 
disallow such things. Also, I think it tends to make the grammar look more 
graceful if ELSE can occur anyway. The particular case of interest is:
  `(COND ,@FORMS (ELSE FOO))
where FORMS may be allowed to contain an ELSE clause. I object to having to
write:
  `(COND ,@FORMS ,@(IF (AND FORMS (NOT (EQ (CAR (LAST FORMS)) 'ELSE)))
		       `((ELSE FOO))
		       `()))

If you decide to make any of the above forms legal, I wish to have my 
reasons for disagreement cited.

I think CASE should be changed to use EQUAL?, which I think is in agreement
with a recent suggestion by you. This will get around a lot of confusion that
could otherwise result from the recent trend toward wanting to intern quoted
structure.

I'm fairly satisfied with the way things seem to be going in the EQ? and 
EQV? discussion so will mostly decline from any comment for now on that 
subject.

    JAR: If people believe that it's important to be able to parse Scheme's 
    read syntax using only standard Common Lisp reader features, then by all
    means we must allow (eq? '#() '#()) to be false, but we also have to
    change the syntax of numbers, and make colon not be a constituent
    character.  But Scheme's eqv? could still deal with #() and "" as I
    propose even if eq? doesn't.
    
Right.

    JAR: It looks like I'll lose on this point, so I won't push it too hard.  
    I'm    just resisting adding yet another clause which basically says "we 
    did this for compatibility with Common Lisp."

I am sympathetic to this position.

I strongly oppose requiring APPEND to do gratuitous copying. It's trivial to
adopt 

    Bartley (about APPEND): ... I'd like some discussion on this.  It sounds 
    like something a LISP programmer could trip up on, especially those 
    who use (APPEND X '()) to copy X.  Steele's book specifically mentions
    that APPEND will work that way in Common LISP, but implies that it is 
    poor style.  My inclination is to be compatible with Common LISP in 
    order to minimize frustration for the poor people we're trying to 
    win over to Scheme.

    JAR: If this is what other people want I'm happy with it too (except 
    again for the fact that I'll have to insert another apology and another 
    reference to Common Lisp).

The fact that CL provides COPY-LIST is enough for me. I am strongly opposed
to continuing this lossage of forcing APPEND to do gratuitous copying. You're
falling down on your let's-not-be-gratuitously-compatible-with-CL maxim. CL
itself is really only doing it for compatibility, too. This is a case where
we're clearly right and ought not give in.

    JAR: What about (let ((x (list 'a))) (eq? x (reverse x))) ?

    Bartley: I feel strongly that REVERSE should always copy (unless its 
    argument is the empty list), since it is easier to remember that rule 
    than that it does so only when there's more than one element in the list.
    Pragmatically, I often do something like (APPEND! (REVERSE X) Y), and
    wouldn't want to side effect the original list in X if it had exactly
    one element.  (Note that this works correctly when X is the empty
    list, so this is a pretty unusual boundary condition.)

    JAR: I agree.  (Except note that it doesn't copy empty lists....)

I am receptive to the idea of permitting the result of REVERSE to share with
its input. The idiom (APPEND! (REVERSE X) Y) should just be named. CL has 
REVAPPEND and NRECONC. I believe we should just have APPEND-REVERSE and 
APPEND-REVERSE! which do these common operations. This would reduce the need 
to rely on  copying. I think we should take a consistent stand on the idea 
that REVERSE, APPEND, do not have to copy and that that's why we provide 
COPY-LIST. People can always write their own COPY-LIST-REVERSE, 
COPY-LIST-APPEND, etc. if they really need to intertwine the two operations 
for some efficiency reason. The dumb routines are so easy to write yourself, 
after all. The ones provided by the system should be the messy-to-write 
super-optimizing ones.


∂27-Apr-86  1607	@MC.LCS.MIT.EDU:dcj%jacksun@SUN.COM 	SCOOPS, and GNU support question 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Apr 86  16:07:16 PDT
Received: from sun.com by MC.LCS.MIT.EDU 27 Apr 86 19:06:04 EDT
Received: from snail.sun.com (snail-ptp) by sun.com (3.2-/SMI-3.0)
	id AA13232; Sun, 27 Apr 86 16:01:26 PDT
Received: from jacksun.sun.uucp by snail.sun.com (3.2/SMI-3.0DEV4)
	id AA28515; Sun, 27 Apr 86 16:04:42 PDT
Received: by jacksun.sun.uucp (1.1/SMI-3.0)
	id AA11217; Sun, 27 Apr 86 16:04:02 PDT
Date: Sun, 27 Apr 86 16:04:02 PDT
From: dcj%jacksun@SUN.COM (Donald Clark Jackson)
Message-Id: <8604272304.AA11217@jacksun.sun.uucp>
To: scheme@mc.lcs.mit.edu
Subject: SCOOPS, and GNU support question


As a user of TI-SCHEME, I kind of like
the SCOOPS object-oriented package.
I have C-Scheme running on a Sun now, and
I would like to get SCOOPS running on it.

Is source for SCOOPS available, or is it
TI proprietary code?  Is there something
similar available?  

Also, while getting the "inferior scheme"
mode in GNU Emacs to work, I had to change the
following line in xscheme.el:

	(make-shell "scheme" scheme-program-name nil "-emacs")
to 
	(make-shell "scheme" scheme-program-name)

What was the "-emacs" supposed to do?
I have GNU Emacs Version 17.61, and
MIT C-Scheme Version 6.1.

If this is the wrong mailing list for these
questions, please suggest a better forum.

Mail me your replies, if possible. I'll
summarize to this list if there is any
demand.

Thanks,

Don Jackson

djackson@sun.com
{ucbvax,decwrl,...}!sun!djackson


∂28-Apr-86  1155	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: variata    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Apr 86  11:54:22 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Apr 86 14:55:35 EDT
Received: from ti-csl by csnet-relay.csnet id a002987; 28 Apr 86 14:49 EDT
Received: by tilde id AA15512; Mon, 28 Apr 86 13:40:42 cdt
Date: Mon 28 Apr 86 13:28:11-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: variata
To: JINX%OZ.AI.MIT.EDU%xx.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: JAR%mc.lcs.mit.edu@CSNET-RELAY.ARPA, 
    RRRS-AUTHORS%mc.lcs.mit.edu@CSNET-RELAY.ARPA, 
    Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <JINX.12201924643.BABYL@MIT-OZ>
Message-Id: <12202480652.63.BARTLEY@CSC60>

  >Date: 26 Apr 1986  10:33 EST (Sat)
  >From: Bill Rozas <JINX%OZ.AI.MIT.EDU%xx.lcs.mit.edu@csnet-relay>
  >
  >    [Bartley:]
  >     -- I like warning messages for things like (MAKE-VECTOR 0 exp) more
  >    than you do.  We can probably agree to provide declarations so you
  >    won't refuse to buy my system!
  >
  >I agree with JAR.  I think that (MAKE-VECTOR 0 exp) is reasonable and
  >no error (warning) message should be given.  I don't understand why
  >you object to it.  Why not warn about reversing a list with less than 2
  >elements also?

I'm not objecting, just asking questions to clarify JAR's position and
to elicit comments from others with strong opinions.  Let's see if I
can clarify both mine and yours: 

 -- I agree that (MAKE-VECTOR EXP1 EXP2) shouldn't be an error or
cause a warning at runtime should EXP1 evaluate to zero.  I'm talking
about compile-time warnings (e.g. for a COMPILE-FILE) when EXP1 is a
literal zero.  I oppose most, perhaps all, warnings during evaluation.
Sorry I wasn't more explicit -- I tend to think in terms of separate
compilation and I'm sure many of you are thinking primarily in terms
of interpretation.

 -- Likewise, (REVERSE EXP3) obviously shouldn't cause a warning when
EXP3 evaluates to a list with fewer than two elements.  But a
compile-time warning about (REVERSE '(A)) might be helpful (if it
weren't so unlikely!).

There's no real debate here.  If I were to report `warnings,' as
opposed to actual `errors,' I'd do it only in a compilation mode where
they wouldn't be confused with the runtime behavior of the program and
only if the user asked for them by setting a flag.  This is a
development environment issue, not a language issue.

>     -- We agree that (ELSE) is a no-no and that (COND) and (COND (ELSE exp))
>     are valid.
>
>     -- I feel that (BEGIN) should have the same meaning as (COND), but I
>    won't push the point.
>
>I don't like this.  Unfortunately JAR did not give me choice c (status
>quo, where (COND (ELSE ...)) is legal, but (COND) is not), which I
>like best.  I object pretty strongly to (BEGIN) and somewhat less
>strongly to (COND).  The usual rationale is that it makes macros
>easier to write, but this is just laziness of the same sort as using
>(cdr (assq <something> <some-list>)) in a Lisp where (cdr '()) -> '().
>(COND (ELSE ...)) although silly has a clear meaning (unless the ELSE
>clause is empty, which should be an error, but we agree on this).

Actually, JINX and I seem to agree that (BEGIN) and (COND) are equally
meaningless.  I offer to allow (COND) but feel (BEGIN) makes as much
sense.  If there's a consensus against (COND), then I'm even happier.
I'm not all that motivated by wanting to write lazy macros or program-
generating programs for reasons similar to JINX's.

Regards,
David Bartley
-------


∂28-Apr-86  1340	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: SCOOPS, and GNU support question    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Apr 86  13:39:52 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Apr 86 16:39:23 EDT
Received: from ti-csl by csnet-relay.csnet id a003922; 28 Apr 86 16:34 EDT
Received: by tilde id AA15837; Mon, 28 Apr 86 13:50:21 cdt
Date: Mon 28 Apr 86 13:42:05-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: SCOOPS, and GNU support question
To: dcj%jacksun%sun.com@CSNET-RELAY.ARPA, 
    scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <8604272304.AA11217sun.sun.uucp>
Message-Id: <12202483182.63.BARTLEY@CSC60>

  > Date: Sun, 27 Apr 86 16:04:02 PDT
  > From: Donald Clark Jackson <dcj%jacksun%sun.com@CSNET-RELAY.ARPA>
  >
  > As a user of TI-SCHEME, I kind of like
  > the SCOOPS object-oriented package.
  > I have C-Scheme running on a Sun now, and
  > I would like to get SCOOPS running on it.
  >
  > Is source for SCOOPS available, or is it
  > TI proprietary code?  Is there something
  > similar available?

I'll look into getting formal approval from our product group to
release the source for SCOOPS.  The actual SCOOPS source for TI's PC
Scheme has some implementation-dependent efficiency hacks built in,
but we may be able to put together a sanitized portable version.
However, SCOOPS is built upon first-class environments, so it wouldn't
port to some dialects out there (including the standard).

If we get permission to give out the source, we will of course want to
make it non-proprietary, which works both ways: you owe us nothing and
we owe you nothing (well, very little!).  I'll see what we can work
out and post the result.

David Bartley
-------


∂29-Apr-86  0743	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	meaning of *global* define   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 Apr 86  07:43:13 PDT
Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 29 Apr 86 10:44:21 EDT
Received: from OZ.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Apr 86 10:42-EDT
Date: 29 Apr 1986  10:20 EDT (Tue)
Message-ID: <JINX.12202697723.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA
Cc:   JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, RRRS-Authors%mit-mc@XX.LCS.MIT.EDU
Subject: meaning of *global* define
In-reply-to: Msg of 15 Apr 1986  15:49-EST from willc%tekchips%tektronix.csnet at CSNET-RELAY.ARPA

    What is the difference between having incorrect procedures all over
    the place and having incorrect numbers, lists, strings, or vectors all
    over the place?

It would be possible to fix other objects if in our system all objects
maintained a history of how they were created, and often I think that
this would be a very nice debugging environment.  Unfortunately, for
efficiency reasons, they do not.  Procedures, fortunately, contain the
environments where they are closed, and these include most of the
relevant information about their creation history.  By modifying these
environments we can patch a running system in a way we cannot patch it
if the "wrong value" happens to be a vector or other "simple" data
structure.  Just because we cannot provide a more general and powerful
debugging tool, it does not mean that we should not provide an
extremely useful (the most useful to me) special case.

In terms of implementation, there are various possible trade offs.  I
can easily accept a system where incremental definition (when it does
not degenerate into assignment) causes a garbage-collection-like
process to occur to make all the references consistent.  I am
perfectly willing to pay the price of a very powerful feature which I
use relatively often.

PS: Sorry about taking so long to answer this message.  It was buried
in a large pile.

∂30-Apr-86  1425	@MC.LCS.MIT.EDU:jcm@ORNL-MSR.ARPA 	Questions from a newcomer
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 Apr 86  14:19:02 PDT
Received: from ORNL-MSR.ARPA by MC.LCS.MIT.EDU 30 Apr 86 17:18:30 EDT
Received: by ORNL-MSR.ARPA (4.12/4.9)
	id AA16413; Wed, 30 Apr 86 16:38:46 edt
Date: Wed, 30 Apr 86 16:38:46 edt
From: jcm@ORNL-MSR.ARPA (James A. Mullens)
Message-Id: <8604302038.AA16413@ORNL-MSR.ARPA>
To: scheme@mc
Subject: Questions from a newcomer


Hi -

I would like to learn know about an implementation of Scheme which runs
on VAX VMS 4.x and an implementation which runs on a 68000 machine
(especially Amiga, Macintosh Plus, Sage/Stride, or Atari 1040ST).  I
have seen a reference to Scheme 312 which sounded interesting.

I have also seen a reference to "Chez Scheme" for VAX BSD 4.2++ which I
would like to know more about.

I am especially interested "native" implementations (not implemented on
top of another Lisp), versions with a compiler, and versions which are
public domain.  I have purchased TI's PC Scheme for my IBM AT.

I am interested in Scheme because I think it may run reasonably well on
a micro I can afford to have at home.  I have a Sage II now, but I am
considering another 68000 machine.  I am also hoping that Scheme will
be a simple, easy to implement Lisp which is not thundering towards
commercialization.

I tried Golden Common Lisp on ATs and was disappointed in the
unwieldiness.

We have Common Lisp (DEC Lisp and NIL) on the VAXen I use at work,
but I would like to investigate Scheme as an alternative.

- Thanks

jim mullens
oak ridge national laboratory

∂30-Apr-86  2156	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	Questions from a newcomer    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 Apr 86  21:56:39 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 MAY 86  00:55:49 EDT
Date: 1 May 1986  00:43 EDT (Thu)
Message-ID: <JINX.12203116956.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   jcm@ORNL-MSR.ARPA (James A. Mullens)
Cc:   scheme@MC.LCS.MIT.EDU
Subject: Questions from a newcomer
In-reply-to: Msg of 30 Apr 1986  16:38-EDT from jcm at ORNL-MSR.ARPA (James A. Mullens)

MIT CScheme runs on a wide variety of machines with C compilers.  In
particular it runs on some 68000 systems (mostly unices) and on VMS.

It currently does not have a compiler, but will have one by the end of
the summer (the VAX back end may not be ready at that time, however).
It is public domain.

∂05-May-86  1142	@MC.LCS.MIT.EDU:amn@LOCUS.UCLA.EDU 	getting C-Scheme running on HP workstations 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 May 86  11:42:26 PDT
Received: from LOCUS.UCLA.EDU by MC.LCS.MIT.EDU  5 May 86 14:40:34 EDT
Date:           Mon, 5 May 86 11:26:40 PDT
From:           Arthur Newman <amn@LOCUS.UCLA.EDU>
To:             scheme@mc.lcs.mit.edu
Subject:        getting C-Scheme running on HP workstations
Message-ID:     <860505.182640z.03031.amn@ZEUS.LOCUS.UCLA.EDU>

By just installing the student version we would get the following bug:
trying to set! an undefined variable would cause a bus error and kick
you out of Scheme back to the system prompt.
I recompiled Scheme using the normal.bin file, and eval'ed
(enable-language-features).  Now trying to set! undefined variables
just gives an error message.
Are there any reasons why we had trouble with set! in the student system
that you can think of?
Thanks for any help,
Arthur Newman

∂05-May-86  1402	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	one more message about CScheme    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 May 86  14:02:15 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 MAY 86  17:01:34 EDT
Date: 5 May 1986  16:26 EDT (Mon)
Message-ID: <JINX.12204337135.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   scheme@MC.LCS.MIT.EDU
Subject: one more message about CScheme


Please, send bug reports about MIT CScheme to
bug-cscheme%oz@mit-mc, not to this (scheme@mit-mc) mailing list.

bug-scheme%oz@mit-mc is not good either.  There is more than one
implementation at MIT, and bug-scheme does not refer to CScheme.

General questions about CScheme should be sent to
info-cscheme%oz@mit-mc.

Thanks.

PS: When answering bug reports incorrectly sent to this mailing list I
have tried not to send the reply here.  If you have run across similar
bugs, and have not received a reply, send mail to bug-cscheme, since
they have probably been fixed.  Notices of bug fixes, etc, are sent to
info-cscheme.

∂05-May-86  1910	@MC.LCS.MIT.EDU:serafini@ames-aero 	implementation roundup  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 May 86  19:09:55 PDT
Received: from ames-aero.ARPA by MC.LCS.MIT.EDU  5 May 86 21:41:26 EDT
Date: 5 May 86 18:32:00 PST
From: DAVE SERAFINI <serafini@ames-aero>
Subject: implementation roundup
To: scheme <scheme@mit-mc.arpa>
Reply-To: DAVE SERAFINI <serafini@ames-aero>

Has anyone compiled a list of the various implementations of scheme extant, 
and could I be send a copy?

advTHANKSance

Dave Serafini        
------

∂05-May-86  1914	JAR@MC.LCS.MIT.EDU 	implementation roundup   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 May 86  19:13:36 PDT
Date: Mon,  5 May 86 22:12:44 EDT
From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Subject:  implementation roundup
To: serafini@AMES-AERO.ARPA
cc: SCHEME@MC.LCS.MIT.EDU
In-reply-to: Msg of 5 May 86 18:32:00 PST from DAVE SERAFINI <serafini at ames-aero>
Message-ID: <[MC.LCS.MIT.EDU].904409.860505.JAR>

    Date: 5 May 86 18:32:00 PST
    From: DAVE SERAFINI <serafini at ames-aero>

    Has anyone compiled a list of the various implementations of scheme extant, 
    and could I be send a copy?

There's a list of implementations, with brief descriptions, in the file
"SCHEME;SCHEME IMPLS" on MIT-MC.  I compiled it from messages sent to
this mailing list.  I don't think MC's FTP server requires passwords to
log in; if you are asked to supply a user name or password, give
arbitrary strings like GUEST and ARPA.

People who don't have Internet access and want a copy of this file
should send a message to JAR@MC (not to SCHEME@MC!) requesting it.  I'll
batch requests, except that if I get more than ten requests I'll simply
send the file out to the entire Scheme mailing list.  It's about 12K
bytes so I'll have to mail it in two pieces (MC's mailer is limited to
10 or 11K).

Jonathan

∂22-May-86  0819	NET-ORIGIN@MC.LCS.MIT.EDU 	H, E, S, B, O, D, X    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 May 86  08:19:24 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 MAY 86  11:17:45 EDT
Received: from JOE-LOUIS.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1619; Thu 22-May-86 11:18:03-EDT
Date: Thu, 22 May 86 11:18 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: H, E, S, B, O, D, X
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <"860522111800.2.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>


Has anyone implemented number output formats in their entirety?  A
number of people have requested the the following minor change:  that
the keywords which are now single letters be spelled out.  E.g.
EXPRESSED and SUPPRESSED instead of E and S.

We can discuss the details separately.  If some people think such a
change is a bad idea at this point then the change shouldn't be made.
But if no one has implemented it and people like the idea then I think
it can be done pretty painlessly.

The letters in question are H, E, S, B, O, D, and X.  If you don't know
what they mean that simply attests to the desirability of spelling them
out.

Jonathan

∂22-May-86  0900	NET-ORIGIN@MC.LCS.MIT.EDU 	LOAD    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 May 86  08:54:27 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 MAY 86  11:53:10 EDT
Received: from JOE-LOUIS.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1622; Thu 22-May-86 11:51:29-EDT
Date: Thu, 22 May 86 11:51 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: LOAD
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <"860522115129.3.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>


I would like to either remove LOAD from the report or change the way in
which it is presented.

Reasons:

(a) A LOAD procedure is equipotent with EVAL, and EVAL isn't documented.
The same reasons that applied to kick out EVAL apply here.

(b) It seems to me a perfectly reasonable idea to create Scheme systems
that don't have a LOAD procedure.  I can imagine at least two completely
different kinds of implementations in which LOAD wouldn't make sense.
One kind of implementation would be in the style of most implementations
of PASCAL, FORTRAN, etc., where one runs programs by configuring entire
environments at once.  This avoids all the semantic stickiness of LOAD
and EVAL by making configuration a meta-issue.  Second, at the opposite
extreme, in an Interlisp-like implementation where one actually edits
"in core", and files don't generally come into play, LOAD is pretty
meaningless.

(c) It seems to me that LOAD is a user interface/programming environment
issue.  We don't talk about read-eval-print loops, or entering or
exiting scheme, or logging in, or editing files; how is this different?

Alternative solutions:

(1) Omit it entirely without saying anything.

(2) Mention somewhere (e.g. in the introduction) that Scheme is
"usually" an interactive language with a read-eval-print loop and
support for things like interactive debugging and dynamic program
loading.

(3) Reclassify LOAD as being part of the syntax of a file.  I.e., like
DEFINE, it can only occur at top level in a file.

(4) Leave it alone, but put it in a "user interface" section along with
TRANSCRIPT-ON and TRANSCRIPT-OFF (and maybe TRACE, DEBUG, and EDIT?),
instead of classifying it as an input procedure.  Make a disclaimer that
these things are only guaranteed to work "at top level" (whatever that
is).

(5) Some combination of (3) and (4) [allow it both in files and at
command loops].


Feedback solicited.

-Jonathan

-----

KMP: please send a message making a case for a (LOAD-SILENTLY x).

∂22-May-86  1016	@MC.LCS.MIT.EDU:andy@aids-unix 	Re:  LOAD    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 May 86  10:16:06 PDT
Received: from ads-grape.ARPA by MC.LCS.MIT.EDU 22 May 86 13:14:03 EDT
Date: Thu, 22 May 86 10:13:20 pdt
From: andy@aids-unix (Andy Cromarty)
To: JAR@MIT-AI.ARPA
Subject: Re:  LOAD
Cc: rrrs-authors@mit-mc

1. Numbers: I agree with full naming.  Even when I was actively working
   on a full numbers package I couldn't remember what these were
   wiuthout looking them up.  Perhaps implementations should be free
   to support single-letter names in "not recommended" status for
   the sake of downward compatibility.

2. LOAD: This is sticky.  The beast probably should not exist in this
   or any other language, because files themselves are a bad idea
   left over from the early days of computer science when we didn't
   know any better and allowed hardware to dominate software design.
   The problem is that not having LOAD available requires that we
   have an alternative available, which means either (a) having a
   transparent or essentially transparent object filing system or (b)
   having a non-transparent object filing system with an explicit
   object-writing operator (e.g. WRITE or some variant would have to
   be able to render permanent any arbitrary object, such as functions
   that make lexical reference to variables from an enclosing scope
   and similar LISP objects that can have very messy state in a
   lexically scoped environment).
   
   If we have LOAD available but we don't document it, we have simply
   ignored the problem, rather than either solving it or admitting we
   can't yet.  The fact is that, unlike EVAL, LOAD is something that
   everyone will have to use, including newcomers; it's not esoterica,
   even if it does interfere with intellectual cleanliness.  The means
   to address such cleanliness issues is probably design, not selective
   non-documentation.

   A good compromise might be to add a paragraph of comment,
   something like what appears in the RRRS for macros, stating that
   this is currently a difficult area in LISP design and that LOAD
   is provided but that work on alternatives (e.g. object filing systems)
   is encouraged.

					asc

∂22-May-86  1558	@MC.LCS.MIT.EDU:KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Notes about (↑ revised 3) report   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 May 86  15:58:13 PDT
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 22 May 86 18:55:22 EDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6687; Thu 22-May-86 18:53:41 EDT
Date: Thu, 22 May 86 18:53 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Notes about (↑ revised 3) report
To: JAR@MIT-MC.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA, RRRS-AUTHORS@MIT-MC.ARPA
Message-ID: <860522185327.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

On p30, while reading the description of READ, the following questions
occurred to me, the answers to which are in some cases probably dependent 
upon the answers to the others in order to assure useful consistency:

 * Does the stream become closed as a side-effect of hitting eof?

 * Is it an error to read from a closed stream, or does eof just keep
   getting returned?

 * Can you read the eof object twice at the end of a file using READ ?
   How about if using READ-CHAR ? PEEK-CHAR ?

 * Is it possible to detect whether a file is closed?

 * Is it acceptable for close on certain streams to not really close the file?
   For example, I could imagine implementing terminal streams or streams into
   editor buffers in a way such that they just always claimed to be open and 
   close was a no-op.

Also on p30, it seems to me that the notion of CHAR-READY? is not a useful one. 
It's subject to timing errors in multi-processed systems and/or systems which 
allow asynchronous interrupts. The Lisp Machine's TYI-NO-HANG paradigm is much 
better, since it has a more test-and-set feel to it and is more easy to use 
reliably. I suggest that CHAR-READY? should be flushed and replaced by a 
READ-CHAR? which returns either a character if one is ready, or NIL otherwise. 
This gets you out of the bind with rubbing out stuff that CHAR-READY? has 
noticed, which is really an awful crock. I believe that TYI-NO-HANG will
interact satisfactorily with Lispm-style rubout handlers.

On p30, the issue with LOAD is that if we're going to define it, we need to give
it a standard meaning so it can be usefully used on different systems. If we
don't say it either types out or doesn't, then people can't use it in their
programs for fear it will screw up the display (this exact problem arose in real
situations in my work with Common Lisp). I feel that a LOAD which does
no typeout is a useful interface to the operating system and a necessary 
feature for bootstrapping other code. The absence to provide it will mean that
either every user will have to type in a definition of load at the keyboard
or every system will have to provide it anyway. Obviously, this translates
to that every system will provide one, since no one's going to force the user
to type it in. If every system is going to provide it, we might as well
standardize on it so people can know what they're getting. If particular 
dialects want to offer additional options, well, ... you're no doubt aware
of my feelings on this issue and i'll spare the cc'd folks for now.


∂23-May-86  0957	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: H, E, S, B, O, D, X  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 23 May 86  09:57:07 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 23 May 86 12:54:49 EDT
Received: from ti-csl by csnet-relay.csnet id a004166; 23 May 86 12:35 EDT
Received: by tilde id AA21938; Fri, 23 May 86 10:21:49 cdt
Date: Fri 23 May 86 10:06:06-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: H, E, S, B, O, D, X
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA, 
    rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <"860522111800.2.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
Message-Id: <12208997463.23.BARTLEY@CSC60>

We have implemented the number output formats in PC Scheme.  I like
the idea of spelling out the keywords and won't "vote" against it, but
there are two troublesome aspects:

(1) We already have a product out that supports the abbreviated style,
so we'd have to grandfather it.  That's always a minor pain.

(2) My experience is that not one programmer in ten can spell both
EXPRESSED and SUPPRESSED correctly (sorry about that!).  What should
NUMBER->STRING do with EXPRESED or SUPRESSED?  [Of course, there are
plenty of other opportunities for misspellings to trip one up!]

Seriously, I recommend that we retain the single letter abbreviations
as an option if we switch to full names for these keywords.

Regards,
David Bartley
-------


∂23-May-86  1013	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: LOAD  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 23 May 86  10:12:57 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 23 May 86 13:08:09 EDT
Received: from ti-csl by csnet-relay.csnet id ab04166; 23 May 86 12:36 EDT
Received: by tilde id AA21281; Fri, 23 May 86 10:06:37 cdt
Date: Fri 23 May 86 09:54:59-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: LOAD
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA, 
    rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <"860522115129.3.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
Message-Id: <12208995440.23.BARTLEY@CSC60>

My first thought is that LOAD should be retained, but not as an
essential procedure.  That would help a programmer avoid some name
conflicts, since most implementations of Scheme and Lisp have a LOAD.

My second thought is to wonder why we have included non-essential
procedures in the Report.  Is it to warn a programmer that the given
identifier should be considered "reserved" or is it to guide
implementors toward consistent extensions to the essential language?
In the first case, I'd say that the programmer should be referring
primarily to the manual for his implementation, not to the Report, and
that that manual should take care to warn him of portability issues.
In the second case, I'd say that our coverage of "suggested"
extensions is so patchy that it's almost irrelevant whether LOAD is
mentioned or not.  After all, where are COMPILE and EVAL, two obvious
names for extended features?

So, my inclination is to let JAR do whatever he likes.  This is a
pragmatic issue.  Ideally, we'd have an appendix that discusses these
things, but that may be Pandora's box.

--db--
-------


∂25-May-86  0923	@MC.LCS.MIT.EDU:VERACSD@USC-ISI.ARPA 	Addition to Mailing-List   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 25 May 86  09:23:11 PDT
Received: from USC-ISI.ARPA by MC.LCS.MIT.EDU 25 May 86 12:18:59 EDT
Date: 25 May 1986 12:18-EDT
Sender: VERACSD@USC-ISI.ARPA
Subject: Addition to Mailing-List
From: VERACSD@USC-ISI.ARPA
To: scheme@MC.LCS.MIT.EDU
Cc: veracsd@USC-ISI.ARPA
Message-ID: <[USC-ISI.ARPA]25-May-86 12:18:05.VERACSD>

Please add me to your Scheme Mailing-List.

I  am  presently  running  MacScheme,  and  have  used it to work
through the examples in the Abelson  &  Sussman  book,  define  a
Common Lisp compatibility package, and implement a PROLOG.

I am particularly interested in using continuations and macros in
Scheme.  I have a great general  interest  in  logic-programming,
and the imple- mentation of logic-programming languages.

Thanks.

-- Cris Kobryn

∂25-May-86  1237	@MC.LCS.MIT.EDU:VERACSD@USC-ISI.ARPA 	Addition to Mailing-List   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 25 May 86  12:37:32 PDT
Received: from USC-ISI.ARPA by MC.LCS.MIT.EDU 25 May 86 15:14:26 EDT
Date: 25 May 1986 12:18-EDT
Sender: VERACSD@USC-ISI.ARPA
Subject: Addition to Mailing-List
From: VERACSD@USC-ISI.ARPA
To: scheme@MC.LCS.MIT.EDU
Cc: veracsd@USC-ISI.ARPA
Message-ID: <[USC-ISI.ARPA]25-May-86 12:18:05.VERACSD>
ReSent-To: scheme@MC.LCS.MIT.EDU
ReSent-From: VERACSD at USC-ISI.ARPA
ReSent-Date: 25 May 1986

Please add me to your Scheme Mailing-List.

I  am  presently  running  MacScheme,  and  have  used it to work
through the examples in the Abelson  &  Sussman  book,  define  a
Common Lisp compatibility package, and implement a PROLOG.

I am particularly interested in using continuations and macros in
Scheme.  I have a great general  interest  in  logic-programming,
and the imple- mentation of logic-programming languages.

Thanks.

-- Cris Kobryn

∂26-May-86  1555	@MC.LCS.MIT.EDU:JAR@MX.LCS.MIT.EDU 	R↑3RS draft   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 May 86  15:55:20 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 MAY 86  18:54:42 EDT
Date: Mon, 26 May 86 18:54:00 EDT
From: Jonathan A Rees <JAR@MX.LCS.MIT.EDU>
Subject:  R↑3RS draft
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].921583.860526.JAR>

I have mailed / given out copies of the latest draft of the report (22
May).  People in Boston and New Haven should have either received one
from me or should stop by and pick one up.  A copy went to Tektronix by
special courier.  People with Internet access AND Latex AND something
that will read Unix "tar" files should FTP to MIT-PREP, using user
Scheme and null password if necessary, and get the file
"/u/jar/r3rs.tar".  If FTP doesn't seem to work, then try telnetting to
PREP and logging in as Scheme (no password needed).  The login shell is
FTP.  Send the abovementioned file to your machine.  Extract all the
files somewhere and run Latex on the file "rrrs.tex".  If you don't have
something that will read tar files, use FTP to get all the files on the
directory /u/jar/r3rs.

On Friday I mailed one copy to Dan Friedman and one copy to Dave
Bartley, so people at Indiana and TI should get extra copies from them.
Anyone else who wants one mailed should let me know right away (although
I think that everyone has been taken care of).

There is a cover letter, too, relevant parts of which I'll send
electronically.

Jonathan.

∂27-May-86  1120	NET-ORIGIN@MC.LCS.MIT.EDU 	Remaining questions & remarks (1)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 May 86  11:19:24 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 MAY 86  14:18:40 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 1808; Tue 27-May-86 14:18:17-EDT
Date: Tue, 27 May 86 14:19 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: Remaining questions & remarks (1)
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <"860527141917.1.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>


I included the following with the reports I sent and gave out.  Here it
is again for those people who don't have it already.  It enumerates most
of the remaining nits I have.  Don't be intimidated by the number of
items; none are serious.  Many of these questions have been discussed
and some have been resolved already.  For those items that stay
unresolved, I'll take the conservative position and leave the new report
in agreement with the old report.

I'll send a second, more recent set of nits separately.

- Jonathan

-----

Questions on LANGUAGE

I left CASE as is, using EQV? as the comparison, and I explicitly stated
that the object ought to be boolean, character, number, or symbol.  But
shouldn't it allow empty lists, vectors, and strings, too?

May structure be shared in cases like (APPEND '(A B) '()) , or should APPEND
be Common Lisp compatible?  [Bartley says sharing would be a gratuitous
incompatibility with CL, I'm invlined to agree.]

Should APPEND and APPEND! explicitly allow any object as last argument
(CL compatible)?

Should APPEND! disallow () as other than last argument?

I decided that allowing GCD, etc. of Gaussian integers was probably
premature.  I'll put them in if someone writes the documentation
(including examples).

Can we decide on what to do about number exactness on input?  How about:
inexact if there are digits following a decimal point, or if exponential
notation is used.  Otherwise exact.

Can we specify that DISPLAY of a character does the same thing as
WRITE-CHAR?

What should be said, if anything, about the desirability and/or legality
of EQUAL? failing to terminate?  Rozas thinks an implementation with
this property is in error.

In light of the vagaries of CALL-WITH-xxPUT-FILE, perhaps it
would be a good idea to explicitly state that closing a closed port
should be a no-op instead of an error.

-----

Questions on PRESENTATION

Should the various examples which use DEFINE be changed to use the
(define (foo ...) ...)  syntax instead of (define foo (lambda ...))?
Several people have told me that all those LAMBDA's could unnecessarily
intimidate SIGPLAN readers.

There are two places (in descriptions of let* and letrec) where it is
necessary to create a lambda body in a context (such as the tail of a
BEGIN) where there isn't one already.  What is the cleanest way to do
this?  Is (let () ...) ok, or would ((lambda () ...)) or something else
be better?

Is the word ``promise'' all right for objects returned by DELAY?

Should the complete presentation of FORCE appear up front with DELAY, or
delayed until the place where the entry for FORCE appears?

-----

Notes on LANGUAGE

The selectors in a CASE expression must be distinct.

I have left CASE and COND syntax as in RRRS: there must be at least one
clause, but it may be an ELSE clause.

BOOLEAN? is essential.

No agreement on COND or BEGIN.  I have left them as in RRRS.
[To do: fix the BNF to agree!]

The RRRS explicitly allows internal definitions in the body of a LETREC.
They are scoped to the body only, not to the entire expression.  I can
flush this "feature" if a movement arises to do so; it seems sufficient
to me to permit only expressions (not definitions) in the body.

The list to which the rest argument gets bound must be newly allocated.

Making LET* be essential was suggested, but there was resistance to
this, so I left it as is.

There was strong sentiment both for removing REC and for removing
NAMED-LAMBDA.  However, the sentiment was not unanimous.  I don't
understand why it should have matterred so much, since neither is an
essential feature.  If these are present, shouldn't everyone's favorite
features be present too?  ... Supporters of REC included Kent Dybvig and
Dan Friedman.  Supporters of NAMED-LAMBDA included Jim Miller and Henry
Wu.  In addition, Bill Rozas insisted that if REC stayed, then
NAMED-LAMBDA must stay too, but he was willing to see both go.

APPEND! necessarily clobbers its arguments (other than the last and
empty ones).

Many people wanted the number predicates pruned (i.e. choose between <
and <?).  No agreement here, so both stay.

The BNF says that ALL random symbols, including ELSE, =>, UNQUOTE, and
UNQUOTE-SPLICING, are reserved and may not be used as variable names.  I
hope this is OK with everyone.

Note that the grammar for numbers allows one to write things like 23##
for inexact numbers.  This was implicit in last summer's report, and I
thought it wouldn't make sense if this was allowed on output but not on
input.

The case sensitivity issue was a very sensitive one (so to speak).  I
did not change the report's stance of symbol case insensitivity.

-----

Notes on PRESENTATION

I listed myself as "editor" of this version.  I probably should just
remain a coauthor, but the report needs an editor in order to look like
the Algol 60 report.

I eliminated the term ``special form.''  I introduced phrases like ``IF
expression'' in a couple of places; things like IF and CASE are not
referred to as active agents (keywords don't refer to particular
things---it's the evaluator that actively interprets expressions having
certain special syntactic forms).  I removed statements like
``<expression> is evaluated but <variable> is not.''

At Pitman's request, I changed ``guard'' to ``test'' in the description
of COND because ``guard'' has inappropriate connotations; COND doesn't
really implement a Dijkstra guarded conditional.

The term "variable" now refers the name itself, not the binding or the
location.  This is in accordance with the way logicians (including
Alonzo Church) use the term.

I decided not to add an appendix describing S&ICP differences.  The most
important difference, I think, was RRRS's lack of DELAY and FORCE.  I no
longer find the presence of SEQUENCE distasteful.

I removed the apologetic statement that went with the description of T
and NIL.  (Some people actually like T and NIL.)

The sentence ``This procedure can be very confusing if used
indiscriminately'' in the descriptions of set-car! and set-cdr! was
struck at Chris Hanson's request; it seemed gratuitous.

There are at least sixteen different references to Common Lisp.  I'm
going to try to remove some of them.  We have to make it very clear that
Scheme is 11 years old and originated some of CL's ideas --- not the
other way around!

∂27-May-86  1339	@MC.LCS.MIT.EDU:cth%indiana.csnet@CSNET-RELAY.ARPA 	define (resend)   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 May 86  13:38:40 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 May 86 16:37:57 EDT
Received: from indiana by csnet-relay.csnet id a009297; 27 May 86 15:40 EDT
Date: Tue, 27 May 86 12:20:15 EST
From: Chris Haynes <cth%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: define (resend)

We have one great difficulty with the RRRS as it stands: DEFINE can not make
global bindings when used locally and still be consistent with the report.
Much has been said about the pros and cons of the "MIT style" local define,
and it is clear that a consensus is not possible, so a compromise is in
order.  Simply making MIT style optional is not acceptible: optional syntax,
if implemented, must conform to a single semantics.  Thus DEFINE semantics is
preempted as the report is currently written.  

Using a different keyword, such as DEFINE-GLOBAL, to make global definitions
from lexically nested positions is not acceptible to us.  We have tried to
live with such arrangements for some months now, and have found them
intolerable.  

A compromise position would be to include a form such as DEFINE-GLOBAL in
the report, hopefully as a required special form, and make an explicit
exception in the case of DEFINE to the rule that optional features, if
implemented, always have a single semantics.  The idea is that it should be
possible, in any "standard" Scheme that supports some kind of macro package,
to get *either* style of lexical DEFINE by simply loading the appropriate 
macro package.  Failing that, it should at least be *possible* for a 
Scheme implementation to provide such packages, and allow either package to
be loaded without stepping outside of the "standard".

This compromise is not something that anyone would love, but it is most
sincerely hoped that it is something that everyone can live with.  Then
no one will feel bad about being associated with the RRRS.

Chris Haynes
Dan Friedman
Kent Dybvig


∂27-May-86  1844	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	define (resend) (long)  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 May 86  18:44:40 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 MAY 86  21:44:00 EDT
Date: 27 May 1986  21:43 EDT (Tue)
Message-ID: <JINX.12210162108.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   Chris Haynes <cth%indiana.csnet@CSNET-RELAY.ARPA>
Cc:   rrrs-authors@MC.LCS.MIT.EDU
Subject: define (resend) (long)
In-reply-to: Msg of 27 May 1986  13:20-EDT from Chris Haynes <cth%indiana.csnet at CSNET-RELAY.ARPA>

I'm afraid that we have a real disagreement here.

    Much has been said about the pros and cons of the "MIT style" local define,
    and it is clear that a consensus is not possible, so a compromise is in
    order.

I disagree.  Much has been said about MIT's INCREMENTAL DEFINE (which
T also has), but not much has been said at all about (static and local)
INTERNAL DEFINE, which is the only one which appears on the report.
This happened mostly for compatibility with S&ICP, not because the
people from MIT were trying to force it on anybody else (after all, we
cheerfully accepted LETREC, which we did not have before).

    Using a different keyword, such as DEFINE-GLOBAL, to make global definitions
    from lexically nested positions is not acceptible to us.  We have tried to
    live with such arrangements for some months now, and have found them
    intolerable.  

DEFINE-GLOBAL does not make sense for either T or MIT-Scheme.  Neither
really has a global environment distinguished from the rest, thus
there is no environment where these definitions could be made.  The
closest we (MIT) can come to this is making the definition occur in
the innermost environment created by means of MAKE-ENVIRONMENT (the
innermost locale in the case of T), but this seems arbitrary in our
case, to say the least, since all environments are created equal.  In
T this is not the case, so this is a viable option.  We would still do
it if everybody else agreed to it, but we'd rather not, since there
are other options (see below).

    The idea is that it should be
    possible, in any "standard" Scheme that supports some kind of macro package,
    to get *either* style of lexical DEFINE by simply loading the appropriate 
    macro package.  

What about Schemes that do not have macros at all?  Does this mean
that they have to choose one of the two styles, and thus have no
possibility of running the "portable" code written using the other?  I
disagree very strongly with having a feature with two possible
inconsistent semantics.  The only option would be to remove its
optional status, and therefore remove it from the report completely.
Thus nobody would be able to use DEFINE at all in portable code.
Changing semantics now, besides being unacceptable to us, would mean
being purposely incompatible with S&ICP, and gratuitously incompatible
with the previous version of the report.

What is it that you do not like about DEFINE-GLOBAL?  The name is too
long?  Use DEFINE! or DEF instead.  The first was suggested at the meeting
in Brandeis.  Is the problem that it is not even in the report, so you
can't use it because it is not portable?  I'm pretty convinced that we
(MIT) could be convinced of accepting it for the sake of consensus
after a little arm twisting (very little needed).

Note that there is a portable way of achieving the effect of
DEFINE-GLOBAL:

(define foo)	; or (define foo '*)
(define bar)	; or (define bar '*)

(let ((<local-state>))
  (set! foo <whatever you want 1>))
  (set! bar <whatever you want 2>)))

We often do this (although we have and use alternatives) to "export"
values to outer environments, but this gives us more control than
DEFINE-GLOBAL, since we can just place the DEFINEs in the environment
where we want the definitions to occur.

If you do not like the assignments, there is the following
alternative:

(with-exports (foo bar)
  (let ((<local-state>))
    (define-export foo <whatever you want 1>)
    (define-export bar <whatever you want 2>)))

which would just be pretty syntax for the previous choice.  Note that
DEFINE-EXPORT (or DEFINE!, or anything you want to call it) is nothing
special, since it trivially turns into SET!.

Note that the (FOO BAR) list could be made optional, meaning "trap"
all DEFINE-EXPORTs.


∂28-May-86  0827	@MC.LCS.MIT.EDU,@KATHERINE.THINK.COM:gls@AQUINAS.THINK.COM 	Remaining questions & remarks (1)  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86  08:26:59 PDT
Received: from Godot.Think.COM by MC.LCS.MIT.EDU 28 May 86 11:21:41 EDT
Received: from KATHERINE.THINK.COM by Godot.Think.COM; Wed, 28 May 86 10:42:51 edt
Date: Wed, 28 May 86 10:43 EDT
From: Guy Steele <gls@Think.COM>
Subject: Remaining questions & remarks (1)
To: JAR@MIT-AI.ARPA
Cc: rrrs-authors@MIT-MC.ARPA
In-Reply-To: <"860527141917.1.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>
Message-Id: <860528104332.1.GLS@KATHERINE.THINK.COM>

    Date: Tue, 27 May 86 14:19 EDT
    From: Jonathan A Rees <JAR@MIT-AI.ARPA>
    ...
    There are at least sixteen different references to Common Lisp.  I'm
    going to try to remove some of them.  We have to make it very clear that
    Scheme is 11 years old and originated some of CL's ideas --- not the
    other way around!

That's right!  Good for you.
--Guy


∂28-May-86  0836	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	hash-consing   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86  08:36:45 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 May 86 11:33:21 EDT
Received: from ti-csl by csnet-relay.csnet id aj17147; 28 May 86 11:08 EDT
Received: by tilde id AA18724; Wed, 28 May 86 09:55:46 cdt
Date: Wed 28 May 86 09:45:51-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: hash-consing
To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
Message-Id: <12210304495.60.BARTLEY@CSC60>

Has anyone had any experience with systems that use hashing CONS?  I
remember the idea was in vogue 15 or 20 years ago as a way to lower
memory consumption, speed up EQUAL, and for theoretical (heretical?)
reasons.  The idea is to use hashing techniques to make pairs that are
EQUAL? also be EQ?.

The disadvantages seem to be (1) slower CONS, (2) unclear semantics
for SET-CAR! and SET-CDR!, (3) separate spaces or tags (or something)
if both hashed and regular CONS exist, and (4) GC complications.  Are
there any experimental results that demonstrate any significant
compensating advantages?  If so, what are the circumstances?

The definition of CONS in the RRRRS guarantees that every pair
returned is unique, so hashing would seem to be out of the question.
However, I wonder if a HASH-CONS procedure has any merit.

Regards,
David Bartley
-------


∂28-May-86  1137	@MC.LCS.MIT.EDU:andy@aids-unix 	Re:  define  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86  11:37:37 PDT
Received: from ads-grape.ARPA by MC.LCS.MIT.EDU 28 May 86 14:36:14 EDT
Date: Wed, 28 May 86 08:04:09 pdt
From: andy@aids-unix (Andy Cromarty)
To: JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, cth%indiana.csnet@CSNET-RELAY.ARPA
Subject: Re:  define 
Cc: rrrs-authors@MC.LCS.MIT.EDU

If we are casting votes on DEFINE, I would observe that of the
half-dozen or so of us here who are directly involved in our Scheme
effort, only one of us favors any legitimate status for "global"
DEFINEs.  (He happens to come from Indiana, BTW, and we may have 
succeeded in changing even his mind on this issue.) The rest of us 
have from the outset found Scheme-84's global DEFINE semantics to be 
an abhorrent violation of the principles of lexical scope.  In fact,
we assumed it was a compiler bug when we first ran across it.

Even where there is a most global environment, we are hard-pressed
to see what could justify advocacy of a special form that reaches
into it specially from an enclosed scope to destructively manipulate 
its state.  If we (collectively) need an extension of Scheme to achieve 
this effect, let's promote binding environments to first-class objects and
define a destructor that treats them uniformly.  (I believe, however,
that it is possible to write substantive, efficient, and above all,
elegant Scheme programs without the inclusion of such a destructor.)

I have always felt that the global DEFINE in Scheme-84 was a profound
design flaw that must be attributable to the unfortunate influence of
the Franz environment (both software and intellectual) in which Scheme-84
was constructed.  I understand that there is a substantial difference of
opinion on this issue, but we find it difficult to see how global DEFINEs
are even arguably compatible with what we take to be fundamental design
principles of Scheme.  In fact, as evidence of our objection to Scheme-84's
global DEFINE semantics, we have done some work on ripping this feature out 
of a copy of the Scheme-84 compiler, replacing it with S&ICP's internal 
DEFINE.

					asc

p.s. My apologies for blitzing you with such a strong opinion; we hashed
     this one out locally until it was beaten to death some time ago,
     and our opinions have admittedly become somewhat calcified....

∂28-May-86  1241	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  define (resend) (long) (short)   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86  12:41:36 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 May 86 15:40:20 EDT
Received: from indiana by csnet-relay.csnet id ab19262; 28 May 86 15:35 EDT
Date: Wed, 28 May 86 13:30:30 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: jinx@MC.LCS.MIT.EDU
Subject: Re:  define (resend) (long) (short)
Cc: rrrs-authors@MC.LCS.MIT.EDU

It is too much to ask everyone who has learned to use "define" the
way we know and love it here to switch to either a new word or a
new meaning for internal definitions.  We feel that we have given it
our best shot over the past year, having tried both "define!" and
"global-define".  What it boils down to is that (1) the same name
should be used inside as out to define global variables and (2) the
right name is define.

You mentioned the possibility of omitting internal define altogether.
We would be satisfied with that.  The report should say something to
the effect of portable code should only use the define/set! form (or
appropriate sugaring).  This seems to be the only viable solution.


∂28-May-86  1736	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	define (resend) (long) (short)    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86  17:36:26 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 MAY 86  20:34:54 EDT
Date: 28 May 1986  20:34 EDT (Wed)
Message-ID: <JINX.12210411645.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
Cc:   rrrs-authors@MC.LCS.MIT.EDU
Subject: define (resend) (long) (short)
In-reply-to: Msg of 28 May 1986  14:30-EDT from Kent Dybvig <dyb%indiana.csnet at CSNET-RELAY.ARPA>

    What it boils down to is that (1) the same name
    should be used inside as out to define global variables and (2) the
    right name is define.

Again, this does not make any sense in MIT Scheme, where user code
runs by default in an environment which inherits the "global"
bindings, rather than the one were the bindings actually exist.  Top
level DEFINEs do not define in the global environment, but in whatever
environment the code is loaded.  The default top level environment is
an environment with an empty top frame, and whose parent frame
contains the initial accessible bindings of the system.  Our system
(local and incremental DEFINE) is perfectly consistent, since DEFINE
always acts on the environment where the definition is evaluated.
There is no difference between top level and inner environments.  As a
matter of fact, top level is changed at various times, and thus top
level DEFINE acts on different environments at different times.

Indiana style DEFINE sounds horrendous to me because the evaluation
happens in one environment, while the "assignment" happens in another,
without making this explicitely visible.  Nevertheless, I'm willing to
have it added it to the report as long as it has a different name
(DEF?).  Note that if DEF is implemented, it will also "work" at top
level, so you can always use the same name.

    You mentioned the possibility of omitting internal define altogether.
    We would be satisfied with that.  The report should say something to
    the effect of portable code should only use the define/set! form (or
    appropriate sugaring).  This seems to be the only viable solution.

Again, this is being gratuitously different from the previous version
of the report, and S&ICP.  We are keeping T and NIL, #!TRUE and
#!FALSE, just to be backwards compatible.  Removing DEFINE would allow
implementations (like you) to have semantics completely incompatible
with the previous report.

Look guys, I hate BEGIN with all my guts.  I am not fighting against
it.  We had a vote at Brandeis and it WON (I cast the only vote
against it).  I (and JAR, and GJS, who hate it almost as much as I do)
abide by that decision (although I occasionally grumble about it, as
well as about REC).  I would very much like to see it out, but if
everybody does this we will never agree on anything, because everybody
will find something they do not like.  I'm afraid that DEFINE must
stay the way it is, and I (and the rest of the Scheme people at MIT,
plus others, I'm sure) will oppose any changes to it.  You are
reopening a can of worms which was closed at Brandeis.  Since we are
at it, why don't we argue again about when CALL-WITH-INPUT-FILE closes
the file or whether the name should be LETREC or LABELS?

∂28-May-86  2216	@MC.LCS.MIT.EDU:gls@Think.COM 	Embedded DEFINE forms   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86  22:16:13 PDT
Received: from Godot.Think.COM by MC.LCS.MIT.EDU 29 May 86 01:14:55 EDT
Received: by Godot.Think.COM; Thu, 29 May 86 01:14:45 edt
Date: Thu, 29 May 86 01:14:45 edt
From: gls@Think.COM (Guy Steele)
Message-Id: <8605290514.AA08588@Godot.Think.COM>
To: rrrs-authors@mc
Subject: Embedded DEFINE forms

I have watched the controversy going on for quite some
time, and it seems to me that at this late date, on the
eve, apparently, of widespread publication of a standard
for SCHEME, that there is not consensus in the SCHEME
community on the subject of embedded DEFINE forms.
If the community cannot agree, nor even agree to agree
on some arbitrary choice, then the matter should not be
standardized.

I see no harm in the standard not defining what happens to
embedded DEFINE forms.  This would allow the various camps
to be upward-compatible extensions of the standard (though
of course not with each other in this regard).  RRRS might
even have, as a footnote or appendix, descriptions of the
competing proposals.

--Guy

∂28-May-86  2243	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: Notes about (↑ revised 3) report
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 May 86  22:43:32 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 01:17:54 EDT
Received: from tektronix by csnet-relay.csnet id ak02235; 29 May 86 1:04 EDT
Received: by tektronix.TEK (5.31/6.12)
	id AA09772; Tue, 27 May 86 13:03:39 PDT
Received: by tekchips (5.31/5.14)
	id AA07744; Tue, 27 May 86 13:07:54 PDT
Message-Id: <8605272007.AA07744@tekchips>
To: KMP@SCRC-STONY-BROOK.ARPA
Cc: JAR@MC.LCS.MIT.EDU, RRRS-AUTHORS@MC.LCS.MIT.EDU, 
    willc%tekchips.tektronix.csnet@CSNET-RELAY.ARPA
Subject: Re: Notes about (↑ revised 3) report
In-Reply-To: Your message of Thu, 22 May 86 18:53 EDT.
	     <860522185327.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 27 May 86 13:07:52 PDT (Tue)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

Here are the answers I prefer to KMP's starred questions; words within
brackets were edited by me.

 * Does the [port] become closed as a side-effect of hitting eof?

No.

 * Is it an error to read from a closed [port], or does [an eof-object]
   just keep getting returned?

It is an error.

 * Can you read the eof object twice at the end of a file using READ ?
   How about if using READ-CHAR ? PEEK-CHAR ?

Yes.  Yes.  Yes.

 * Is it possible to detect whether a [port] is closed?

Impossible using only the procedures documented in R↑3RS.  I'd like the
language to remain silent on whether a closed port is still a port.

 * Is it acceptable for close on certain [ports] to not really close the
   [port]?  For example, I could imagine implementing terminal [ports] or
   [ports] into editor buffers in a way such that they just always claimed
   to be open and close was a no-op.

Yes.

KMP:
    Also on p30, it seems to me that the notion of CHAR-READY? is not a
    useful one.  It's subject to timing errors in multi-processed systems
    and/or systems which allow asynchronous interrupts. The Lisp Machine's
    TYI-NO-HANG paradigm is much better, since it has a more test-and-set
    feel to it and is more easy to use reliably. I suggest that CHAR-READY?
    should be flushed and replaced by a READ-CHAR? which returns either a
    character if one is ready, or NIL otherwise.  This gets you out of the
    bind with rubbing out stuff that CHAR-READY? has noticed, which is really
    an awful crock. I believe that TYI-NO-HANG will interact satisfactorily
    with Lispm-style rubout handlers.

To some extent I agree with this, but I don't think READ-CHAR? by itself
is any better for multi-processing than CHAR-READY?.

Peace, Will

∂29-May-86  1417	NET-ORIGIN@MC.LCS.MIT.EDU 	define  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86  14:16:32 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 MAY 86  17:04:56 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 29 MAY 86  16:14:05 EDT
Date: Thu, 29 May 86 16:13 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: define
To: cth%indiana.csnet@CSNET-RELAY.ARPA, rrrs-authors@MIT-MC.ARPA
In-Reply-To: The message of 27 May 86 13:20-EDT from Chris Haynes <cth%indiana.csnet@CSNET-RELAY.ARPA>
Message-ID: <"860529161305.5.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>

I didn't want to make any changes to the report as fundamental as this.
A change to DEFINE also seems infeasible given how constroversial the
topic is and always has been.  I am trying to sidestep controversies
right now, so that I can get something done.  Maybe in next year's
revision (??) we can address this question.

As we agreed at Brandeis, few of us wholeheartedly like internal
definitions, but they should be described ("nonessentially") because
S&ICP uses them.  This was a difficult compromise for us to arrive at,
and I think it would be much too painful at this point to retract it.
And now we have another reason to leave them in, which is compatibility
with the RRRS.

T originally had the semantics that you prefer for DEFINE (although
definitions aren't "globally" effective, they're scoped to the innermost
lexical contour which is willing to accept it).  Many users found it to
be a very nice feature, for the same reasons you do.  However, I have
recommended to the current T implementors that they remove the feature,
for several reasons:
  (a) It makes it more difficult for humans & programs to scan a file
      to find its definitions.
  (b) It's not always obvious which environment it is intended the
      definitions go in; like MIT Scheme, T has no notion of "top level."
  (c) It really confuses anyone who has ever seen S&ICP or MIT Scheme.
The old meaning will be retained in T, probably under some other name
(or anonymously, since T has anonymous special form types).  Kent and
others still stand by the old meaning.

Here is how I think I would put the functionality that "global define"
provides into a language like Scheme.  (A better language than Scheme
might do it better.)  Invent a special form (or macro) called something
like EXPORT or PROVIDE or MODULE which works as follows:

  (provide <var1> <var2> ...)

is equivalent to

  (lambda (<temp>)
    (case <temp>
      ((<var1>) <var1>)
      ((<var2>) <var2>)
      ...
      (else <error>)))

where <temp> is a variable different from <var1>, <var2>, ....

Then instead of

  (let ((state ...))
    (define-global reader ...)
    (define-global writer ...)
    ...)
  
you can write

  (define i/o-system
    (letrec ((state ...)
	     (reader ...)
	     (writer ...)
	     ...)
      (provide reader writer ...)))
  
  (define reader (i/o-system 'reader))
  (define writer (i/o-system 'writer))
  ...

The PROVIDE special form would be useful for many other applications as
well (e.g. object-oriented programming).

If this is too verbose for you, I think other kinds of macros could
almost as easily be designed which like the above raise no new semantic
questions.


- Jonathan

∂29-May-86  1438	NET-ORIGIN@MC.LCS.MIT.EDU 	schedule
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86  14:38:38 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 MAY 86  17:35:14 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 29 MAY 86  14:37:56 EDT
Date: Thu, 29 May 86 14:36 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: schedule
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <"860529143648.3.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>

Thanks to everyone who has read the draft report so carefully.  But
don't stop -- keep those cards and letters coming.  I called Wexelblat
about the production schedule for August and September SIGPLAN.  He said
he has to have it in his hands by June 13 (needs a page count sooner) if
it's to go into the August issue (which gets mailed out the first week
of August).  So this gives us a little more time.  However: the August
issue is getting to be pretty full; if we think it's urgent that it be
published, it's possible to get it in, but he would prefer if it waited
for the September issue.  I told him that some of the coauthors were
ancy to get the thing published and that I'd ask them what they thought.
Note that it won't get out to people before the Lisp conference in any
case.

I'm inclined to try to push and get it into the August issue, but if
people think we should spend more time arguing about things (I had no
idea so much controversy would arise at this late date), then we can
wait.

Jonathan

∂29-May-86  1450	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	define    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86  14:48:07 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 17:39:12 EDT
Received: from ti-csl by csnet-relay.csnet id aa00976; 29 May 86 13:21 EDT
Received: by tilde id AA23409; Thu, 29 May 86 11:09:54 cdt
Date: Thu 29 May 86 10:35:51-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: define
To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
Message-Id: <12210575742.48.BARTLEY@CSC60>

There is clearly no chance of a consensus on the meaning of an
internal DEFINE.  It seems fair to let the current draft go through
without changes from the previous one, since that was the
understanding at Brandeis.

The only viable solutions for the future are to remove internal
DEFINEs entirely (as Guy suggests) or to persuade the Indiana folk to
choose a new name.  (I thought `DEFINE!' was appropriate--whatever
happened to it?)

I prefer the second option.  Now that Scheme systems are being broadly
distributed, it is important for us to show a united front.  I would
understand a user's anger if he could not find compatible
implementations for his range of machines.

I understand IU's feelings, but I think a compromise with DEFINE! or
DEF or whatever is in the same spirit as all of us have solved similar
inconsistencies in the past.

Regards,
David Bartley
-------


∂29-May-86  1454	@MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA 	R3RS draft -- procedural
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86  14:54:17 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 17:40:14 EDT
Received: from northeastern by csnet-relay.csnet id a001585; 29 May 86 14:20 EDT
Date:     Thu, 29 May 86 10:32 EST
From:     MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>
To:       rrrs-authors@MC.LCS.MIT.EDU
Subject:  R3RS draft -- procedural

I have been looking at the draft of the R3RS which was distributed (dated 22 
May).  There are certainly a number of issues (some serious) which need to be 
resolved.  In addition, there are many places in the report (marked by open 
brackets) which have not yet been filled in, and where the completion is 
substantive, rather than presentational.

In view of this situation, I think it would be a serious mistake to "mail it 
to SIGPLAN June 1 come hell or high water".  I think those of us whose names 
will appear as authors of the report deserve to see a CLEAN draft before it is 
submitted.  The document is too important not to get it right.

I will send out my other comments in some other messages.

Mitch Wand

∂29-May-86  1545	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	R3RS draft -- procedural 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86  15:44:21 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 MAY 86  18:42:11 EDT
Date: Thu, 29 May 86 18:42:02 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  R3RS draft -- procedural
To: WAND%northeastern.edu@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 29 May 86 10:32 EST from MITCHELL WAND <WAND%northeastern.edu at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].48143.860529.JAR>

    Date: Thu, 29 May 86 10:32 EST
    From: MITCHELL WAND <WAND%northeastern.edu at CSNET-RELAY.ARPA>

    In view of this situation, I think it would be a serious mistake to "mail it 
    to SIGPLAN June 1 come hell or high water".  I think those of us whose names 
    will appear as authors of the report deserve to see a CLEAN draft before it is 
    submitted.  The document is too important not to get it right.

OK.

∂29-May-86  1610	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	response to new draft report (long)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86  16:10:17 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 16:06:56 EDT
Received: from ti-csl by csnet-relay.csnet id aa00186; 29 May 86 11:51 EDT
Received: by tilde id AA21997; Thu, 29 May 86 10:35:56 cdt
Date: Thu 29 May 86 10:19:27-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: response to new draft report (long)
To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA, JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA
Message-Id: <12210572757.48.BARTLEY@CSC60>

Here are my (hasty) comments on the new draft Report.

COMMENTS ON THE TEXT OF THE DOCUMENT:

[page 1]

My name is "David Bartley", but "D.H.Bartley" is better than "D.Bartley".

Why use zero-origin indexing for section numbers?

[page 2]

Use italics and capitalization for consistency in "revised report
[29]" in 2nd paragraph of Background.

The term "coalescing" in the 2nd-to-last paragraph is not defined
anywhere.

[page 4]

Remove "will" from "Italicized names will stand for..."

Pluralize "argument" in "the append procedure is being passed zero or
more list argument."

Add "be" in "this report explicitly does not specify what value should
[be] returned." at end of 0.2.2.

Change "Upper and lower case letters are never distinguished..." in 1
to something like "Upper and lower case forms of a letter are never
distinguished...".  Surely `A' is distinct from `b'.

Are #t and #f considered identifiers?

[page 5]

In 1st paragraph of 1.1: "Whitespace may occur..., but not within a
token."  Is a string containing a space a token?  The character `#\ '?

Typo: change `occuring' to `occurring'.

The statement "Backslash isn't used by Scheme except within string
constants" is awkward and negative.

Remove "are not used in Scheme right now but" from "... curly braces
are not used in Scheme right now but are reserved...".

Change "Like Algol or Pascal" to "Like Algol and Pascal".

[page 6]

In 2.1, the words "most values count as true, but a few--notably #f--
count as false" should be tightened up, since section 5.0 on page 13
makes it clear that only #f and the empty list count as false IN
CONDITIONAL EXPRESSIONS.  (Is "in conditional expressions" a
qualifier???)

[page 7]

Fix "see section refdefine" in 3.0.2.

Is 3.0.2 a good place to take note that () is not a good procedure call?

What is meant by "here we will ASSUME that <body> is simply a sequence
of one or more expressions" in 3.0.3?

[page 8]

Please change the descriptions of COND and CASE to be what they were
in the RRRS (modulo the small changes we seem to have consensus on).

I see no reason to get carried away with describing the permissible
types for <datum> in a CASE key list.  Just define CASE as using MEMV
(or EQV?) and let the implications hang out!

[page 10]

The first LET* example at the top left of the page is confusing, since
the first <binding> is decomposed into <variable> and <init> and the
others are not.

At the bottom of the first column, change the second instances of
<variable1> and <init1> to have subscript 2.

The words "... are variables which do not occur in the original LETREC
expression..." are confusing.  Would a new binding of the identifier
(or is it variable) <temp1> be an occurrence of <temp1>?  Similar
wording appears elsewhere in the document (e.g. with DO).

[page 11]

Specify that <name> in named LET must be an identifier (or is it
"variable").

[page 12]

Section 3.1.4: The wording "(for example, by a call to the FORCE
procedure)" begs for elaboration.  I think it makes sense to postpone
most of the discussion to page 27ff, as JAR does, so let's use a
"white lie" here and mention only FORCE as a way to collect on a
promise.  All other ways are extensions.

[page 13]

Change the last line of 4.1.0 from "Global definitions are essential;
all Scheme implementations must support them." to something like "This
semantics for top level definitions is essential."  What does "global
definition" mean?  The clause after the ";" is redundant.

I feel uncomfortable about using the term "lambda body" to include the
"body" of a LET or DEFINE expression, as is done in 4.2.

Why not retitle section 5 to be something like "Standard Procedures"
instead of "Initial Environment"?  The text makes it clear that these
procedures are the standard bindings of variables in the initial
environment, so it doesn't have to be emphasized in the title.  A
person looking at the table of contents on page 1 is likely to be
confused.

[page 14]

How about adding (EQ? NIL 'NIL) ==> #F as another example at the end
of 5.0 to hammer the point home?

Add "in the same order" at the end of "Two procedures are
operationally equivalent iff ... they return the same value and
perform the same side-effects."  (Or is that implied by `having the
same side-effects'?)

The wording "it will always err on the conservative side" seems to say
that EQV? tries to do the "right" "wrong thing"!

[page 15]

Change "Objects of distinct types WILL NEVER BE operationally
        equivalent, BUT FALSE and the empty list are permitted to be 
	identical..."

 to    "Objects of distinct types ARE NEVER operationally equivalent, 
	EXCEPT THAT #F and the empty list are permitted to be 
	identical...".

The second sentence of the description of EQUAL? should say that EQV?
is used for all objects except pairs, vectors, and strings.

[page 16]

Change "same" to "equivalent" in the comparison of (a b c d e) and its
dotted form.

[page 17]

APPEND! always side-effects all but its last argument.

[page 18]

Change "(in the sense of EQV? and EQ?)" to "(in the sense of EQ?)"  or
"(in the sense of EQV?)".  (Why mention both?)

What is meant by "returned" in the second and third sentences of the
description of SYMBOL->STRING?  How about "created"?

[page 19]

The previous Report used all caps for the words NUMBER, COMPLEX, ...,
for EXACT and INEXACT, and [page 23ff] INT, RAT, FIX, FLO, ... .  I
think that is less confusing than using the same typeface used for
Scheme identifiers.

[page 20]

Change the title of 5.4.2 from "Syntax" to something like "Number syntax".

Rephrase "to make all user populations happy".  >I'm< not happy with
having both forms (e.g., both = and =?) and I'd settle for EITHER ONE!

[page 25]

JAR has omitted an important paragraph in the previous Report's
discussion of strings.  The sixth paragraph on page 51 of the RRRS,
beginning "In phrases such as...", clarified in one place how
substring START and END work.  The descriptions of SUBSTRING (etc)
don't make this clear at all.

[page 26]

If we only have SUBSTRING-MOVE-RIGHT! to support text editors, let's
flush it!  This is only the tip of the iceberg when it comes to handy
little utility functions for building editors.

[page 27]

The dual use of VECTOR in the example starting (LET ((VECTOR (VECTOR...
is confusing.

For consistency, change ELTS in LIST->VECTOR to LIST.

[page 28]

Change "they" to "to" in "but they illustrate the property that the
value of a promise is computed at most once."

The second "bullet" at the top of the second column is not an
extension but an implementation issue (I think).

[page 29]

Restore the mention of the alternate name CALL/CC at the end of the
rationale for CALL-WITH-CURRENT-CONTINUATION.

[page 39ff]

Add index entries for `identifier' and `variable'.

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

[Following are my responses to JAR's specific questions on language and
presentation.  His question is left adjusted, my response is preceded
by ` ******* '.]  I've omitted some questions/proposals I agree with
or have no comment on.

Questions on LANGUAGE

I left CASE as is, using EQV? as the comparison, and I explicitly stated
that the object ought to be boolean, character, number, or symbol.  But
shouldn't it allow empty lists, vectors, and strings, too?

 ******* Define it in terms of EQV? and define (EQV? '() '()) ==> #T.
 ******* This is consistent with Common Lisp's CASE, which uses EQL.

May structure be shared in cases like (APPEND '(A B) '()) , or should APPEND
be Common Lisp compatible?  [Bartley says sharing would be a gratuitous
incompatibility with CL, I'm invlined to agree.]

 ******* Don't share structure with any argument but the last.

Should APPEND and APPEND! explicitly allow any object as last argument
(CL compatible)?

 ******* Yes.

Should APPEND! disallow () as other than last argument?

 ******* No.

Can we specify that DISPLAY of a character does the same thing as
WRITE-CHAR?

 ******* Yes.

What should be said, if anything, about the desirability and/or legality
of EQUAL? failing to terminate?  Rozas thinks an implementation with
this property is in error.

 ******* Leave it as it is.  It is `an error' not to terminate.

In light of the vagaries of CALL-WITH-xxPUT-FILE, perhaps it
would be a good idea to explicitly state that closing a closed port
should be a no-op instead of an error.

 ******* Yes.

-----

Questions on PRESENTATION

Should the various examples which use DEFINE be changed to use the
(define (foo ...) ...)  syntax instead of (define foo (lambda ...))?
Several people have told me that all those LAMBDA's could unnecessarily
intimidate SIGPLAN readers.

 ******* LAMBDA is what it's all about; but I don't really care.

There are two places (in descriptions of let* and letrec) where it is
necessary to create a lambda body in a context (such as the tail of a
BEGIN) where there isn't one already.  What is the cleanest way to do
this?  Is (let () ...) ok, or would ((lambda () ...)) or something else
be better?

 ******* Use (LET () ...).

Should the complete presentation of FORCE appear up front with DELAY, or
delayed until the place where the entry for FORCE appears?

 ******* It's OK where it is, but see my comments above.

-----

Notes on LANGUAGE

The selectors in a CASE expression must be distinct.

 ******* OK.

I have left CASE and COND syntax as in RRRS: there must be at least one
clause, but it may be an ELSE clause.

 ******* Yes--I don't like the rewrite in the new draft.

BOOLEAN? is essential.

 ******* I suppose so.

No agreement on COND or BEGIN.  I have left them as in RRRS.
[To do: fix the BNF to agree!]

 ******* Yes, but keep `test' instead of `guard'.

The RRRS explicitly allows internal definitions in the body of a LETREC.
They are scoped to the body only, not to the entire expression.  I can
flush this "feature" if a movement arises to do so; it seems sufficient
to me to permit only expressions (not definitions) in the body.

 ******* Allow them.

The list to which the rest argument gets bound must be newly allocated.

 ******* Yes.  Common Lisp screwed this up.

There was strong sentiment both for removing REC and for removing
NAMED-LAMBDA.  However, the sentiment was not unanimous.  I don't
understand why it should have matterred so much, since neither is an
essential feature.  If these are present, shouldn't everyone's favorite
features be present too?  ... Supporters of REC included Kent Dybvig and
Dan Friedman.  Supporters of NAMED-LAMBDA included Jim Miller and Henry
Wu.  In addition, Bill Rozas insisted that if REC stayed, then
NAMED-LAMBDA must stay too, but he was willing to see both go.

 ******* Keep them both.

APPEND! necessarily clobbers its arguments (other than the last and
empty ones).

 ******* Yes.  It's meaningless otherwise.

Many people wanted the number predicates pruned (i.e. choose between <
and <?).  No agreement here, so both stay.

 ******* I still can't understand why we can't get agreement, but
 ******* having both forms is OK until we do.  I'll live with either form.

The case sensitivity issue was a very sensitive one (so to speak).  I
did not change the report's stance of symbol case insensitivity.

 ******* Let's remain case-insensitive.

-----

Notes on PRESENTATION

 ******* I agree with (or don't care about) the rest of the issues.

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

BTW, I generally agree with Will's answers to KMP's questions.

Regards,
David Bartley
-------


∂29-May-86  1610	@MC.LCS.MIT.EDU,@CSNET-RELAY.ARPA,@boethius.think.com:gls@AQUINAS.THINK.COM 	hash-consing 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86  16:10:42 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 17:40:28 EDT
Received: from [30732002700] by CSNET-RELAY.ARPA id a003087; 29 May 86 16:54 EDT
Received: from BOETHIUS.THINK.COM by Godot.Think.COM; Thu, 29 May 86 16:50:11 edt
Date: Thu, 29 May 86 16:50 EDT
From: Guy Steele <gls@GODOT.THINK.COM>
Subject: hash-consing
To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA, 
    RRRS-Authors%mit-mc@CSNET-RELAY.ARPA
Cc: gls@AQUINAS.THINK.COM
In-Reply-To: <12210304495.60.BARTLEY@CSC60>
Message-Id: <860529165056.1.GLS@BOETHIUS.THINK.COM>

Dr. Eiichi Goto has done the greatest amount of work on hash-consing;
I think he may have invented the idea.  See the bibliography of the
paper by Goto et al. in the 1982 Lisp conference.
--Guy


∂29-May-86  1706	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: global definitions    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 May 86  17:05:52 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 May 86 18:47:48 EDT
Received: from tektronix by csnet-relay.csnet id a003857; 29 May 86 18:45 EDT
Received: by tektronix.TEK (5.31/6.12)
	id AA25806; Thu, 29 May 86 15:24:54 PDT
Received: by tekchips (5.31/5.14)
	id AA13361; Thu, 29 May 86 15:29:04 PDT
Message-Id: <8605292229.AA13361@tekchips>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: willc%tekchips.tektronix.csnet@CSNET-RELAY.ARPA
Subject: Re: global definitions
Date: 29 May 86 15:29:02 PDT (Thu)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

Though I spent time in Indiana, I must join with JINX and Andy in
protest against the very idea of global definitions.  If we must
have global definitions, I propose that the syntax be

    (SETF (SYMBOL-FUNCTION 'FOO) ...)

so as to avoid gratuitous differences between Scheme and Common Lisp.

As prelude to more serious comments, let me summarize the status quo:

INCREMENTAL DEFINE:  Not in the report, but appears in S&ICP.  Supported
only by MIT Scheme, though T has something similar.

INTERNAL DEFINE:  Optional in the report, pervasive in S&ICP.  Alternative
syntax for LETREC.  Supported by MIT Scheme, PC Scheme, and MacScheme.

TOP-LEVEL DEFINE:  Essential in the report.  It is up to the programming
environment whether top-level definitions are implemented as global
bindings, incremental bindings, or assignments; it makes very little
semantic difference.  Supported by everyone.

I don't want to give in to Guy's suggestion that internal definitions be
dropped entirely because it would return us to the days when we couldn't
read each other's code.  The implementations that support internal
definitions for compatibility with S&ICP would go on supporting them,
while people using Chez Scheme and Scheme-84 would write syntactically
identical code that does something completely different.  If everyone
could agree not to use DEFINE except at top level I might agree with Guy,
but that just isn't going to happen.  (For instance, the idea of dropping
internal DEFINE wouldn't even have come up if the people at Indiana
weren't so insistent on using the word DEFINE at places other than top
level.)

Though I once programmed in the Indiana style, I have found it easy to
switch to the new idiom:

    (define foo)
    (define bar)

    (let (<local state>)
      (set! foo ...)
      (set! bar ...))

I am partly in the dark because I have not yet received Chris Haynes's
message, but I suspect that folks at Indiana have not really given the
above idiom a chance because the one message I have received says only
that both "define!" and "global-define" were tried.

In short, I'm not a fan of the internal definition syntax, but I vote in
favor of keeping it in the report so as to prevent the syntax from being
used with two incompatible semantics.

Peace, Will

∂30-May-86  1432	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	definitions; APPEND!; etc 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 May 86  14:31:48 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 May 86 17:30:31 EDT
Received: from tektronix by csnet-relay.csnet id ac00463; 30 May 86 17:19 EDT
Received: by tektronix.TEK (5.31/6.12)
	id AA16726; Fri, 30 May 86 12:04:15 PDT
Received: by tekchips (5.31/5.14)
	id AA21283; Fri, 30 May 86 12:08:30 PDT
Message-Id: <8605301908.AA21283@tekchips>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: jar@MC.LCS.MIT.EDU
Subject: definitions; APPEND!; etc
Date: 30 May 86 12:08:29 PDT (Fri)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

Since the report won't appear in SIGPLAN Notices until after the Lisp
conference, I too favor waiting another month.

----------------------------------------------------------------
At Brandeis we agreed that (BEGIN (DEFINE ...) (DEFINE ...)) would be
flattened when it appeared at the beginning of a lambda body, but I
forgot to mention that in the RRRS.  It seems simplest to extend that
flattening to apply to the top level as well by changing the formal
syntax of <definition>  to be

    <definition>  -->  (define <variable> <expression>)
                    |  (define (<pattern> <formalz>) <body>)
                    |  (begin <definition>+)

This still rules out things like

    (begin (define up)
           (define down)
           (let ((n 0))
             (set! up (lambda () (set! n (1+ n)) n))
	     (set! down (lambda () (set! n (-1+ n)) n))))

After writing the new syntax for <program> that would be needed
to allow this, I decided it isn't worth it.

----------------------------------------------------------------
I prefer dropping both NAMED-LAMBDA and REC to leaving them both
in.

----------------------------------------------------------------
I have a few remarks to add to some of David Bartley's comments.

>Add "in the same order" at the end of "Two procedures are
>operationally equivalent iff ... they return the same value and
>perform the same side-effects."  (Or is that implied by `having the
>same side-effects'?)

There is still considerable research directed toward formulating
a satisfactory notion of operational equivalence for procedures
with side effects in the presence of concurrency, or even in the
presence of asynchronous interrupts.  To see that the definition
on page 14 is inadequate, consider that

    (lambda (x) (set! x (1+ (1+ x))) x)
and
    (lambda (x) (set! x (1+ x)) (set! x (1+ x)) x)

are operationally equivalent but

    (lambda (y) (set! x (1+ (1+ y))) x)
and
    (lambda (y) (set! x (1+ y)) (set! x (1+ x)) x)

are not.


>APPEND! always side-effects all but its last argument.

No, APPEND! should not be required to perform side effects.  This is not
as silly as it may sound.  In an implementation using the Hewitt-Lieberman
gc algorithm, for example, side effects to sufficiently old structures are
likely to be more expensive than consing.  APPEND! should be free to decide
for itself which technique is fastest.

I would feel differently if APPEND! returned an unspecified value, as
does VECTOR-SET!.


>Rephrase "to make all user populations happy".  >I'm< not happy with
>having both forms (e.g., both = and =?) and I'd settle for EITHER ONE!

I have been one of the main holdouts here, but I too am now willing to
settle for either one.


>If we only have SUBSTRING-MOVE-RIGHT! to support text editors, let's
>flush it!  This is only the tip of the iceberg when it comes to handy
>little utility functions for building editors.

I agree.  I think we should write other documents, however, to describe
the portable Scheme libraries that people have written, and we should
work on improving portability and availability.

peace, Will

∂30-May-86  1650	@MC.LCS.MIT.EDU:OXLEY%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: Embedded DEFINE forms  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 May 86  16:49:47 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 May 86 19:48:45 EDT
Received: from ti-csl by csnet-relay.csnet id ab01528; 30 May 86 19:37 EDT
Received: by tilde id AA15347; Fri, 30 May 86 17:50:20 cdt
Date: Fri 30 May 86 17:42:25-CDT
From: Don Oxley <OXLEY%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: Embedded DEFINE forms
To: gls%Think.COM@CSNET-RELAY.ARPA, rrrs-authors%mc@CSNET-RELAY.ARPA
In-Reply-To: <8605290514.AA08588@Godot.Think.COM>
Message-Id: <12210915540.62.OXLEY@CSC60>

I have generally avoided getting into these discussions as David has
represented our viewpoints very effectively.  However, I am becoming
concerned about what looks like a potentially destructive argument over
DEFINE.  

It seems to me that it is unlikely that very many users outside of the
aficionados at MIT and IU are likely to use embedded DEFINE at all -
except as they may have seen it in S&ICP.  I would hate to see
"outsiders" back away from using SCHEME because they see a religious war
going on within the community. 

My first suggestion is to leave it as we decided at Brandeis - based on
the notion that we had agreement (even if grudging) and we do not have
an agreement on a change.  Possibly better is Guy's suggestion to
leave it undefined (which I think is roughly equivalent to letting the
dominant dialect win).
 
I would be very hesitant for us to have to change PC Scheme in an
incompatible direction.  I'll hazard a guess that PCS is or is close to
becoming the most widely used Scheme today, so we are trying to be
somewhat careful about compatibility (although as I said, I doubt if
this will affect very many users).  Either leaving the position as it is
or making it undefined would leave PCS alone.  

Please, let's not let this become a divisive issue that hurts the spread
of Scheme to those who don't care about so technical an issue and
merely what to know what the langauge does and does not do.

        --Don
-------


∂30-May-86  1703	@MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA 	procedure (Tnx)    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 May 86  16:58:49 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 May 86 19:57:43 EDT
Received: from northeastern by csnet-relay.csnet id ac01577; 30 May 86 19:48 EDT
Date:     Fri, 30 May 86 10:04 EST
From:     MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>
To:       rrrs-authors@MC.LCS.MIT.EDU
Subject:  procedure (Tnx)

Thanks to Jonathan for so promptly accepting my suggestion that we delay
publication until these issues are resolved.

-- Mitch

∂30-May-86  1703	@MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA 	define -- a modest proposal  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 May 86  17:03:39 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 May 86 19:59:54 EDT
Received: from northeastern by csnet-relay.csnet id ae01577; 30 May 86 19:49 EDT
Date:     Fri, 30 May 86 10:40 EST
From:     MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>
To:       rrrs-authors@MC.LCS.MIT.EDU
Subject:  define -- a modest proposal

I think it is clear that we do not have a consensus on the semantics of 
internal DEFINE.  My understanding of the compromise reached at Brandeis was 
that lexically nested DEFINE would retain the MIT semantics, whereas
the IU semantics could be obtained by using DEFINE! .   The current report 
does not appear to be compatible with that compromise, because it would appear 
necessary to do a

(define foo 'hunoz)

at top-level before one can legally do a set! on foo from an interior scope.

Analyzing this situation, there are two operations involved in a define:

1.  Binding the identifier to some location.
2.  Storing a value in that location.  

The latter operation is clearly doable by set!, so the only issue is #1.
The MIT semantics has DEFINE performing #1 on the current scope.  The 
advantage of this proposal is that it is uniform on both "top-level" and 
interior scopes.  The disadvantage is that it essentially creates a new scope 
(region) in the program which is not delimited by parentheses.  [Perhaps the 
grammar could be fixed to recognize this new, non-list-structure phrase?].
This is an unpleasantness at the top level which I do not think we understand.

[Perhaps we should separate DEFINE into two procedures:

(make-local-variable 'foo)
(set! foo value)

[shades of GNU Emacs-Lisp!!]]

[Another, separate, argument against including internal define as an optional
feature in the report is that, unlike the other optional features in the 
report, it requires pervasive modifications in many other sections of the 
report].

Nevertheless, I am not yet arguing for elimination of internal defines from 
the report, in keeping with the compromise reached at Brandeis.

What I will argue for is the following:

An implementation may have a top level (initial, whatever) environment in 
which every possible identifier is bound (though only some are initialized).

This would allow programs in that implementation to do a set! on a global 
variable (excuse me, a variable in the current top-level environment) from an 
internal scope without having to explicitly bind the variable in the initial 
scope.  It would also allow MIT-style define to proceed, as it does not 
require the existence of a distinguished global environment.

I think this proposal retains the spirit of the Brandeis agreement on this 
issue.

Mitchell Wand

∂31-May-86  0108	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	define -- a modest proposal  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 31 May 86  01:08:38 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAY 86  00:34:03 EDT
Date: 31 May 1986  00:32 EDT (Sat)
Message-ID: <JINX.12210979336.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>
Cc:   rrrs-authors@MC.LCS.MIT.EDU
Subject: define -- a modest proposal
In-reply-to: Msg of 30 May 1986  11:40-EDT from MITCHELL WAND <WAND%northeastern.edu at CSNET-RELAY.ARPA>

I may have misunderstood your message, but I'm afraid you are still
confusing (local static) INTERNAL DEFINE with (dynamic, horrible
semantically) INCREMENTAL DEFINE.  They have nothing in common (except
sharing the keyword).

INTERNAL DEFINE does NOT create a new scope.  The scope is created by
the surrounding LAMBDA, LET, or LETREC expression, and is therefore
bounded by parentheses.

(let ()
  (define foo ...)
  (define bar ...)
  <some expression>)

should be exactly equivalent to

(letrec ((foo ...)
         (bar ...))
  <some expression>)

As a matter of fact, I originally implemented LETREC in MIT-Scheme
(and it is still implemented in this way in MIT CScheme, I believe),
by transforming the second expression into the first.

Thus, the (INTERNAL) DEFINEs do not establish the context.  The
context is established by LET.

Your proposal of separating DEFINE into

(make-local-variable 'foo)
(set! foo value)

seems to violate this semantics.  It appears to be advocating for
INCREMENTAL DEFINE, which is NOWHERE on the report.  Indeed, MIT
Scheme has a primitive procedure which implements INCREMENTAL DEFINE,
on top of which MAKE-LOCAL-VARIABLE could be implemented trivially,
but we are certainly not advocating for a feature we don't feel
comfortable with ourselves.

INTERNAL DEFINE is purely declarative, it does not involve ANY side
effects.  INCREMENTAL DEFINE, on the other hand, is mostly imperative,
and involves side effecting environments.

As far as I know (please correct me on this), INTERNAL DEFINE has no
semantic problems, its only problem is purely syntactic: it makes the
evaluator (compiler, syntaxer, code walker, whatever) harder to write
since it has to collect all the definitions which occur in a scope
before processing the expressions.  Since the report only allows 
definitions as the very first thing in a block (it's the only place
where they make sense), collecting them is trivial.

∂31-May-86  0331	NET-ORIGIN@MC.LCS.MIT.EDU 	wanted: teaching do's and dont's 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 31 May 86  03:31:21 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAY 86  06:25:28 EDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 23 Dec 85 15:20:57 EST
Received: from bostonu by csnet-relay.csnet id ae01055; 23 Dec 85 15:15 EST
Received: by bu-cs.ARPA (4.12/4.7)
	id AA22857; Mon, 23 Dec 85 14:41:29 est
Date: Mon, 23 Dec 85 14:41:29 est
From: Edward Sciore <sciore%bostonu.csnet@CSNET-RELAY.ARPA>
To: SCHEME@mit-mc.ARPA
Subject: wanted: teaching do's and dont's

I will be teaching from the "Structure and Interpretation..." book
spring semester. Students will be sophmores/juniors with at least 2
semesters of Pascal behind them. Does anybody know of things that I
should be wary of? How fast should I go in order to get through chapter 
4? Will their previous programming experience allow the students to 
handle the material more easily? Any tips people have discovered 
will be appreciated. Thanks.
				Ed Sciore
				Boston University CS Dept
				sciore@bostonu.CSNET


∂31-May-86  0539	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	wanted: teaching do's and dont's  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 31 May 86  05:38:57 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAY 86  08:34:33 EDT
Date: 31 May 1986  08:33 EDT (Sat)
Message-ID: <JINX.12211066871.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   Edward Sciore <sciore%bostonu.csnet@CSNET-RELAY.ARPA>
Cc:   SCHEME@MC.LCS.MIT.EDU
Subject: wanted: teaching do's and dont's
In-reply-to: Msg of 23 Dec 1985  14:41-EST from Edward Sciore <sciore%bostonu.csnet at CSNET-RELAY.ARPA>

Our experience at MIT is that it is often the case that students with
previous programming experience suffer MORE in the course than
students without such experience, since the latter are not biased.

In particular, students familiar with BASIC and FORTRAN (and probably
PASCAL) tend to have a hard time adapting to the functional style
encouraged by Scheme.  They view DEFINE as assignment, which it isn't,
and even if they get used to the functional style, when assignment
(SET!) is finally introduced, they often revert to the ugly imperative
style.  They sometimes have this crazy notion that imperative style is
more efficient.  Interestingly enough, code with side effects is often
LESS efficient in T and in MIT Scheme with the new compiler.

Although Pascal is, like Scheme, lexically scoped, students do not
have a really hard time accepting this, so I'm not sure it's a real
advantage.

Obvious potential stumbling blocks, beyond style:

Absence of VAR parameters, used sometimes to "return" multiple values in
Pascal.  This is usually done in Scheme (in dialects without multiple
values) in one of two ways: returning a data structure (list or
vector) with the appropriate contents, or passing an explicit
continuation with many parameters to the procedure that wants to
return multiple values, which will, instead of returning, invoke its
explicit continuation with the multiple "returned" values.

Absence of iteration constructs.  Standard Scheme has DO, but it is
not used in S&ICP, in fact, we did not even have it in MIT Scheme
until the report describing Standard Scheme came about.  Iteration has
to be achieved through syntactic recursion.  One of the reasons for
not having syntactic sugar in MIT Scheme (originally) was to emphasize
this point, and force students to deal with the issue.

Absence of explicit allocation.  Memory management in Scheme is
automatic, rather than manual.

Eventually, the fact that thanks to tail recursion and first class
procedures (and worse, cwcc, but this is not covered in S&ICP), Scheme
is a completely unstructured language (in the sense of "structured
programming").  Procedures (lambda expressions) are labels, and
application is GOTO, and any arbitrary control structure can be built
on top of this.

PS: There is a teacher's manual for S&ICP written by Juile Sussman.
It is very good.  It contains more examples, more problems, and a very
detailed description of where students go wrong in various places, and
what points need further emphasis.  I believe (HAL or GJS can correct
me here) that it can be obtained through McGraw Hill.

∂31-May-86  0738	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	sentiments   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 31 May 86  07:37:52 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 31 May 86 10:37:01 EDT
Received: from indiana by csnet-relay.csnet id aa06940; 31 May 86 10:36 EDT
Date: Fri, 30 May 86 15:34:53 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: sentiments
Cc: jar@MC.LCS.MIT.EDU

I believe I must explain to you why I am as upset about internal-define
as I am.  This report has been a long time in coming and as it approaches
its final form, it begins to look quite splendid.  So much so that I
believe that its potential for generating converts will be quite
substantial.  That was, in fact, one of its goals.  However, we Schemer's
have had the freedom for several years of writing code for papers and
books in just about any dialect we felt the audience could/would follow.
Scheme has been a fabulous tool for that purpose.  The simplicity of the
language and the elegance of its definition attracted us and I am sure
many of you towards it.  How simple was it?  In the presence of macro
expansion, we needed the following 4 special forms:  "quote", "lambda",
"if", and "set!".  Many implementations began to exist on micros.  One
of my students, Mark Meyer, implemented an entire Scheme system including
engines, macros, a compiler, the run time support in 5k bytes on a
IBM PC.  He did this as an undergraduate in the 5 weeks following my
undergraduate programming languages course.  Now it was the case that
"set!" assigned to the closest lexical "rib" and we assumed that the
bottom rib had all known identifers assigned to either "unbound" or,
in the case of +, to some value.  This really was simple.  With this view,
define was merely an alias for set!.  However, define's value was its
first argument and set!'s value was its second argument.

This is how things were prior to the Brandeis meeting.  As I recall the
feeling at the Brandeis meeting most of us were willing to go along with
the idea of limiting the use of "define" internally to the semantics of
SI&CP.  This was in the interest of good feeling about not undermining
their book.  I hope everyone understands that I do not want to undermine
their book, although I would like to see them rewrite it without internal
defines.  However, when I went along with this view I had underestimated
how damaging this decision would be to the characterization of Scheme being
a simple language.  I was expecting a "comment" in the report that stated
that "use of define within the text of a program would be restricted to
the use as given in SI&CP."  Instead, the definition of "lambda" got changed.
Instead, begin must be added to the list of special forms.  Instead the
macro for "letrec" must be conscious of it by having the body be 
"(let () <body>)" where it should be <body>.  Instead define must be added to
the list of special forms.  Instead the semantics of "set!" are weakened
so that it is not possible to just get by with "set!" and ignore "define".
Instead we must do something "special" with "lambda", "named-lambda",
"let", "let*", and "letrec".

We have taken a rather elegant language and made it elitest.  I wanted
all of my students to be able to implement "Scheme" when they walked out
of my course, now that is no longer possible.  It was a great beauty of
Scheme that the four mentioned special forms along with identifiers and
application were the only syntax.  It was wonderful that a CPS interpreter
for Scheme was all that was necessary to come to grips with in order to
understand the run-time architecture of Scheme.  

My argument with internal-define is not that it is good or bad, but
that the subtlety of its definition is unnecessary with judicious use
of letrec and letrec should be a trivial macro.  What happened?

I have never liked internal defines.  I thought they were harmless
until I saw what havoc they introduced to the Report.  I am trying
desperately to convince everyone that we made a mistake and we should
do everything in our power before we go public on this Report to
wait until we impose internal defines on everyone.

					Dan


∂31-May-86  1608	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	sentiments    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 31 May 86  16:08:15 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 MAY 86  19:07:29 EDT
Date: Sat, 31 May 86 18:53:02 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject:  sentiments
To: dfried%indiana.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].923375.860531.JAR>

    Date: Fri, 30 May 86 15:34:53 est
    From: Dan Friedman
    Sent-by: Kent Dybvig

    ... define was merely an alias for set! ...
    This is how things were prior to the Brandeis meeting.

This is how things were AT INDIANA prior to the Brandeis meeting.  At
Yale and MIT they somewhat different (although not as different as you
suppose) and had been since at least 1981.  Your quest for elegance is
noble but please try not to equate your own version of Scheme with
Scheme.

    As I recall the feeling at the Brandeis meeting most of us were
    willing to go along with the idea of limiting the use of "define"
    internally to the semantics of SI&CP.  This was in the interest of
    good feeling about not undermining their book.  I hope everyone
    understands that I do not want to undermine their book, although I
    would like to see them rewrite it without internal defines.
    However, when I went along with this view I had underestimated how
    damaging this decision would be to the characterization of Scheme
    being a simple language.  I was expecting a "comment" in the report
    that stated that "use of define within the text of a program would
    be restricted to the use as given in SI&CP."  Instead, the
    definition of "lambda" got changed.  

I don't understand.  Is it really the case that S&ICP never ever uses
internal defines in the body of a lambda?  I'll check.  In any case, if
internal definitions exist at all, LAMBDA is the ONLY form that's
affected, after macro expansion.

    Instead, begin must be added to the list of special forms.  

Not true, and I'm don't understand why you think so.  Note that I
clearly put BEGIN in the "derived expression types" section.  I will
include the usual expansion of it in a future draft; I forgot to note
that this was on my list of things to do.

    Instead the macro for "letrec" must be conscious of it by having the
    body be "(let () <body>)" where it should be <body>.

I proposed flushing internal definitions in the body of a letrec for
exactly this reason.  But I don't see this as increasing the complexity
of LETREC significantly, and I was wrong to draw attention to it.  I'll
try to figure out how to make this smoother.

    Instead define must be added to the list of special forms.

What do you mean?  Definitions aren't even expressions!

    Instead the semantics of "set!" are weakened so that
    it is not possible to just get by with "set!" and ignore "define".

As has been explained innumerable times, there is no way to avoid this
and have a language which is at all coherent with T and MIT Scheme.
Note that in all programming languages of the Algol/Pascal/C variety it
is an error to assign to an undeclared variable.  That MIT Scheme and T
(and thus RRRS Scheme) also have this property is not coincidence.

    Instead we must do something "special" with "lambda",
    "named-lambda", "let", "let*", and "letrec".

Certainly the report is muddled, and I must accept the blame for some of
this muddle.  I introduced a lot of the nonsense you're complaining
about into this version of the report in a quest for accuracy.  I agree
with your complaint that internal definitions are intrusive, and I'll do
what I can to remedy the situation.

    We have taken a rather elegant language and made it elitest.

I don't understand this use of that term.

    I wanted all of my students to be able to implement "Scheme" when
    they walked out of my course, now that is no longer possible.

This is false.  Internal defines are not essential.  If by "Scheme" you
mean absolutely everything described in the report, I would expect that
internal definitions (which can be implemented with a very small amount
of code) would be the least of any implementor's worries.  What about
number I/O?

    It was a great beauty of
    Scheme that the four mentioned special forms along with identifiers and
    application were the only syntax.  It was wonderful that a CPS interpreter
    for Scheme was all that was necessary to come to grips with in order to
    understand the run-time architecture of Scheme.  

Why isn't this still true?

    My argument with internal-define is not that it is good or bad, but
    that the subtlety of its definition is unnecessary with judicious use
    of letrec and letrec should be a trivial macro.  What happened?

How do internal definitions make LETREC more complicated?  The (LET ()
...)  (which would otherwise be a (BEGIN ...)) is trivial compared to
the rest of what LETREC has to do, and doesn't even have to be there at
all if you're not implementing the full language.

    I have never liked internal defines.

Thanks for telling me, I hadn't figured this out.

    I thought they were harmless
    until I saw what havoc they introduced to the Report.  I am trying
    desperately to convince everyone that we made a mistake and we should
    do everything in our power before we go public on this Report to
    wait until we impose internal defines on everyone.

I'll do what I can to fix the presentation; I can at least certainly
make internal definitions less intrusive than they were in the RRRS.  I
hope that will be sufficient.  Personally, I wouldn't mind removing
internal definitions from the language, although special treatment of
definitions at top level of a file (which is another story altogether)
must stay.  If you can convince everyone, including Sussman and Abelson,
that internal definitions should be flushed, then I'll flush them.  If
you must persue this, I suggest you talk to Sussman on the telephone
about this; he isn't reachable by electronic mail until June 20, I
think.  I'll try to find his phone number at Princeton or HP or wherever
he is.

Why does this question arise at this moment?  I am angered by the
untimeliness of this debate.  Why didn't it come up when the idea of
printing the report in SIGPLAN was first mentioned?  This part of the
language hasn't changed.


Jonathan

∂31-May-86  2319	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	define -- a modest proposal  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 31 May 86  23:19:38 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 JUN 86  02:18:12 EDT
Date: Sun,  1 Jun 86 02:03:01 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject:  define -- a modest proposal
To: WAND%northeastern.edu@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].923455.860601.JAR>

    Date: Fri, 30 May 86 10:40 EST
    From: MITCHELL WAND <WAND%northeastern.edu at CSNET-RELAY.ARPA>

    I think it is clear that we do not have a consensus on the semantics
    of internal DEFINE.  

This isn't clear to me.  I thought we had always agreed that internal
definitions were just sugar for LETREC (see Will's message of 11 November
84, excerpted below).

			 My understanding of the compromise reached at
    Brandeis was that lexically nested DEFINE would retain the MIT
    semantics, whereas the IU semantics could be obtained by using
    DEFINE! .  The current report does not appear to be compatible with
    that compromise, because it would appear necessary to do a

    (define foo 'hunoz)

    at top-level before one can legally do a set! on foo from an interior scope.

At first I thought that you had misremembered, but I just went back to
the archives, and you are right.  However, DEFINE! was later flushed --
without any liberalization of SET! .  The discussion was obviously
incomplete (as you can tell by reading it), and we're completing it now.
Will did the right thing since he flushed features that not everyone
wanted, namely (a) DEFINE! and (b) an environment in which SET! could
cause unbound variables to become bound.  See the Appendix to this
message for the exchange.

I was moderately happy with how that turned out and implicitly assumed
that if people had serious troubles with the RRRS they would have spoken
up ages ago.  My attempts to clarify things have apparently drawn
attention to issues which have been peacefully asleep for over a year.

    Analyzing this situation, there are two operations involved in a define:

    1.  Binding the identifier to some location.
    2.  Storing a value in that location.  

    The latter operation is clearly doable by set!, so the only issue is #1.
    The MIT semantics has DEFINE performing #1 on the current scope.  The 
    advantage of this proposal is that it is uniform on both "top-level" and 
    interior scopes.  The disadvantage is that it essentially creates a new scope 
    (region) in the program which is not delimited by parentheses.

This is true, the region is only the <body> of the LET or whatever
expression, not the entire expression, so the region isn't delimited by
left and right parentheses.  The region of a definition at top level of
a file is similarly not delimited by parentheses, although for a
slightly different reason.  I wouldn't say the definition creates the
scope, I'd say that the scope is created by the expression in whose body
the definition appears.  But what is so unusual about this?  The region
of a binding created by LET is also not delimited by parentheses; it's
not the entire LET expression.

    [Perhaps the 
    grammar could be fixed to recognize this new, non-list-structure phrase?].

What change do you suggest?  Why don't <body> and <program> foot the
bill?  A <body> is exactly the region of the bindings specified by
internal definitions which begin it.  A <program> (which, I suppose, is
the concatenation of all the files comprising a running Scheme program,
or something like that) is the region of bindings created by top level
definitions.

    This is an unpleasantness at the top level which I do not think we
    understand.

I guess I'm losing track of what you're saying.  I agree that there is
much unpleasantness, but to which one are you referring?

In Algol 60 a <program> is a <block> or a <compound expression>, so
Algol 60 has the property you want, that regions are always fully
parenthesized (by BEGIN ... END).  I always rationalized Scheme's lack
of "outermost parentheses" by the fact that there would be no point in
having them if you would always have to write them -- they would be
redundant.  I imagine that those parentheses are there, just outside the
edge of my files, providing a region for my files' top level bindings to
live in.  (The T compiler actually puts the parentheses there, treating
a file boundary as a sort of a macro.)

The main unpleasantness I see is the syntactic oddity that a <program>
is a sequence of intermixed <expression>s and <definition>s (it's very
important that <definition>s aren't <expression>s!), whereas a <body> is
a sequence of <definition>s followed by a sequence of <expression>s.  I
think I suggested fixing this a while ago (whether to people at MIT or
to RRRS-Authors I don't remember), so that <program>s and <body>s could
have the same syntax and semantics (if internal definitions were
supported at all, that is), but this suggestion was not well received.
This change would make Scheme like Algol 68, which also allows one to
intersperse statements and declarations within a "series" (the region
("range") of a declaration includes previous statements and declarations
in its "series").  The other way to resolve the inconsistency is to be
like Algol 60 and require that all the definitions in a program go at
the top, before any statements (expressions), but somehow I don't think
people would buy that.

    [Perhaps we should separate DEFINE into two procedures:

    (make-local-variable 'foo)
    (set! foo value)

A reasonable idea.  In MIT Scheme, (make-local-variable 'foo) is written
(define foo).  (Or do you really mean a procedure?)  If people like this
feature (which causes the variable to become bound but unassigned, like
in LETREC) I'd be happy to see it go into the report.  It is bothersome
that one has to specify an initial value, and this seems as good a way
as any to avoid having to do so.

    [Another, separate, argument against including internal define as an
    optional feature in the report is that, unlike the other optional
    features in the report, it requires pervasive modifications in many
    other sections of the report].

I agree that the presentation is bad.  This is a real problem which, as
I said in my message to Dan, I think I can fix, by going back to
something closer to Will's approach, which was much less intrusive.  I
take full responsibility for having screwed this up.

    What I will argue for is the following:

    An implementation may have a top level (initial, whatever) environment in 
    which every possible identifier is bound (though only some are initialized).

    This would allow programs in that implementation to do a set! on a global 
    variable (excuse me, a variable in the current top-level environment) 

[Can you define "current"?]
									  from an 
    internal scope without having to explicitly bind the variable in the initial 
    scope.  It would also allow MIT-style define to proceed, as it does not 
    require the existence of a distinguished global environment.

    I think this proposal retains the spirit of the Brandeis agreement on this 
    issue.

If people generally think it's OK if this is documented as an optional
language feature (as was DEFINE! previously), I don't have too much
problem with putting it in the report, if it's accompanied by some
mention of the fact that some implementations have principled reasons
for not having this feature.  (Dan has complained to me, however, that
he doesn't want the report to contain advertisements for random features
of various dialects, so I wouldn't know quite how to do this.)  My main
complaint is that it would be nice to be able to support as many as
possible of the report's non-essential features in T and MIT Scheme, and
it would be a substantial amount of work to implement this particular
feature in T and MIT Scheme; causing assigned variables to become bound
in an appropriate contour involves a bothersome non-local code
transformation.

The MIT Scheme and T designers have worked hard to implement truly
block-structured languages which, like Algol, have no distinguished
top-level environments.  (Algol 68's "standard prelude" and its
mechanism of "particular-programs" is block structure to the max -- can
someone tell me what would correspond to the proposed SET! extension in
Algol 68?)  Legitimizing binding-from-a-distance (or environments in
which all variables are bound, which amounts to the same thing) in the
Scheme report is a threat to the pedagogical and engineering effort
we've put in.  Of course, de-legitimizing unprepared SET!'s is
apparently a threat to your investment.  I thought the compromise in the
RRRS was a good one considering how different our world views were.

With apologies to you and Dan for the angry tone & the abundance of
parenthetical remarks.  I'm tired.

Jonathan.


------

APPENDIX.  Historical record of the DEFINE! and SET! debate.

Clinger, 11 Nov 84, preliminary report on the workshop:
    (DEFINE id expr) allows top-level definitions of variables.  Its
    semantics at top level are similar to the semantics of
    (SET! id expr).  The difference is that if id is not already
    bound to a location, then the DEFINE form binds id before
    performing the assignment, whereas it would be a mistake to
    perform a SET! on an unbound identifier.

    Optionally, (DEFINE! id expr) is equivalent to (DEFINE id expr)
    when typed at the top level.  Within code, (DEFINE! id expr) is
    equivalent to (SET! id expr) unless id is unbound, in which case
    the DEFINE! form creates a new top level binding for id before
    performing the assignment.

    Optionally, DEFINE may be used for internal definitions as in MIT
    Scheme and in the book by Abelson and Sussman.  If allowed at
    all, internal definitions are permitted only in the bodies of
    LAMBDA, LET, LETREC, and similar binding constructs.  Furthermore
    they must precede the rest of the body.  With these restrictions,
    the semantics of internal definitions can be explained in terms
    of LETREC.  For example, ...

Pitman, 6 Dec 84:
    The term "top-level binding" is ... completely vague in DEFINE!'s
    definition.

Rees, 14 March 85:
    ... And incidentally, I don't remember the rationale for having both
    DEFINE! and DEFINE.  I understand why DEFINE shouldn't have hairy
    syntax, but what does DEFINE! give you that the stripped-down DEFINE
    doesn't?

Clinger, 18 March 85, "final" draft of report:
    (define! var expr)                                   special form
    
    If var is bound, then the define! form is equivalent to the 
    corresponding set!.  If var is unbound, however, define! binds 
    var in the global environment before performing the assignment.  

Haynes and Friedman, 27 Mar 85:
    DEFINE!  and DEFREC!  should go away.  (Yes, We were among those who
    wanted them originally, but they aren't worth it.) We're not fond of
    DEFINE either and wish it could go the same way, or at least be
    optional.

Bartley, 29 March 85:
    I'm willing to lose DEFINE! and DEFREC!, as Chris and Dan suggest.

Rozas, 27 March 85:
    How am I supposed to define things if both DEFINE! and DEFINE 
    go away?

Haynes, 29 March 85, answering Rozas:
    With SET!, provided one assumes that all identifiers are initially bound in
    the global environment, or that SET!  can extend the global environment.
    With the exception of MIT's Scheme, this is what existing systems do.  If MIT
    is unwilling to change this, then we are reluctantly stuck with DEFINE.

Hanson, 30 March 85, answering Haynes:    
    This is a terrible idea.  It seems that the ability to have many
    different environments in which to perform incremental definitions has
    been consistently overlooked by almost everyone except MIT Scheme and
    T.  Anyone who has ever tried to program a BIG system, and by that I
    mean something over 500-1000 pages of code, knows that this kind of
    packaging is **ESSENTIAL**!!  So please don't try to take this away.

Haynes, 31 March 85, answering Hanson:
    We grant the importance of such a facility, and are not trying to take it
    way; but there is no concensus on how to provide such a facility, so it
    is too soon to standardize on one.  (Similarly, syntactic extensions
    are **ESSENTIAL** to the kind of thing we do here; but it is also too soon
    to standardize on a syntactic extension mechanism.)

    We were simply debating whether SET! should be required to extend the
    global environment if its identifier is unbound (or equivalently, have
    everything bound in the global environment to begin with).  This would
    make DEFINE unessential, though it might still be optional.  It has
    nothing to do with multiple environments for incremental definition,
    except that MIT uses DEFINE for both purposes.

Hanson, 2 April 85, answering Haynes:
    What I wanted to say was: if SET! extends the "global" environment,
    then that environment has become special in that it is the ONLY
    environment that can be extended by interactive definition.  This
    would seem to preclude the existence of many such environments.
    DEFINE eliminates the problem, because it specifies, very precisely,
    the environment in which the name is bound.

Clinger, 20 April 85:
    define! and defrec! will be flushed altogether.



Note: no one at Indiana replied to Hanson's message, even though it
isn't conclusive.  (I don't even think it's true; there could be
multiple "global" environments, and SET!'s could be associated with them
lexically.)  Did they assume that SET! would be changed?

∂01-Jun-86  0815	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	define -- a modest proposal  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Jun 86  08:14:48 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 JUN 86  11:13:41 EDT
Date: 1 Jun 1986  11:10 EDT (Sun)
Message-ID: <JINX.12211357535.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Cc:   rrrs-authors@MC.LCS.MIT.EDU, WAND%northeastern.edu@CSNET-RELAY.ARPA
Subject: define -- a modest proposal
In-reply-to: Msg of 1 Jun 1986  02:03-EDT from Jonathan A Rees <JAR%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>

    In Algol 60 a <program> is a <block> or a <compound expression>, so
    Algol 60 has the property you want, that regions are always fully
    parenthesized (by BEGIN ... END).  I always rationalized Scheme's lack
    of "outermost parentheses" by the fact that there would be no point in
    having them if you would always have to write them -- they would be
    redundant.  I imagine that those parentheses are there, just outside the
    edge of my files, providing a region for my files' top level bindings to
    live in.  (The T compiler actually puts the parentheses there, treating
    a file boundary as a sort of a macro.)

In MIT Scheme, the syntaxer (a program which translates s-expressions
into Scode, shared by the interpreter and the compiler) "puts" the
parantheses there by building an Scode object called an open-block
around the "top level".

    The main unpleasantness I see is the syntactic oddity that a <program>
    is a sequence of intermixed <expression>s and <definition>s (it's very
    important that <definition>s aren't <expression>s!), whereas a <body> is
    a sequence of <definition>s followed by a sequence of <expression>s.  I
    think I suggested fixing this a while ago (whether to people at MIT or
    to RRRS-Authors I don't remember), so that <program>s and <body>s could
    have the same syntax and semantics (if internal definitions were
    supported at all, that is), but this suggestion was not well received.
    This change would make Scheme like Algol 68, which also allows one to
    intersperse statements and declarations within a "series" (the region
    ("range") of a declaration includes previous statements and declarations
    in its "series").  The other way to resolve the inconsistency is to be
    like Algol 60 and require that all the definitions in a program go at
    the top, before any statements (expressions), but somehow I don't think
    people would buy that.

I object to mixing internal definitions and expressions.  I also
object to mixing top level definitions and expressions although I
admit to being guilty of laziness and occasionally doing the latter.
I never (as far as I can remember) mix them internally, and try to
avoid mixing top level ones also.  I would not mind (and might even
applaud) a decision forcing top-level definitions to come first, which
would make the intenal and external cases more symmetric.

	[Perhaps we should separate DEFINE into two procedures:

	(make-local-variable 'foo)
	(set! foo value)

    A reasonable idea.  In MIT Scheme, (make-local-variable 'foo) is written
    (define foo).  (Or do you really mean a procedure?)  If people like this
    feature (which causes the variable to become bound but unassigned, like
    in LETREC) I'd be happy to see it go into the report.  It is bothersome
    that one has to specify an initial value, and this seems as good a way
    as any to avoid having to do so.

It is completely unacceptable if it is a procedure (which was my
understanding given the wording and the QUOTE).  This would imply
runtime definition (INCREMENTAL DEFINE), rather than static definition
(INTERNAL DEFINE).  It also has the problem that if it is a procedure,
it needs the environment where the definition must occur as an
argument.  Procedures cannot pick it up at run time.

If it is a special form, the QUOTE is not needed (nor the environment,
which is available at evaluation time), and it could be made static
(as I would expect everyone to want), but then it is exactly internal
DEFINE, so why change names?

I agree that (define foo) is reasonable, although only needed at top
level.  I use it often in MIT-Scheme.  In particular I use it as an
idiom indicating that the this variable is going to be assigned.  I
specify an initial value only when it will not change.  It is not
needed elsewhere (in MIT Scheme) because

(let ((foo))
  ...)

gives me a local binding for FOO which I can then assign.

    Note: no one at Indiana replied to Hanson's message, even though it
    isn't conclusive.  (I don't even think it's true; there could be
    multiple "global" environments, and SET!'s could be associated with them
    lexically.)  Did they assume that SET! would be changed?

JAR, I can't believe YOU have the bad taste to consider this (using
SET! to bind) seriously.  One of the features that I dislike the most
from MacLisp and Franz (which is a poor clone of MacLisp), is that
SETQ is used to bind variables.  I always use DEFCONST and DEFVAR
before assigning anything.  Making this the standard (eliminating
DEFINE) would guarantee that I would never write in the standard
dialect.  I'm sure that other people at MIT find this proposal as
distasteful as I do.  I don't object to a system (like MacScheme, for
example) where SET! "works", but under no circumstances will I
accept a situation where it is the only way to do it.  On such
systems, top-level DEFINE would be a NO-OP, which is fine with me, as
long as it is available.

∂01-Jun-86  2051	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	schedule  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Jun 86  20:51:03 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 JUN 86  23:49:28 EDT
Date: Sun,  1 Jun 86 23:49:21 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject:  schedule
To: JAR@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 29 May 86 14:36 EDT from Jonathan A Rees <JAR at MIT-AI.ARPA>
Message-ID: <[AI.AI.MIT.EDU].49879.860601.CPH>

I would vote for waiting a little longer before publishing, to get it
done right.  It's not terribly important to me that it happen
immediately.

∂01-Jun-86  2343	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  sentiments   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Jun 86  23:42:59 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  2 Jun 86 00:59:17 EDT
Received: from indiana by csnet-relay.csnet id a005855; 2 Jun 86 0:57 EDT
Date: Sun, 1 Jun 86 16:21:30 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: jar@MC.LCS.MIT.EDU
Subject: Re:  sentiments
Cc: dfried%indiana.csnet@CSNET-RELAY.ARPA, rrrs-authors@MC.LCS.MIT.EDU

        Date: Fri, 30 May 86 15:34:53 est
        From: Dan Friedman
        Sent-by: Kent Dybvig

First, let me apologize that the note from Dan looked like it was
coming from me.  I did "su dfried" and resent the note for him
after his first try failed.  I thought that it would put his name
on the note.  I also apologize for the length of this note, which
is due primarily to the fact that I have included the entirety of
Jonathan's response to Dan's note.
    
        ... define was merely an alias for set! ...
        This is how things were prior to the Brandeis meeting.
    
    This is how things were AT INDIANA prior to the Brandeis meeting.  At
    Yale and MIT they somewhat different (although not as different as you
    suppose) and had been since at least 1981.  Your quest for elegance is
    noble but please try not to equate your own version of Scheme with
    Scheme.

This is how things were in the first two Scheme reports, in several
Indiana Schemes, in one North Carolina Scheme, and probably in other
Schemes as well as of the Brandeis meeting.

        As I recall the feeling at the Brandeis meeting most of us were
        willing to go along with the idea of limiting the use of "define"
        internally to the semantics of SI&CP.  This was in the interest of
        good feeling about not undermining their book.  I hope everyone
        understands that I do not want to undermine their book, although I
        would like to see them rewrite it without internal defines.
        However, when I went along with this view I had underestimated how
        damaging this decision would be to the characterization of Scheme
        being a simple language.  I was expecting a "comment" in the report
        that stated that "use of define within the text of a program would
        be restricted to the use as given in SI&CP."  Instead, the
        definition of "lambda" got changed.  
    
    I don't understand.  Is it really the case that S&ICP never ever uses
    internal defines in the body of a lambda?  I'll check.  In any case, if
    internal definitions exist at all, LAMBDA is the ONLY form that's
    affected, after macro expansion.

I quickly scanned S&ICP and I found two uses of define within let
(pp.  234 and 238), and a mention of the use of a lambda-expression
translator to support internal definitions (p.  440).  The obvious
implication to the thoughtful reader is that the authors intend to
allow definitions at the front of a lambda body; however, it might
also be reasonable to only effect "define" (and "let" if the few uses
are considered enough reason to complexify it).

        Instead, begin must be added to the list of special forms.  
    
    Not true, and I'm don't understand why you think so.  Note that I
    clearly put BEGIN in the "derived expression types" section.  I will
    include the usual expansion of it in a future draft; I forgot to note
    that this was on my list of things to do.
    
That begin must be a core special form results from the fact that in
the report, (begin (define ...) ...) must not open up a new scope;
i.e., (begin x y ...) must not be defined as ((lambda () x y ...)),
or the more traditional form ((lambda (t) (begin y ...)) x) where t
does not appear free in (begin y ...).  I think of this as the "usual
expansion".

        Instead the macro for "letrec" must be conscious of it by having the
        body be "(let () <body>)" where it should be <body>.
    
    I proposed flushing internal definitions in the body of a letrec for
    exactly this reason.  But I don't see this as increasing the complexity
    of LETREC significantly, and I was wrong to draw attention to it.  I'll
    try to figure out how to make this smoother.

You are right, it is not much, but any added complexity is a shame,
especially when the added complexity is to support an innessential
feature (other than the one being described, of course).
    
        Instead define must be added to the list of special forms.
    
    What do you mean?  Definitions aren't even expressions!
    
I wouldn't brag about this!  Having already expanded Scheme from
expressions and functions to statements and procedures, we are now
adding declarations.  What happened to simplicity?

        Instead the semantics of "set!" are weakened so that
        it is not possible to just get by with "set!" and ignore "define".
    
    As has been explained innumerable times, there is no way to avoid this
    and have a language which is at all coherent with T and MIT Scheme.
    Note that in all programming languages of the Algol/Pascal/C variety it
    is an error to assign to an undeclared variable.  That MIT Scheme and T
    (and thus RRRS Scheme) also have this property is not coincidence.

Algol, Pascal, and C are not (typically) interactive languages, nor
do they have such nice features as first-class functions that allow
one to form modules of functions sharing local state/help functions.
I think that it would be possible in any system to have a notion of
a "top-level" lexical environment which implicitly contains bindings
for all things not bound elsewhere.  This could be a per-user or
per-module thing; it need not be the outermost lexical environment.
    
        Instead we must do something "special" with "lambda",
        "named-lambda", "let", "let*", and "letrec".
    
    Certainly the report is muddled, and I must accept the blame for some of
    this muddle.  I introduced a lot of the nonsense you're complaining
    about into this version of the report in a quest for accuracy.  I agree
    with your complaint that internal definitions are intrusive, and I'll do
    what I can to remedy the situation.
    
        We have taken a rather elegant language and made it elitest.
    
    I don't understand this use of that term.
    
I don't either, but I think what he means is that only a handful of
experienced implementors will understand how a full Scheme system is
implemented.

        I wanted all of my students to be able to implement "Scheme" when
        they walked out of my course, now that is no longer possible.
    
    This is false.  Internal defines are not essential.  If by "Scheme" you
    mean absolutely everything described in the report, I would expect that
    internal definitions (which can be implemented with a very small amount
    of code) would be the least of any implementor's worries.  What about
    number I/O?

Dan was referring, I'm sure, to the core of the language, which he
feels must now not only include lambda, set!, quote, if, identifiers,
and applications but also begin and define, not to mention the added
complexity of lambda.

        It was a great beauty of
        Scheme that the four mentioned special forms along with identifiers and
        application were the only syntax.  It was wonderful that a CPS interpreter
        for Scheme was all that was necessary to come to grips with in order to
        understand the run-time architecture of Scheme.  
    
    Why isn't this still true?
    
        My argument with internal-define is not that it is good or bad, but
        that the subtlety of its definition is unnecessary with judicious use
        of letrec and letrec should be a trivial macro.  What happened?
    
    How do internal definitions make LETREC more complicated?  The (LET ()
    ...)  (which would otherwise be a (BEGIN ...)) is trivial compared to
    the rest of what LETREC has to do, and doesn't even have to be there at
    all if you're not implementing the full language.
    
I think you misunderstood his point completely here.  He was merely
wondering of what use internal define is if you have letrec, and noted
that you can get letrec trivially with lambda and set!, if you like.

        I have never liked internal defines.
    
    Thanks for telling me, I hadn't figured this out.
    
        I thought they were harmless
        until I saw what havoc they introduced to the Report.  I am trying
        desperately to convince everyone that we made a mistake and we should
        do everything in our power before we go public on this Report to
        wait until we impose internal defines on everyone.
    
    I'll do what I can to fix the presentation; I can at least certainly
    make internal definitions less intrusive than they were in the RRRS.
    I hope that will be sufficient.  Personally, I wouldn't mind removing
    internal definitions from the language, although special treatment of
    definitions at top level of a file (which is another story altogether)
    must stay.

I agree in principle with this idea.  It makes sense that define at
top level should be treated specially, and nested definitions such as 
those given throughout S&ICP are quite handy and encourage modularity
in a nice way.  Since this treatment would not affect lambda or let,
it would be easy to understand and easy to implement.  I would agree
to using something totally different for definitions or perhaps use
the define/set! combinations for our interpretation of internal define
if we all agreed that define were only to be used at top level, with
the nested syntax.  I would even agree to making top-level, nested
define a required feature, and to requiring that define not be used
anywhere else.

    If you can convince everyone, including Sussman and Abelson,
    that internal definitions should be flushed, then I'll flush them.  If
    you must persue this, I suggest you talk to Sussman on the telephone
    about this; he isn't reachable by electronic mail until June 20, I
    think.  I'll try to find his phone number at Princeton or HP or wherever
    he is.
    
    Why does this question arise at this moment?  I am angered by the
    untimeliness of this debate.  Why didn't it come up when the idea of
    printing the report in SIGPLAN was first mentioned?  This part of the
    language hasn't changed.
    
We are all very sorry for the lateness of the debate, but it has
taken time to absorb everything (and we have brought it up before
publicly and privately, perhaps not as loudly).  None of us had used
a system with the internal definitions until after the RRRS (not R3S)
came out, so we must plead a certain amount of ignorance in earlier
discussions.  On the other hand, it is more important on the eve of
SIGPLAN publication than at any previous time, since that will be the
first wide distribution of a Scheme report, and we must come together
on this issue.  We have an exceptionally tight community of people
working on/with Scheme and it is not good for us to put each other at
odds by publishing a feature that some of us strongly dislike in its
current form.  We ask your forgiveness and patience; please realize
that we understand and very much appreciate all of your time and
effort that has gone gone into this report.

    Jonathan

Kent


∂02-Jun-86  0730	@MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU 	Another Can of Worms?
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jun 86  07:30:04 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JUN 86  10:28:49 EDT
Date: 2 Jun 1986 10:28-EDT
Sender: JMILLER@MIT-OZ
Subject: Another Can of Worms?
From: JMILLER@MIT-OZ
Reply-To: JMiller%OZ@MIT-MC
To: rrrs-authors@MC
Message-ID: <[MIT-OZ] 2-Jun-86 10:28:16.JMILLER>

I've withheld this one for a long time on the theory that new
problems with the language should be discussed AFTER the imminent
publication of the standard.  Since we appear to have stalled
that yet again, I'd like to mention it.

I am very concerned about the fact that the document we are
promulgating as a language standard permits of no way to write
truly portable code.  This arises from the lack of a convention
which would permit me to choose the names of variables which will
guarantee me that no implementation has used those names as
special forms.  I know of two solutions: (a) a gentleman's
agreement to the effect that every implementation will support
some well-publicized mechanism for absorbing foreign portable
code (in MIT Scheme, for example, we could provide a portable
syntax table for this purpose); or (b) as in BCPL, make a formal
statement as part of the language design that certain names will
never be used as the names of built-in special forms.

I am in favor of option (b) since it prevents the current
implementors from becoming a select small clique which has more
knowledge than outsiders.  One such proposal would be that we
insert a statement somewhere to the effect that "No
implementation shall supply by default a special form with ":" in
its name".  Thus portable code uses variables with ":" in them
somewhere and all is well.  [FYI, the BCPL statement was that
reserved words were all lower-case and more than one letter
long.]

-- Jim Miller

∂02-Jun-86  1558	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	sentiments    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jun 86  15:58:26 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JUN 86  18:56:44 EDT
Date: Mon,  2 Jun 86 18:41:25 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject:  sentiments
To: dyb%indiana.csnet@CSNET-RELAY.ARPA
cc: dfried%indiana.csnet@CSNET-RELAY.ARPA,
    rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Sun 1 Jun 86 16:21:30 est from Kent Dybvig <dyb%indiana.csnet at CSNET-RELAY.ARPA>
Message-ID: <[MX.LCS.MIT.EDU].923886.860602.JAR>

    Date: Sun, 1 Jun 86 16:21:30 est
    From: Kent Dybvig <dyb%indiana.csnet at CSNET-RELAY.ARPA>
        
    That begin must be a core special form results from the fact that in
    the report, (begin (define ...) ...) must not open up a new scope;
    i.e., (begin x y ...) must not be defined as ((lambda () x y ...)),
    or the more traditional form ((lambda (t) (begin y ...)) x) where t
    does not appear free in (begin y ...).  I think of this as the "usual
    expansion".

I get the feeling you haven't read the report.  According to NEITHER
Will's RRRS, NOR the draft I sent out, is (begin (define ...) ...) a
syntactically valid expression!  Look again at the BNF and at the text.
The usual expansion ((lambda (t) (begin y ...)) x) works perfectly well
since <expression> can't produce anything of the form (define ...),
<definition>s can only occur in <program>'s and <body>'s, and the syntax
of <sequence>s is (begin <expression>+), not (begin <body>).  The RRRS
says that definitions are expressions, which isn't exactly wrong, but it
seemed a little misleading to me, since they aren't legitimate in all
places where expressions are supposed to be.  (Again, only the details
of the description have changed, not the language described!)

Maybe you're misled by the statement in the RRRS that "(lambda (var1 ...)
expr1 expr2 ...) is equivalent to (lambda (var1 ...) (begin expr1 expr2
...))".  This can be seen to be technically true if either (a) you take
this statement to be only about the essential subset or (b) definitions
aren't expressions (so that the statement wouldn't apply in the case of
(begin (define ...) ...)).

The BNF in the draft makes the error of classifying (begin ...) as
primitive instead of derived.  This is an error.  (At one point I too
was confused and thought that begin had to be primitive, but Sussman
straightened me out).  Sorry if this bug confused you.  I will fix it.

    I wouldn't brag about this!  Having already expanded Scheme from
    expressions and functions to statements and procedures, we are now
    adding declarations.  What happened to simplicity?

"Now"?  The fact that definitions weren't valid in copntexts other than
top level and the beginnings of "bodies" was agreed on Brandeis and
hasn't been challenged until now.

Introducing the term "statement" to mean an expression whose value is
thrown away seems harmless to me; I was inspired to do this by the
abstract syntax that Will sent me for the denotational semantics (which
sets Com = Exp).  Using "<statement>* <expression>" instead of
"<expression>+" also gives a rationale for requiring at least one
expression in LAMBDA, BEGIN, etc.  If there's general sentiment that
this is a bad idea, I'll flush it, but I thought it was reasonable.

We all know why we use "procedure" instead of "function".  I don't
understand how this makes the language more complex.

Your question about simplicity is pure propaganda, so I won't answer it
beyond the above remarks.
        
        As has been explained innumerable times, there is no way to avoid this
        and have a language which is at all coherent with T and MIT Scheme.
        Note that in all programming languages of the Algol/Pascal/C variety it
        is an error to assign to an undeclared variable.  That MIT Scheme and T
        (and thus RRRS Scheme) also have this property is not coincidence.

    Algol, Pascal, and C are not (typically) interactive languages, nor
    do they have such nice features as first-class functions that allow
    one to form modules of functions sharing local state/help functions.
    I think that it would be possible in any system to have a notion of
    a "top-level" lexical environment which implicitly contains bindings
    for all things not bound elsewhere.  This could be a per-user or
    per-module thing; it need not be the outermost lexical environment.

I repeat: "there is no way to avoid [requiring that variables be bound
before they're assigned] and have a language which is at all coherent
with T and MIT Scheme."  I never said it would be impossible to
implement.  And interactiveness has nothing to do with it.
        
    ... I don't either, but I think what he means is that only a handful of
    experienced implementors will understand how a full Scheme system is
    implemented.
    ... Dan was referring, I'm sure, to the core of the language, which he
    feels must now not only include lambda, set!, quote, if, identifiers,
    and applications but also begin and define, not to mention the added
    complexity of lambda.

Do I need to mail out a complete evaluator in order to drive the point
home?
        
    I think you misunderstood his point completely here.  He was merely
    wondering of what use internal define is if you have letrec, and noted
    that you can get letrec trivially with lambda and set!, if you like.

No one ever said internal defines were linguistically necessary.  They
are obviously redundant.  They are there because it's very important to
be compatible with something so central to S&ICP.  Like I say, talk to
Sussman and Abelson if you dispute this.

    I agree in principle with this idea.  It makes sense that define at
    top level should be treated specially, and nested definitions such as 
    those given throughout S&ICP are quite handy and encourage modularity
    in a nice way.  Since this treatment would not affect lambda or let,
    it would be easy to understand and easy to implement.

How does its not affecting lambda or let have anything to do with how
easy it is to implement?  Implementing internal defines involves one
trivial loop, and it doesn't matter whether you put this loop in the
code for lambda or define, although it DOES matter if you have to invoke
it two places.

    I would agree
    to using something totally different for definitions or perhaps use
    the define/set! combinations for our interpretation of internal define
    if we all agreed that define were only to be used at top level, with
    the nested syntax.  I would even agree to making top-level, nested
    define a required feature, and to requiring that define not be used
    anywhere else.

I don't understand this paragraph at all.  Note that no one has ever
wanted internal defines to be essential in any context.

    ... We have an exceptionally tight community of people
    working on/with Scheme and it is not good for us to put each other at
    odds by publishing a feature that some of us strongly dislike in its
    current form.

Like I say, talk to Abelson and Sussman.  I think a lot has and can be
done to make internal definitions minimally ugly and intrusive.  It is
not good to confuse many innocent bystanders and put your community at
odds with MIT's by permitting an incompatible meaning for DEFINE.

Jonathan.

∂02-Jun-86  1604	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	DEFINE -- a concrete proposal  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jun 86  16:02:48 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  2 Jun 86 18:57:59 EDT
Received: from tektronix by csnet-relay.csnet id an13197; 2 Jun 86 18:51 EDT
Received: by tektronix.TEK (5.31/6.14)
	id AA09219; Mon, 2 Jun 86 13:19:31 PDT
Received: by tekchips (5.31/5.14)
	id AA05517; Mon, 2 Jun 86 13:23:57 PDT
Message-Id: <8606022023.AA05517@tekchips>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: jar%mx.lcs.mit.edu@MC.LCS.MIT.EDU, wand%northeastern.edu@CSNET-RELAY.ARPA, 
    dfried%indiana.csnet@CSNET-RELAY.ARPA
Subject: DEFINE -- a concrete proposal
Date: 02 Jun 86 13:23:55 PDT (Mon)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

I propose that section 4.1.0 of the 22 May 1986 draft be clarified to
read as follows:

    At the top level of a program, a definition

        (define <variable> <expression>)

    has essentially the same effect as the assignment expression

        (set! <variable> <expression>)

    if <variable> is bound.  If <variable> is not bound, however,
    then the definition will bind <variable> before performing
    the assignment, whereas it would be an error to perform a
    set! on an unbound variable.

        [examples go here]

    Top level definitions are essential; all Scheme implementations
    must support them.

    Some implementations of Scheme use an initial environment in
    which all possible variables are bound to locations, most of
    which contain undefined values.  Top level definitions in
    such an implementation are truly equivalent to assignments.

In my opinion, this is merely a clarification because the draft
does not say that the initial environment must contain only the
variables mentioned in the report, and it is in fact the case
that most implementations supply variables that don't appear
in the report.  Furthermore, even if unbound variables exist,
the phrase "it would be an error" indicates that implementations
are not required to complain when one is assigned, so an
implementation is free to do something random (like bind the
variable and do an assignment) instead of signalling the error.

The phrase "Some implementations of Scheme" is the very same
neutral phrase used at the beginning of Section 4.2 on internal
definitions.  Thus the report would be neutral between those
who for whatever reason want to assign variables before they
declare them and those who for whatever reason prefer the
internal definition syntax to LETREC.

Since this is only a clarification of what is already implicit
in the report, I believe this proposal should satisfy those who
prefer the status quo.  I believe it should also satisfy those
who with Mitch are arguing for the following:

    An implementation may have a top level (initial, whatever)
    environment in which every possible identifier is bound
    (though only some are initialized).

    This would allow programs in that implementation to do a set!
    on a global variable (excuse me, a variable in the current
    top-level environment) from an internal scope without having
    to explicitly bind the variable in the initial scope.  It would
    also allow MIT-style define to proceed, as it does not require
    the existence of a distinguished global environment.

Mitch is entirely right that his proposal retains the spirit of
the Brandeis agreement on this issue.  Though Jonathan said in
his reply to Mitch that he wouldn't have too much problem with
adding this clarification to the report, he insisted that it should
be "accompanied by some mention of the fact that some implementations
have principled reasons for not having this feature".  I say that
stipulation is unfair -- the report doesn't contain any of the
principled arguments against internal definitions or against the
fancy DEFINE syntax or against REC or against NAMED-LAMBDA or
against NIL or against the behavior of EQ? on procedures or
against hexadecimal notation...

Dan Friedman had some very reasonable things to say about the
importance of simplicity and elegance, particularly with regard
to ease of implementation by students.  My answer is that
students should implement "Essential Scheme" instead of worrying
about how to get ASIN to work with complex numbers.  Essential
Scheme does not have internal definitions, and it is perfectly
all right to use an initial environment in which all variables
are bound and to implement DEFINE as assignment.

I must admit that Essential Scheme is a more elegant language than
full Scheme.

I second Bill Rozas's objections to MAKE-LOCAL-VARIABLE as a procedure
for performing incremental definitions.

Let us seek peace,
William Clinger

----------------------------------------------------------------
[Because of one mailer error, the local postmaster has suggested
that people send me mail at willc@tekchips.tek.csnet instead of
at willc%tekchips@tektronix.csnet, which had worked fine until
now.  If one doesn't work, please try the other.]

∂02-Jun-86  1803	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: definitions; APPEND!; etc 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jun 86  18:03:10 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  2 Jun 86 21:02:04 EDT
Received: from ti-csl by csnet-relay.csnet id a014023; 2 Jun 86 20:52 EDT
Received: by tilde id AA20278; Mon, 2 Jun 86 19:00:17 cdt
Date: Mon 2 Jun 86 18:46:15-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: definitions; APPEND!; etc
To: willc%tekchips.tek@CSNET-RELAY.ARPA, 
    rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: jar%mc.lcs.mit.edu@CSNET-RELAY.ARPA, Bartley%TI-CSL@CSNET-RELAY.ARPA, 
    605301901283@tekchips
MMDF-Warning:  Parse error in original version of preceding line at CSNET-RELAY.ARPA
Message-Id: <12211713593.48.BARTLEY@CSC60>

[Bartley:]
>>APPEND! always side-effects all but its last argument. 

[Clinger:]
>No, APPEND! should not be required to perform side effects.  This is not
>as silly as it may sound.  In an implementation using the Hewitt-Lieberman
>gc algorithm, for example, side effects to sufficiently old structures are
>likely to be more expensive than consing.  APPEND! should be free to decide
>for itself which technique is fastest.

My point of view is that APPEND! is used to ensure sharing of
structure and APPEND is used to ensure that structure is NOT shared
(except in the clearly specified case of the last argument).

>I would feel differently if APPEND! returned an unspecified value, as
>does VECTOR-SET!.

Perhaps that would be more consistent.  Perhaps we should call it
SET-LAST-CDR! instead!

Seriously, I could go either way, but I'm sure some of my code would
fail to work on a system in which APPEND! did not share structure.
Are there any others we should be discusssing?

--db--
-------


∂03-Jun-86  0853	@MC.LCS.MIT.EDU:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86  08:53:32 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  3 Jun 86 11:48:51 EDT
Received: from ti-csl by csnet-relay.csnet id ac20037; 3 Jun 86 11:38 EDT
Received: by tilde id AA02583; Tue, 3 Jun 86 11:06:15 cdt
Date: Tue, 3 Jun 86 11:06:15 cdt
From: John Maeda <maeda%tilde%ti-csl.csnet@CSNET-RELAY.ARPA>
To: jkr%mit-oz@MC.LCS.MIT.EDU


okay glen I hope this gets to you; I had written you a real l ong letter but 
I have no idea how to save it from this version of EMACS running on this uLTRIX
machine ... (must be a ti-professional playing "multi-user") ... so I'm really
ticked, I just hope this gets to you.


jtm


∂03-Jun-86  0953	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	APPEND!  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86  09:53:47 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 JUN 86  12:52:26 EDT
Date: Tue,  3 Jun 86 12:37:27 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject:  APPEND!
To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 2 Jun 86 18:46:15-CDT from David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
Message-ID: <[MX.LCS.MIT.EDU].924078.860603.JAR>

Maybe we should just flush APPEND! altogether?  It's easy enough to do
(SET-CDR! (LAST-PAIR list1) list2).  I think Sussman was the one who
really wanted APPEND! in the language, but I forget why.

Jonathan

∂03-Jun-86  1010	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	portability   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86  10:09:43 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 JUN 86  13:08:08 EDT
Date: Tue,  3 Jun 86 13:08:20 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject:  portability
To: RRRS-AUTHORS@MX.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].924086.860603.JAR>

The following is in response to Jim Miller's message about portability,
which raises an important question I've been hoping to repress.  But Freud
tells us that the repressed always returns.

- Jonathan


Date: Sat, 31 May 86 21:32:00 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
To:   GJC%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU
cc:   JAR at MX.LCS.MIT.EDU
Re:   revised↑n report
In-reply-to: Msg of Sat 31 May 86 13:16:32 EDT from George J. Carrette <GJC%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
Message-ID: <[MX.LCS.MIT.EDU].923398.860531.JAR>

    Date: Sat, 31 May 86 13:16:32 EDT
    From: George J. Carrette <GJC%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
    To:   JAR%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU

    One should be able to show that clever underspecification in
    a language spec is eventually a losing proposition. Example:
    in CL (make-array 3) => #(0 0 0) (e.g. in VAX-NIL) or #(NIL NIL NIL)
    in at least the LISPM environments I'm aware of. The idea
    is to make the guy say (make-array <x> :initial-element <value>) if
    he is depending on the initial value. Supposed to be a big efficiency
    win. (now, I've just spent a few hours tracking down a bug in the
    DOE-MACSYMA plot package that had to do with the initial element of
    an array screw). A few days ago you had a note to the CL list about
    a similar underspecification screw in defstruct.

    Well, revised↑n has its share of clever underspecification too.
    But, is this really a win in a language spec? Or is it just a way
    of showing (forcing down everybodies neck...) how much the
    language designers know about different implementation tricks?
    You dont see this kind of stuff in other language specs.

    Back to the array example. Is it reasonable to argue that in lisp
    there are good natural default values? The empty list as default
    for an array? I think it is. On the other hand, if you know that
    there might be machine dependancies in these defaults, (in fact it
    is usually operating system dependancies. VMS goes to some trouble to
    make sure pages allocated to users are filled with zero's)
    then why not have:
     (make-array 10 :initial-element *:system-prefered-initial-array-element).

    I argue that clever underspecifications for the purpose of elicidating
    implementation tricks know by the language designers causes:
     * "dating" of the language.
     * frustration for users of the language
     * eventual lack of portability.

This is all too true.  I think that if I were designing another language
now I would try to get rid of all underspecifications, since they lead
to so much confusion.  I hope that as many underspecifications as
possible will disappear from Common Lisp.

Let me try to figure out why I think it's OK for Scheme to be
underspecified and not for Common Lisp to be underspecified.  Scheme's
underspecifications don't generally have anything to do with
"implemetation tricks."  Political expediency demands that the report
leave a lot of room for local variation.  We wouldn't be able to get
agreement on all these little things.  Some differences between versions
result from differing implementation demands, but mostly it's that the
different groups have incompatible ideologies, so each group would have
its own idea of what the "right" thing is for each situation.

The goals of Revised↑n Scheme differ from those of Common Lisp, I think.
Mostly we want to be able to read each others' code when it appears in
the literature, and relieve people from the pain of there being
incompatible languages all calling themselves "scheme".  Portability is
only a secondary consideration, and we're not so concerned that all
non-erroneous programs should port, only that "well-written" programs
should port.  I think there's the feeling that people who write in
Scheme don't just play around until their code just happens to work
(often the only programming technique available in some systems which
will remain nameless) -- they actually write "clean" code which observes
data abstractions and doesn't depend on things it shouldn't depend on
(like the initial value of vector components).  So while it's very easy
to write unportable code, people who do so have somehow missed the
point, and probably ought to be programming in CLU or Ada (or the
language I have yet to design?) instead.

If we really want to aim for airtight portability then we've got to start
making a lot of changes.

Jonathan.

∂03-Jun-86  1124	@MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA 	define   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86  11:23:18 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  3 Jun 86 14:20:34 EDT
Received: from northeastern by csnet-relay.csnet id a000357; 3 Jun 86 14:19 EDT
Date:     Tue, 3 Jun 86 11:29 EST
From:     MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>
To:       rrrs-authors@MC.LCS.MIT.EDU
Subject:  define 

1. I think the discussion has clarified, at least for me, the difference 
between "internal" and "incremental" define.  I was certainly thinking about 
"incremental" define, which happens conceptually at run-time.  As I gather it, 
the idea is that internal define is JUST SYNTAX, which might be formalized as
something like

(define-equivalent-syntax		;; hypothetical pseudocode! 
  (<context-for-internal-define>
   (define name1 body1) ...
   <body>)
  (letrec
    ((name1 body1) ...)
    <body>))

The only place where "internal" define acts truly incrementally is at the top 
level.

If this is correct, then my objections are considerably lessened.  The major 
complication of internal define, then, is sorting out in exactly which 
contexts this syntax is permissable.  This is a matter on which I think there 
can be reasoned debate. 

2. Will's proposal looks OK to me.

3. (make-local-variable 'foo) was a joke.  No one seemed to get it.  Sorry 
'bout that.

4. Thanks to jinx and to jar for their thoughtful replies.  In particular 
thanks to jar (I think) for extracting the historical record.  I say "jar (I 
think)" because I've managed to lose my copy ($%↑&! VMS mailer); could someone 
retransmit it?  Tnx.

Mitch

∂03-Jun-86  1441	@MC.LCS.MIT.EDU:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA 	SCOOPS source   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86  14:41:37 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  3 Jun 86 17:33:42 EDT
Received: from ti-csl by csnet-relay.csnet id ac02031; 3 Jun 86 17:24 EDT
Received: by tilde id AA11964; Tue, 3 Jun 86 16:45:17 cdt
Date: Tue 3 Jun 86 15:32:49-CDT
From: Amitabh Srivastava <Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: SCOOPS source
To: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA
Message-Id: <12211940524.20.ASRIVASTAVA@CSC60>


SCOOPS source is available now. It can be obtained by doing anonymous
ftp at host BBNA to the directory PS:<TICSL.RELSCOOPS> .

Initially, ftp the file README.SCM . It contains list of the
files needed and other information. The sources have been modified
and are totally in TI Scheme. 

- amitabh
-------


∂03-Jun-86  1554	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Is BEGIN primitive?  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86  15:54:17 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  3 Jun 86 18:50:57 EDT
Received: from tektronix by csnet-relay.csnet id ai02667; 3 Jun 86 18:43 EDT
Received: by tektronix.TEK (5.31/6.14)
	id AA00979; Tue, 3 Jun 86 10:00:01 PDT
Received: by tekchips (5.31/5.14)
	id AA14582; Tue, 3 Jun 86 10:04:26 PDT
Message-Id: <8606031704.AA14582@tekchips>
To: jar%mx.lcs.mit.edu@MC.LCS.MIT.EDU, dyb%indiana.csnet@CSNET-RELAY.ARPA
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: Is BEGIN primitive?
Date: 03 Jun 86 10:04:25 PDT (Tue)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

Whether you think BEGIN must be a primitive expression depends on your
cultural heritage.  If you have grown up believing that syntax is fully
checked before macro expansion, then (BEGIN X Y ...) ==>
((LAMBDA () X Y ...)) works fine.  If you have grown up believing that
macros do the least amount of syntax checking they can get away with
(or less), then (BEGIN (DEFINE ...) ...) ==> ((LAMBDA () (DEFINE ...) ...))
does not detect the syntax error.

I like the term "derived expression" because it expresses the fact that
the semantics of BEGIN can be expressed in terms of primitive expressions
without implying that a macro mechanism is used.

Though the word "statement" ought to signify a declarative assertion,
the American programming language community long ago corrupted it to
signify a command.  I prefer the English "command", but I prefer even
"statement" to the phrase "expression evaluated solely for effect".

Peace, Will

∂03-Jun-86  2023	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	ftp-able r3rs.dvi   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Jun 86  20:22:59 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 JUN 86  23:22:06 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 2325; Tue 3-Jun-86 23:22:23-EDT
Date: Tue, 3 Jun 86 23:21 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: ftp-able r3rs.dvi
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <860603232145.2.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>

I put the DVI file for the report on host MIT-PREP.  The filename
is
	/u/jar/r3rs.dvi


- Jonathan

∂04-Jun-86  0554	@MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU 	Re:  portability
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 4 Jun 86  05:53:58 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 4 JUN 86  08:52:11 EDT
Date: 4 Jun 1986 08:51-EDT
Sender: JMILLER@MIT-OZ
Subject: Re:  portability
From: JMILLER@MIT-OZ
Reply-To: JMiller%OZ@MC
To: RRRS-Authors@MC
Message-ID: <[MIT-OZ] 4-Jun-86 08:51:16.JMILLER>
In-Reply-To: <[MX.LCS.MIT.EDU].924086.860603.JAR>

Well, I agree in principle with all that was said.  But I think
you have missed one important point: it is not possible, even
with all the care in the world, to write portable code in the
current design.  I don't want to contort the language design in
any way (and neither of my suggestions do that) but I DO want
some statement which makes the possibility of portable code
feasible.

I urge you to think, again, about including some formal and
mutually agreeable statement which limits the implementors choice
of names for special forms.  I believe that this is the sole
requirement necessary to permit a person intent on writing a
totally portable program to succeed.

--Jim

∂04-Jun-86  1049	@MC.LCS.MIT.EDU:Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: SCOOPS source    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 4 Jun 86  10:49:32 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  4 Jun 86 13:44:00 EDT
Received: from ti-csl by csnet-relay.csnet id ac10705; 4 Jun 86 13:37 EDT
Received: by tilde id AA07924; Wed, 4 Jun 86 11:55:29 cdt
Date: Wed 4 Jun 86 11:47:42-CDT
From: Amitabh Srivastava <Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: SCOOPS source
To: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <12211940524.20.ASRIVASTAVA@CSC60>
Message-Id: <12212161685.28.ASRIVASTAVA@CSC60>


I am sorry - our systems people blew it. BBNA does not allow
user anonymous. The sources are available on host UTEXAS-20
in the directory ps:<g.ti.scoops> . Use anonymous ftp to get the
sources.

Initially, ftp the file README.SCM . It contains list of the
files needed and other information. The sources have been modified
and are totally in TI Scheme. 

Again, my apologies for this confusion.

- amitabh
-------


∂04-Jun-86  1623	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: portability 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 4 Jun 86  16:23:39 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  4 Jun 86 19:23:00 EDT
Received: from tektronix by csnet-relay.csnet id ae02282; 4 Jun 86 18:58 EDT
Received: by tektronix.TEK (5.31/6.14)
	id AA25894; Wed, 4 Jun 86 09:46:37 PDT
Received: by tekchips (5.31/5.14)
	id AA28499; Wed, 4 Jun 86 09:51:05 PDT
Message-Id: <8606041651.AA28499@tekchips>
To: JMiller%OZ@MC.LCS.MIT.EDU
Cc: RRRS-Authors@MC.LCS.MIT.EDU
Subject: Re: portability
In-Reply-To: Your message of 4 Jun 1986 08:51-EDT.
	     <[MIT-OZ] 4-Jun-86 08:51:16.JMILLER>
Date: 04 Jun 86 09:51:03 PDT (Wed)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

Jim Miller writes:
>I urge you to think, again, about including some formal and
>mutually agreeable statement which limits the implementors choice
>of names for special forms.  I believe that this is the sole
>requirement necessary to permit a person intent on writing a
>totally portable program to succeed.

Suppose every implementation of Scheme were required to supply a
"vanilla" mode in which all reserved words are among those that
appear in the report?

Peace, Will

∂05-Jun-86  0546	@MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU 	Re: portability 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Jun 86  05:46:24 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 JUN 86  08:43:44 EDT
Date: 5 Jun 1986 08:42-EDT
Sender: JMILLER@MIT-OZ
Subject: Re: portability
From: JMILLER@MIT-OZ
Reply-To: JMiller%OZ@MC
To: RRRS-Authors@MC
Message-ID: <[MIT-OZ] 5-Jun-86 08:42:33.JMILLER>
In-Reply-To: <8606041651.AA28499@tekchips>

I'd be happy with Will's suggestion, and it does make the writing
of portable code considerably easier than my suggestion.  I'm
only concerned that this may require unanimous consent.  I
believe that the MIT system already includes the necessary hooks
(we would supply an RRRS-Essential syntax table).

--Jim

∂05-Jun-86  0935	@MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA 	Will's proposal
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Jun 86  09:34:51 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  5 Jun 86 12:34:17 EDT
Received: from indiana by csnet-relay.csnet id a007465; 5 Jun 86 12:21 EDT
Date: Wed, 4 Jun 86 23:44:17 est
From: Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Will's proposal

We are satisfied with Will's proposal re "set!".

Dan



∂05-Jun-86  0939	@MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA 	named-lambda and rec
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Jun 86  09:39:00 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  5 Jun 86 12:34:21 EDT
Received: from indiana by csnet-relay.csnet id aa07465; 5 Jun 86 12:21 EDT
Date: Wed, 4 Jun 86 23:47:27 est
From: Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: named-lambda and rec

Jinx recently suggested that he could live without either.
I second jinx's suggestion.  
Dan


∂05-Jun-86  1055	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	named-lambda and rec
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Jun 86  10:55:38 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 5 JUN 86  13:54:39 EDT
Date: Thu,  5 Jun 86 13:54:25 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject:  named-lambda and rec
To: dfried%indiana.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 4 Jun 86 23:47:27 est from Dan Friedman <dfried%indiana.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].52205.860605.CPH>

    Date: Wed, 4 Jun 86 23:47:27 est
    From: Dan Friedman <dfried%indiana.csnet at CSNET-RELAY.ARPA>

    Jinx recently suggested that he could live without either.
    I second jinx's suggestion.  

I `third' it.

∂06-Jun-86  0800	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	portability   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 6 Jun 86  08:00:02 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 JUN 86  10:59:40 EDT
Date: Fri,  6 Jun 86 10:59:26 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject:  portability
To: JMiller@OZ.AI.MIT.EDU
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 5 Jun 1986 08:42-EDT from JMILLER at MIT-OZ
Message-ID: <[MX.LCS.MIT.EDU].924918.860606.JAR>

I would say that a strict reading of the new draft, and perhaps even of
the RRRS, would say that ANY identifier other than those explicitly
listed as syntactic keywords (reserved words) may be used as a variable.
In other words, a correct implementation of the report would already
have the property that there are no other special forms other than the
ones explicitly listed in the report (the complete list is somewhere
inside the BNF).  So that a program which does (define trace ...)  or
(let ((loop ...)) ... (loop ...) ...)  would already be portable.  The
addition of ANY special form is an incompatible change to Scheme.

[Actually, if in a particular implementation special-form-ness is
cancelled out by DEFINE and lambda-binding, then it would probably be OK
in that implementation to have extra special forms/macros lying around,
since a program which used those identifiers for variables would still
be correct.  But let's not think about this possibility.]

I wouldn't say that all implementations would have to start up with the
stripped-down syntax, omitting all their favorite features, but I think
that supplying a mode in which this was the case, rather than saying
only a certain class of identifiers can be used as variables, is the
right thing.

Would any implementors have any problem providing a report-syntax-only
mode?  I know this is trivial in MIT Scheme and T, but we haven't heard
from other implementors.

If there are problems, then one way to cope would be to add to the
report's list of syntactic keywords some or all of the things which such
implementations would like to have be special forms, e.g. define-macro,
trace, make-environment, etc., simply saying that these are reserved for
use by particular implementations as syntactic keywords, but have no
meaning according to the report.  This is sort of the dual of Jim's
original suggestion.  It's pretty gross, but I thought I'd mention it.

How should this situation be explained in the report, if at all?

Jonathan

∂06-Jun-86  0806	@MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA 	add1 and sub1  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 6 Jun 86  08:06:06 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  6 Jun 86 11:05:34 EDT
Received: from indiana by csnet-relay.csnet id aa00907; 6 Jun 86 11:04 EDT
Date: Fri, 6 Jun 86 09:57:13 est
From: Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: add1 and sub1


When describing arithmetic I find the symbols "1+" and 
"-1+" very harmful.  The function + is denoted by the
symbol "+" and this confuses people who are trying to
understand the primitive recursive definition of +.
Purely for pedagogical reasons I would like to see "add1"
and "sub1" be optional.  I know that macscheme & PC-Scheme
have included them.  I don't like multiple names for the
same construct, but we have a few instances already in the
report.  

Dan


∂06-Jun-86  1039	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	add1 and sub1  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 6 Jun 86  10:39:37 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 JUN 86  13:38:58 EDT
Date: Fri,  6 Jun 86 13:38:45 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject:  add1 and sub1
To: dfried%indiana.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 6 Jun 86 09:57:13 est from Dan Friedman <dfried%indiana.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].52665.860606.CPH>

    Date: Fri, 6 Jun 86 09:57:13 est
    From: Dan Friedman <dfried%indiana.csnet at CSNET-RELAY.ARPA>

    When describing arithmetic I find the symbols "1+" and 
    "-1+" very harmful.

    Purely for pedagogical reasons I would like to see "add1"
    and "sub1" be optional.

Another alternative might be to make `1+' and `-1+' optional, since
they aren't necessary in any sense.  Then there would be no need to
describe them to students at all.

In fact, there's no need to teach them even if they are essential.

∂06-Jun-86  2038	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: portability
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 6 Jun 86  20:38:22 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  6 Jun 86 16:25:39 EDT
Received: from ti-csl by csnet-relay.csnet id ad03178; 6 Jun 86 16:24 EDT
Received: by tilde id AA18136; Fri, 6 Jun 86 14:06:53 cdt
Date: Fri 6 Jun 86 13:55:31-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: portability
To: JAR%MX.LCS.MIT.EDU%mc.lcs.mit.edu@CSNET-RELAY.ARPA, 
    JMiller%oz.ai.mit.edu@CSNET-RELAY.ARPA
Cc: RRRS-Authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA, Bartley%TI-CSL@a

In-Repl <[MX.LCS.MIT.EDU].924918.860606.JAR>
Message-ID: <12212709243.41.BARTLEY@CSC60>

From JAR:
>I would say that a strict reading of the new draft, and perhaps even of
>the RRRS, would say that ANY identifier other than those explicitly
>listed as syntactic keywords (reserved words) may be used as a variable.
>In other words, a correct implementation of the report would already
>have the property that there are no other special forms other than the
>ones explicitly listed in the report (the complete list is somewhere
>inside the BNF).  So that a program which does (define trace ...)  or
>(let ((loop ...)) ... (loop ...) ...)  would already be portable.  The
>addition of ANY special form is an incompatible change to Scheme.

Several implementations, including Chez Scheme, PC Scheme, and
Scheme-84, allow user-specified syntactic extensions.  I doubt if we
could get a consensus that this is to be disallowed.  When you (JAR)
speak of special forms, are you including macros and the like?

>[Actually, if in a particular implementation special-form-ness is
>cancelled out by DEFINE and lambda-binding, then it would probably be OK
>in that implementation to have extra special forms/macros lying around,
>since a program which used those identifiers for variables would still
>be correct.  But let's not think about this possibility.]

Is there an alternative possibility?

(This paragraph seems to say that you are speaking of macros as well
as special forms.)

Regards,
David Bartley
-------


∂07-Jun-86  1658	@MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA 	macros.   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Jun 86  16:58:00 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  7 Jun 86 19:49:27 EDT
Received: from indiana by csnet-relay.csnet id a005487; 7 Jun 86 19:00 EDT
Date: Sat, 7 Jun 86 15:25:24 est
From: Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: macros.


Our programming relies heavily on the safe use of macros.
No one here would be willing to remove the option of having
them in the language.  

Dan


∂07-Jun-86  1820	@MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: named-lambda and rec  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Jun 86  18:19:56 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  7 Jun 86 21:18:13 EDT
Received: from tektronix by csnet-relay.csnet id ad00288; 7 Jun 86 1:47 EDT
Received: by tektronix.TEK (5.31/6.14)
	id AA19278; Fri, 6 Jun 86 09:06:33 PDT
Received: by tekchips (5.31/5.14)
	id AA26553; Fri, 6 Jun 86 09:11:02 PDT
Date: Fri, 6 Jun 86 09:11:02 PDT
From: Norman Adams <adams%tekchips.tek.csnet@CSNET-RELAY.ARPA>
Message-Id: <8606061611.AA26553@tekchips>
Subject: Re: named-lambda and rec
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Dan Friedman <dfried%indiana.csnet@csnet-relay.arpa>, Wed, 4 Jun 86 23:47:27 est

I too would prefer to see both NAMED-LAMBDA and REC removed.
-Norman

    
    
    
-------

∂07-Jun-86  1829	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  add1 and sub1
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Jun 86  18:29:40 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  7 Jun 86 21:19:58 EDT
Received: from indiana by csnet-relay.csnet id a003864; 7 Jun 86 13:46 EDT
Date: Fri, 6 Jun 86 15:43:12 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re:  add1 and sub1

    Another alternative might be to make `1+' and `-1+' optional, since
    they aren't necessary in any sense.  Then there would be no need to
    describe them to students at all.

These are already innessential, in both RRRS and the draft RRRRS.

Chez Scheme will support add1 and sub1 for Dan (and the Little LISPer),
but I don't care if they appear in the report or not.  I will also support
1- as an alternative for -1+; if ever there was a gratuitous difference
from Common Lisp, -1+ is it.  Actually, I'd prefer flushing 1+ and -1+
from the report, but it doesn't seem worth worrying about.


∂08-Jun-86  1652	@MC.LCS.MIT.EDU:Swenson.Multics@MIT-MULTICS.ARPA 	Re: SCOOPS source   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 8 Jun 86  16:52:36 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  8 Jun 86 19:47:59 EDT
Received: from mit-multics.arpa by CSNET-RELAY.ARPA id a006158;
          8 Jun 86 19:45 EDT
Acknowledge-To:  "Eric J. Swenson" <Swenson@MIT-MULTICS.ARPA>
Date:  Sun, 8 Jun 86 19:35 EDT
From:  "Eric J. Swenson" <Swenson@MIT-MULTICS.ARPA>
Subject:  Re: SCOOPS source
To:  Amitabh Srivastava <Asrivastava%ti-csl.csnet@CSNET-RELAY.ARPA>
cc:  scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
In-Reply-To:  Message of 3 Jun 86 16:32 EDT from "Amitabh Srivastava"
Message-ID:  <860608233557.811290@MIT-MULTICS.ARPA>

Are you certain BBNA supports anonymous FTP?  I repeatedly get rejected
when attempting to "login anonymous" with an error indicating that there
is no such user as "anonymous."

∂09-Jun-86  1643	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	portability   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 9 Jun 86  16:43:34 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 JUN 86  19:43:14 EDT
Date: Mon,  9 Jun 86 19:27:34 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject:  portability
To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
cc: RRRS-AUTHORS@MX.LCS.MIT.EDU
Message-ID: <[MX.LCS.MIT.EDU].925333.860609.JAR>

OK, my message seems to have confused a lot of people.  I'll try to be
clearer.  For the purposes of this message I'll only consider
system-supplied special form types, not user-supplied ones, although the
problems are I think the same.

Jim Miller said originally that he didn't see any way to write portable
programs which used variables, because implementations were free to
preempt arbitrary variable names for use as syntactic keywords.  I just
wanted to reply that on the contrary, the report is clear on what the
set of allowable variable names is.  The BNF describes a <variable> as
being any <identifier> which isn't a <syntactic keyword>, and the
<syntactic keywords> are enumerated.  E.g.  according to my reading of
the report, the sequence

	(define block (lambda (x) (extend x 3)))
	(define extend (lambda (a b) (list b a)))
	(block 1)

has a perfectly well-defined meaning: BLOCK and EXTEND are variable
names (unconditionally!); these names become bound to values; the value
of BLOCK is applied to the number 1; etc.  I didn't see anything in the
report which allowed any implementation to assign any other meaning to
this program fragment.  Any implementation which did something different
with this code fragment (e.g., T, which has BLOCK-expressions, and
independent namespaces for variables and keywords) would not be
implementing the language described in the report.

I don't think this is a departure from the previous report, although of
course my edits have made the *description* follow my world view more
closely.

The way so-called "syntactic extensions" usually (not always) work,
however, is that they pre-empt certain identifiers for use as variable
names.  E.g. an implementation might make BLOCK or EXTEND unavailable.
Or, worse, the variables remain available, but expressions whose cars
are these names are no longer treated as procedure calls.  Then the
above program wouldn't have the expected meaning.  I say that such
modifications to the language aren't syntactic extensions, since they
incompatibly change the meanings of programs, rather than just defining
what would otherwise be an error situation.

If the implementation is clever enough that program fragments like these
still work, i.e. the extensions are only seen when the variable is
undefined (a situation which would otherwise be an error), then that's
fine, but I don't think that's how most scheme implementations out there
actually implement their additional special form types.  (Correct me if
I'm wrong.  Consider forward references.)

Implementations can support macros (they can also support Algol 60 mode,
or any other incompatible change, if they want -- it's not as if it's a
sin to program in something other than reportified-scheme), so long as
there's some way to run programs written in the language described in
the report.  Several existing implementations are already structured to
make it easy to support multiple such modes or incompatible dialects; so
what's the big deal?

In short: why should the report say anything at all about this issue?
To warn implementors not to do the wrong thing?

Do we want to change the report to explicitly ALLOW the preemption of
arbitrary variable names?  I think Jim's question originated from a
belief that implementations were free to do this and still claim to be
adhering to the report.  I think that's absurd.  How should the report's
examples, much less portable programs in general, be written in that
case?

Jonathan

∂10-Jun-86  0744	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  portability  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jun 86  07:44:19 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 10 Jun 86 10:40:50 EDT
Received: from indiana by csnet-relay.csnet id a005144; 10 Jun 86 10:36 EDT
Date: Tue, 10 Jun 86 01:43:10 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: bartley%ti-csl.csnet@CSNET-RELAY.ARPA, jar@MC.LCS.MIT.EDU
Subject: Re:  portability
Cc: rrrs-authors@MC.LCS.MIT.EDU

I don't think this issue is as cut and dried as all that.  Jonathan
is right on the one hand; it is ``absurd'' to write portable programs
if any identifier might be taken away by a particular implementation.
However, it is not clear to me what the most practical solution is
at this point for systems that have additional special forms or user-
defined macros.  It is certainly not practical to stay away from all
special forms but those appearing in the report.  Nor is it practical
to invalidate a macro when a binding is found; as Jonathan points
out, forward references become a problem.  Perhaps it is practical to
complain when a binding is found; this does not allow portable code
but it does provide some level of sanity.  And I'm not sure it is
practical to have a "vanilla" mode; although the issue is worthy of
consideration, what happens when someone wants a basically portable
piece of code to use a system-specific special form?

If I had to take a stand one way or another, I would probably favor
a more liberal definition of keyword---rather than saying that all
of the keywords are enumerated in the report, I would allow for the
inclusion of additional keywords by any particular implementation,
with the requirement that any implementation must provide a warning
when a keyword is used as a variable.  Writing portable code would
be an iterative process, but it would be relatively painless.

But I don't really want to take a stand at this point.  I would
rather leave this topic, along with the whole topic of macros, out of
the report.  That way we could experiment with various ways of doing
things and at some point agree on the most practical way of dealing
with the situation.

(I was going to suggest that we require keywords to begin with an
upper-case letter so that portable code could be written by employing
only lower-case variable names, but I remembered that Scheme is case-
insensitive.  Sigh...)

Kent


∂11-Jun-86  1021	@MC.LCS.MIT.EDU:TIM%upenn.csnet@CSNET-RELAY.ARPA 	Scheme for AI based CAI  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jun 86  10:21:30 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 11 Jun 86 13:16:10 EDT
Received: from [1100455600] by CSNET-RELAY.ARPA id ac01092; 11 Jun 86 13:05 EDT
From: Tim Finin <Tim%upenn.csnet@CSNET-RELAY.ARPA>
Subject: Scheme for AI based CAI
To: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Date: Wed, 11 Jun 86 12:59 EDT


What follows is a msg from Mark Richer via the AIED digest concerning the
use of Scheme for building AI based educational systems.  I've included my
response.  Others may have relevant thoughts to share with him.

Tim
--------------------------------------------------------------------------

From: Mark Richer <RICHER@SUMEX-AIM.ARPA> on Wed 11 Jun 1986 at 12:00
To:   ai-ed-outgoing@SUMEX-AIM.ARPA
Subj: 1:8 Scheme; AI-ED questionnaire

AI-ED Digest          Tuesday, 10 June 1986       Volume 1 : Issue 8

Today's Topics: Scheme, anyone?
		AI and Education questionnaire		

Date: Tue 10 Jun 86 08:29:38-PDT
From: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Subject: Scheme, anyone?

I have been asked to give advice regarding the appropriateness of using
Scheme for a development effort in Intelligent Computer Assisted Instruction.
Although this is partly a research effort also, a clear goal is testing
and installing the software in high school classrooms.  The hardware available
to this project is HP workstations.

Admittedly I know little about Scheme.  However, my initial reaction is that
no advantages Scheme could provide over CommonLisp could offset the
disadvantages of using a language without a large user base for the
purposes of software development and installation.  CommonLisp
promises to offer portability (of course there are still problems, e.g.,
graphics) and a large user community, and has other obvious advantages 
because of the general acceptance of Lisp in the U.S. AI community.

I'd appreciate some feedback from people that are familiar with Scheme,
particularly if you have used it for developing a large AI-based system.
Can any argument be presented to justify the resources necessary to train
people in Scheme and build and maintain a system in this UnCommonLispLike
language? In other words, what is so special about Scheme compared to
CommonLisp?

Mark

... rest of digest deleted ...
-------------------------------------------------------------------------

From: Tim Finin <Tim@upenn> on Wed 11 Jun 1986 at 12:49
To:   Mark Richer <RICHER@SUMEX-AIM>
Cc:   Bonnie Webber <bonnie@upenn>, Ai Bulletin Board <scheme@upenn>
Subj: Scheme

Here are some thought on Scheme vs. CommonLisp.  We use Common Lisp in our
research efforts (mostly) and Scheme as an instructional language.  We are
using it in both our graduate and undergraduate programs in the core
software/programming languages courses.

  Scheme is Lisp.  More precisely, Scheme is what Lisp should be modulo some
  software engineering arguments.  I think that the biggest influence on the
  development of Common Lisp was the success of Scheme as a language. The
  differences between common Lisp and scheme, as programming languages, at
  this point, are mostly surface level phenomina.  Common Lisp does have a
  much much bigger base of existing software, however.  
  
  Scheme will be the Pascal of the 90's. Scheme is fairly standardized.  There
  are a number of good implementations (CScheme, PC-Scheme, Chez Scheme,
  MacScheme) and all ashere to the unofficial standard (The Revised Revised
  Report on Scheme). I think it will be used in most of the good CS
  undergraduate programs in a few years to teach basic concepts of
  programming.  Common Lisp, I believe, will not be used in this way.  Thus,
  you can expect to see an increasing "user base".
  
  Scheme is simple. Scheme is inherently simpler and smaller than common lisp.
  There is some truth to the equation of sheme/commonlisp = pascal/ada.  I
  think Scheme will be a beter deliverey vehicle for AIED systems.  It will be
  hard to sell these systems if they need an HP Bobcat or a Vaxstation to run
  them.  It will be easy to sell them if they run on a PC or a MAC.  
  
I hope these thought are relevant.  Tim.


∂11-Jun-86  1145	@MC.LCS.MIT.EDU:FAHLMAN@C.CS.CMU.EDU 	Scheme for AI based CAI    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jun 86  11:45:20 PDT
Received: from C.CS.CMU.EDU by MC.LCS.MIT.EDU 11 Jun 86 14:40:44 EDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 11 Jun 86 14:37:45-EDT
Date: Wed, 11 Jun 1986  14:37 EDT
Message-ID: <FAHLMAN.12214016709.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Tim Finin <Tim%upenn.csnet@CSNET-RELAY.ARPA>
Cc:   scheme@MC.LCS.MIT.EDU
Subject: Scheme for AI based CAI


I've been involved pretty deeply in the Common Lisp design effort for
several years.  For what it's worth, I agree with most of what Tim Finin
said about Common Lisp vs. Scheme for education.  Common Lisp has a lot
of ugly things in it that are there for compatibility with older Lisps,
for efficiency on certain machines, and for support of large systems.
There are a lot of features built into Common Lisp that increase the
conceptual load on the first-time user, but that are valuable for the
experienced user who has to do a big job in a hurry.

Scheme is smaller, cleaner, and more willing to break with some of the
bad ideas of the past.  I would use Common Lisp for any really big job,
especially if it needs to be portable to a lot of machines.  At some
point, if I were training students to go out into the world and design
intelligent systems, I'd make sure that they were exposed to Common
Lisp.  But for teaching the fundamental principles of Computer Science,
Scheme provides equal or better support, with many fewer distracting
features and mis-features.

I think that students trained in Scheme would have no trouble learning
Common Lisp later, though it would be useful to warn them about the
separate function and value namespaces in Common Lisp before they get
too used to Scheme's way of doing things.  And I'd try not to present
Scheme in such a way that the students will be too pure to deal with a
"dirty" language like Common Lisp when the time comes.  Some of that
dirt is there for a reason, and the rest is the price we had to pay to
make Common Lisp a widely agreed-upon standard.

In the long run, I don't think that the need for a larger machine to run
Common Lisp will matter: the only real difference in resource needs is
that Common Lisp needs a couple of megabytes more than Scheme (either
real or virtual memory will do) to hold the full language, and that
difference tends to wash out once megabit memory chips start turning up
as the prize in Cracker Jacks.  But for the next year or two, the choice
on the smallest machines will be between a full Scheme and a very
stripped down Common Lisp, and under those conditions Scheme wins.

I hope that Scheme won't become the Pascal of the 90's.  I hate Pascal.

-- Scott Fahlman


∂13-Jun-86  0956	@MC.LCS.MIT.EDU:mmeyer%tilde%ti-csl.csnet@CSNET-RELAY.ARPA 	Revised↑3 Draft Comment  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 13 Jun 86  09:54:35 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 13 Jun 86 12:33:09 EDT
Received: from ti-csl by csnet-relay.csnet id ao20650; 13 Jun 86 12:26 EDT
Received: by tilde id AA27555; Fri, 13 Jun 86 10:44:00 cdt
Date: Fri, 13 Jun 86 10:44:00 cdt
From: Mark Meyer <mmeyer%tilde%ti-csl.csnet@CSNET-RELAY.ARPA>
To: RRRS-authors%mit-mc@CSNET-RELAY.ARPA
Subject: Revised↑3 Draft Comment
Cc: mmeyer%ti-csl.csnet@CSNET-RELAY.ARPA

 
 
     In going over the grammar in the Revised↑3 Report for numbers in
Scheme, I noticed a possible omission.  According to the production
     <ureal R> --> <prefix R> <digit R>+ #* / <digit R>+ #* <suffix>
the production of rationals, 1/2e3 is legal syntax while 1e3/2 is not.
Shouldn't the production be amended to 
     <ureal R> -->
       <prefix R> <digit R>+ #* <suffix> / <digit R>+ #* <suffix>
so that the numerator as well as the denominator may carry a suffix?
In that case, 1/2e3 would mean 1/2000 and 1e3/2 would be 1000/2 (=500).

Mark Meyer
(mmeyer@ti-csl)



∂15-Jun-86  1251	@MC.LCS.MIT.EDU:cth%indiana.csnet@CSNET-RELAY.ARPA 	Logic Continuations (Abstract)   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jun 86  12:51:40 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Jun 86 15:47:20 EDT
Received: from indiana by csnet-relay.csnet id ah03896; 15 Jun 86 15:44 EDT
Date: Sun, 15 Jun 86 11:44:22 est
From: Chris Haynes <cth%indiana.csnet@CSNET-RELAY.ARPA>
To: scheme@MC.LCS.MIT.EDU
Subject: Logic Continuations (Abstract)

The following abstract of a paper, to be delivered at the Third International
Conference on Logic Programming (London, July 1986), may be of interest to the
Scheme community.  The paper is also available as Indiana University Computer
Science Department Technical Report No. 183, and is to appear in The Journal
of Logic Programming in a somewhat revised from.


			    Logic Continuations

			   by Christopher Haynes

We develop a `complete' embedding of logic programming into Scheme---a
lexically scoped Lisp dialect with first-class continuations.  Logic
variables are bound in the Scheme environment and the success and failure
continuations are represented as Scheme continuations.  To account for the
semantics of logic variables and failure continuations, the state-space model
of control is modified in a novel way that generalizes the trail mechanism.
This assures that logic variable bindings are properly restored when
continuations are invoked to perform `lateral' control transfers that are not
possible in a traditional logic programming context.  It is thereby possible
to obtain greater control over logic program behavior by using continuations
as first-class objects.  


∂17-Jun-86  1621	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Number syntax  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jun 86  16:20:57 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 17 Jun 86 19:19:56 EDT
Received: from ti-csl by csnet-relay.csnet id ao17298; 17 Jun 86 18:51 EDT
Received: by tilde id AA27184; Tue, 17 Jun 86 17:08:11 cdt
Date: Tue 17 Jun 86 16:00:31-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Number syntax
To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
Message-Id: <12215615581.31.BARTLEY@CSC60>

One irritant in the Report that we have neglected to comment on until
now (sorry!) is the syntax of numbers.  We believe that Scheme numbers
are essentially equivalent to Common Lisp numbers except for the new
notion of exactness.  To the extent that that is so, it seems to be a
(shudder!) ``gratuitous difference'' from Common Lisp to have an
incompatible syntax.

The R↑3RS doesn't make clear which subset of the syntax of numbers is
essential and what is optional.  As implementors of systems in which
Scheme and Common Lisp must co-exist, we're faced with two potential
compatibility issues: (1) going with an ``extended subset'' of the
Report's number syntax that is compatible with Common Lisp, or (2)
going with the full number syntax in the Report to be compatible with
all other Scheme implementations.

What we'd like to see is an essential syntax for numbers which is
compatible with Common Lisp's.  Additional features, including
exactness, would be optional extensions.  Even so, they should not
conflict with Common Lisp.  For example, the use of `#s' and the order
of <sign> and <prefix> are different in the two languages.

Our motivation, of course, is that we'd like programmers to feel free to
use either language and exchange files of data without irritating
obstacles being thrown in their path.  If we can't agree on a
consistent syntax for numbers, then we'll have to provide each language
with two readers and the user will have to know which one to use.

(There are other problems, of course, such as whether `:' is a
constituent of an identifier or associated with Common Lisp package
designations.  We may have to go with separate readers/modes anyway.)

Does anyone agree with us?  Is there time to make such a change before
R↑3RS goes to press?

Regards,
David Bartley,
Mark Meyer
-------


∂17-Jun-86  1909	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Number syntax  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jun 86  19:09:05 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUN 86  21:46:55 EDT
Received: from AI.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 17 JUN 86  21:46:13 EDT
Date: Tue, 17 Jun 86 21:44:45 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Number syntax
To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
cc: RRRS-Authors@MX.LCS.MIT.EDU
In-reply-to: Msg of Tue 17 Jun 86 16:00:31-CDT from David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].58406.860617.JAR>

    Date: Tue 17 Jun 86 16:00:31-CDT
    From: David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>

    Does anyone agree with us?  Is there time to make such a change before
    R↑3RS goes to press?

I agree with you, but I don't have anything at stake.  If we can come to
an agreement to change, I'd be happy to make the change.

As far as time goes, I have yet to call Wexelblat again to find out the
next deadline, buI imagine it will be the first week of July (for the
September issue).  I need to get a clean copy out to everyone at least,
say, 10 days before SIGPLAN's deadline, so that means we should try to
get stability by circa June 25.  I'll aim for that, but of course my aim
has not been good in the past.

Jonathan

∂17-Jun-86  1912	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Policy on change-making  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jun 86  19:10:31 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUN 86  22:10:52 EDT
Received: from AI.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 17 JUN 86  22:10:08 EDT
Date: Tue, 17 Jun 86 22:08:58 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Policy on change-making
To: rrrs-authors@MX.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].58425.860617.JAR>

A number of suggestions for incompatible changes are currently on the
floor.  Before I start polling y'all about these various questions
(mostly removals), I would like to see if we can reach concensus on what
our policy should be for making such incompatible changes.  I think the
policy we adopt will bear on the changes we decide we want to make.
Questions that should be answered:

- How radical ought we to be?  That is, how important is compatibility with
last summer's report?

- Given that there will be incompatible changes, how should these be
indicated in the report?  Should I clutter the main text with little
notes; should I make a list of all the changes; if I make such a list,
where should it appear --- in the "notes" section, in the introduction,
somplace else?    Should the list include rationales

I guess my current bias is either to omit the list entirely or relegate
it to the notes section, in pursuit of a "crisper" [Dan Friedman's word]
document.  However, I again have nothing at stake, and don't care too
much, so people with real implementations should speak up.

Changes and removals (as opposed to clarifications or extensions) so far
agreed upon include the omission of the "object table" chapter, the
omission of all the #!foo constants, and the change in meaning of
(define (foo ...) ...)  [from using named-lambda to using lambda].  We
have already decided on some others, and may decide on others still, in
the coming weeks.

What other documents do:  The Revised Report on Scheme has pretty
thorough notes about how the language changed, with complete rationales.
The revised Algol 60 report merely enumerates, in a footnote, the
section numbers of sections that were changed at the 1962 conference.
The Algol 68 report has a comparison with Algol 60 (3 pages) as part of
its introduction, and the Revised Algol 68 report also has a comparison
with the non-revised Algol 68 report (4 pages).


Jonathan

∂18-Jun-86  2144	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  Number syntax
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 18 Jun 86  21:44:39 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 19 Jun 86 00:44:37 EDT
Received: from indiana by csnet-relay.csnet id ac01244; 19 Jun 86 0:38 EDT
Date: Wed, 18 Jun 86 17:53:13 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: bartley%ti-csl.csnet@CSNET-RELAY.ARPA, jar@MC.LCS.MIT.EDU
Subject: Re:  Number syntax
Cc: rrrs-authors@MC.LCS.MIT.EDU

I'm all for the modifications David and Mark suggest...the same issues
have been annoying me, although I have no stake in Common Lisp.  I
suggest that David send out another letter with the wording/syntax he
wants to make things easier for Jonathan.


∂20-Jun-86  0202	@MC.LCS.MIT.EDU:JINX@OZ.AI.MIT.EDU 	Policy on change-making 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 19 Jun 86  20:01:53 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 19 JUN 86  23:02:27 EDT
Received: from OZ.AI.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 19 JUN 86  23:01:11 EDT
Date: 18 Jun 1986  14:33 EDT (Wed)
Message-ID: <JINX.12215850914.BABYL@MIT-OZ>
From: Bill Rozas <JINX@OZ.AI.MIT.EDU>
To:   Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc:   rrrs-authors@MX.LCS.MIT.EDU
Subject: Policy on change-making
In-reply-to: Msg of 17 Jun 1986  22:08-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>

My feelings:

- Don't be unneccessarily radical, but fix things which are broken,
and change things to reflect the new consensus (if there is one).

- I would like the incompatibilities mentioned in the notes section.

∂23-Jun-86  1412	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Bibliography   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 23 Jun 86  14:12:10 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 JUN 86  17:13:15 EDT
Date: Mon, 23 Jun 86 17:11:43 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Bibliography
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].60539.860623.JAR>

I would like to update the "bibliography and references" section of
the report.  If you have published new papers on Scheme-related topics
in the past year, or if you will have done so within the next few
weeks, or if you're aware of something which ought to be included,
please send me a complete, accurate reference, or an incomplete
reference and enough information for me to be able to track it down.

Already on my list of things to include are:

- Felleison et al, Reasoning with Continuations (Logic in CS conf)
- Kranz et al, ORBIT compiler (Compiler Construction conf)
- Feeley, Deux approches a l'implantation du langage Scheme (masters
  thesis, Montreal)

but I'm sure there are many others.

Also, send your index entry suggestions.

Jonathan

∂26-Jun-86  2114	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Remaining questions & remarks (2)  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 Jun 86  21:14:31 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 JUN 86  00:16:04 EDT
Received: from LIVE-OAK.LCS.MIT.EDU by MX.LCS.MIT.EDU via Chaosnet; 27 JUN 86  00:14:00 EDT
Received: from JOE-LOUIS.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 3220; Thu 26-Jun-86 19:04:00-EDT
Date: Thu, 26 Jun 86 19:03 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: Remaining questions & remarks (2)
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <"860626190326.1.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>


Almost no one answered my query about grandfathering.  Think about it
while answering the questions below.  I propose listing incompatibilites
in the "notes" section, and otherwise not worrying too much about the
incompatibilities we're introducing.  I'll send out a list of known
language changes in a separate message.

Here is the second list of remaining questions and remarks.  Some of
these may be duplicates.
 
1.  BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report;
    it's obvious to the world we couldn't get consensus on this one.
    Many people have told me that they don't care which one is there, so
    long as there's only one.  SEQUENCE was used heavily in S&ICP and
    for that reason I think it should be retained; thus the options I
    offer are
      (a) leave things as they are (BEGIN essential with non-essential
	  synonym SEQUENCE),
      (b) remove BEGIN and make SEQUENCE essential (noting in the Notes
	  section that BEGIN, like #!TRUE etc., should be supported by
	  those implementations which care about running code written in
	  the past year).
    Let me know your vote if you haven't done so already.
 
2.  Similarly but less glaringly, we have a problem with the numeric
    comparisons.  Again, many people have said they don't care but they only
    want one set, with or without question marks.  Thus I offer
    the choices
      (a) leave things as they are
      (b) flush the alternative names  <? <=? >? >=? =?
    [The ones without question marks were used in S&ICP; moreover, they
    exist in other Lisp dialects.  The argument in favor of the ?'s is that
    it allows the simple statement: "names of predicates end in question mark".]
    Send me your vote.
 
3.  REC and NAMED-LAMBDA :
    Again, I sense capitulation on the part of some who have been stubborn.
    The only options permitted are:
      (a) Keep both
      (b) Flush both
    My editorial sense is that we should be able to achieve (b).  Remember,
    the language also doesn't have EVAL, environments, or macros, so if you
    want to keep these features please say how they're different from other
    "indispensible" features that the language DOESN'T have.
 
4.  SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :
    Many people have suggested removing these.  Anyone who wants them
    retained MUST provide a convincing rationale, for inclusion in the
    report.  Otherwise I'll remove them.
 
5.  Should we say anything about the possibility of parallel or
    interleaved argument evaluation?  Remembering something I thought I
    heard Will once say, I added the innocent little phrase "or perhaps
    in parallel" to the description of procedure calling.  Richard
    Kelsey quickly pointed out that if it's mentioned as being a
    possibly legal implementation, many otherwise valid scheme programs
    may fail to run in implementations which do this, because they won't
    do necessary synchronization.  I agree; this is acceptable only if
    we provide synchronization primitives. 
 
6.  Number input exactness: two proposals have been advanced to decide whether
    a number is exact or inexact if it has no #I or #E prefix and contains no
    trailing #'s.
      (a) Inexact if there are digits following a decimal point, or if exponential
	  notation is used.  Otherwise exact.  (This makes exctness similar to
	  "floatness" in CL.)
      (b) A proposal which Will advanced, which I'm unable to locate right now, so he'll
	  have to re-send it.
    I'll additionally advance another alternative, and you can make up more of
    your own:
      (c) Always exact.  E.g. "1.2" is exact.
 
7.  Must a port still be a port (i.e. answer true to INPUT-PORT? or OUTPUT-PORT?)
    after being closed?
 
8.  Apparently there's no difference between ABS and MAGNITUDE.  Should we
    keep both?  If so, should I change the presentation in any way?
 
9.  ANGLE is what Common Lisp calls PHASE; any interest in changing the
    name? ...
 
10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
    can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)).  Do we
    apply Occam's razor and remove it?  If it's retained, then I'll just
    document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).

11. JINX says: if PROCEDURE? exists, then a portable printer can be written.
    JAR replies (in jest):
      (define procedure?
	(lambda (obj)
	  (not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...))))
    Seriously however, I was the only holdout at Brandeis against having
    this predicate.  After thinking about this further I think it's not such
    a bad idea, even though it is of limited use.  Is anyone opposed to
    having an essential procedure PROCEDURE?, to round out the set of type
    predicates?

12. (if x 1) vs.  (cond (x 1)) -- this is inconsistent, as a couple of people
    have pointed out.  I would expect these two expressions to have the
    same meaning, but they don't.  The first is defined to always return
    an unspecified value.  The second is defined to return the value 1
    if x is true, and an unspecified value otherwise.  I would like to
    make this consistent, and there are two ways to do.  Take your pick:
      (a) Change IF expressions so that they return the value of the
	  second form if the first form evaluates to false.
      (b) Change COND and CASE so that they return an unspecified value if
	  there is no ELSE clause.
    Here are some arguments in favor of (a):  
     - It removes the possibility of inferring that an implementation might
       not be tail-recursive through an alternate-less IF.
     - Similarly, it makes (IF #T <exp>) mean the same as <exp>, and removes
       doubt about the meaning of things like (if x (if y 1) z).
     - It simplifies the macro expansion of COND as compared with (b).
     - Option (b) is obviously undesirable (consider the case of mutually
       exclusive test expressions in a COND).

13. Many people would like to see the (define ((((a b) c) d) e) ...)
    feature go away.  S&ICP doesn't use it, and it has a rather complicated
    syntax (look at the BNF for evidence).  Vote keep or flush.

14. Status of LOAD not resolved.  If, as I suggested, LOAD is only
    to be syntactically valid at top level of a file, shouldn't it be
    renamed to be INCLUDE ?

15. Page breaks and tabs are mentioned in the report (actually I guess I
    added them - sorry), but there are no #\PAGE or #\TAB characters.
    Can this be made consistent by documenting #\PAGE and #\TAB, or
    should I try to neutralize or remove the places where I mention tabs
    and page breaks, by saying something to the effect that there may be
    other whitespace characters, and some of these characters might
    terminate comments?  In Common Lisp, #\PAGE and #\TAB aren't
    "standard", they're only semi-standard; and I don't believe that

16. If page breaks are documented, should the terminate comments?  I think
    they should (but of course they don't in Common Lisp).

17. Bartley says: "the second sentence of the description of EQUAL? should
    say that EQV? is used for all objects except pairs, vectors, and
    strings."  Forcing it to use EQV? seems kind of random to me.  This
    would of course make my notion of "apparent equivalence" useless,
    destroying what I deluded myself into thinking was an elegant symmetry
    between EQV? and EQUAL?; maybe it's a bogus idea anyhow.  I
    intentionally wanted to be silent on this point, allowing EQUAL? to
    return true more often than EQV? perhaps, but I don't care that much.


-----

Presentation questions:

18. Several people have complained about Clinger's perhaps overly accurate
    description of what happens when variables become bound.  To be
    accurate, we have to say that locations are created and the initial
    value is stored in the location, but this doesn't sit well with the
    desire to have Scheme sound like an almost-functional language.
    What to do?
    
19. What should the dedication be?  Sussman suggested the PDP-6, which was
    the world's first Lisp machine, but some people didn't like this joke.
    I have changed it to Christopher Strachey in the draft.
    
20. Is it OK to replace "Lazy ML" with "SASL" (last paragraph of section
    0.0)?  This is Dan Friedman's suggestion and I approve; SASL is more
    widely known.  I've never heard of Lazy ML (although I can imagine what
    it is).
    
21. Should section numbers be zero-based?  I'm beginning to think this looks
    unprofessional; and it just doesn't look right in several places.  It
    worked well in the previous version of the report, and it's clearly more
    consistent with the language (which is zero-based), but it doesn't work
    the way I've reorganized things.  If you like zero-based section
    numbers, speak up.
    
22. Was Scheme the first programming language to have first-class lexical
    closures?  Can we say anything edifying along these lines?
    
23. I flushed the historical note "CATCH could be provided by a procedure"
    sentence (again, because two or three people thought it was random and I
    agreed), but some of you have complained about this.  Why should this
    bit of history be present, but not others that are at least as
    important?
    
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS.  I
    flushed the reference because (a) a number of people find the name
    CALL/CC quite distasteful and (b) it is inconsistent to mention here
    that some scheme implementations provide an alternate name for this but
    not also do so for LABELS, BLOCK, and a zillion other things.
    
25. How best to resolve the inconsistencies between terminology in text and
    semantics?  Namely: "I", "Ide", "identifier" in semantics vs. "variable"
    in text; "Com", "command" in semantics vs. "statement" in text.
    
26. FORCE & DELAY are still problematic.  About half of respondents said it
    was better to put FORCE up front with DELAY, and the other half thought
    it was fine as it was.  No one gave convincing arguments.
    
27. Is 3.0.2 (description of procedure calls) a good place to take note that
    () is not a valid procedure call?
    
28. In section 0.0, 2nd paragraph, before the terms "variable" and
    "identifier" have been defined, it should say "variable" instead of
    "identifier" to be consistent with the rest of the report.  Is that OK?
    
29. There are two nonterminals in the BNF that need names.  Currently they
    are called <formals> and <formalz> which was never intended to be a
    serious suggestion (I put it there to see if anyone would actually read
    the BNF!).  Actually one or both of these can go away if NAMED-LAMBDA
    and/or (DEFINE ((( ...) ...) ...) ...) go away.  Can someone who likes
    these things take a look at the BNF and suggest names for these?
    
30. Someone wanted me to avoid discussion of immutable objects in the
    discussion of operational equivalence in the 2nd paragraph before entry
    for EQV? .  I want to mention immutability there because I think it's
    important to warn users that this might be the case, otherwise they can
    easily end up writing unportable code.




-----

For your information, here are changes I've made that either don't seem
controversial or reflect what I judged to be the consensus:


Language:

Only one empty list, period.  (eq? '() '()) returns true.

Kelsey asks: why does ROUND round to even?  Answer: Common Lisp does it
this way.  Ask Steele.  Probably this has to do with statistical
niceness.

A port does not become closed as a side effect of reaching end of file.
After end of file, you'll continue to read end of file objects as long
as the port is open.  It's an error to read from or write to a closed
port.

DISPLAY writes characters like WRITE-CHAR does.

-----

Presentation:

"Iterative process" --> "iterative computation" on page 3 (this change
is an example of "desussmanization").

Inserted the following sentence in section 1.0:
"In addition, \ide{+}, \ide{-}, \ide{1+}, and \ide{-1+} are identifiers."

At Dan Friedman's request, I removed Perlis from the list of authors.

Changed <? and >? to < and > in all examples.

Removed non-essential features from examples (including the big one)
where possible:  (1+ x) --> (+ x 1), (-1+ x) --> (- x 1), (define (foo
...) ...) --> (define foo (lambda ...)), 1-armed if --> cond, named let
--> letrec.

Changed variable name "loop" to "recur" in the
call-with-current-continuation example.

"iff" --> "if" in section 5.1.

-----

That's all for now, folks...

Jonathan

∂27-Jun-86  0943	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	r3rs presentation  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jun 86  09:42:55 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 27 Jun 86 12:44:13 EDT
Full-Name: 
Organization: The MITRE Corp., Bedford, MA
Received: from jymme.sun.uucp by linus.MENET (1.1/4.7)
	id AA00559; Fri, 27 Jun 86 11:38:01 EDT
Posted-Date: Fri, 27 Jun 86 11:37:13 edt
Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3)
	id AA19250; Fri, 27 Jun 86 11:37:13 edt
Date: Fri, 27 Jun 86 11:37:13 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8606271537.AA19250@jymme.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: r3rs presentation

I went on vacation and then I had trouble getting the r3rs.tar file.
By the time I sat down to read the report, I found my Scheme mail had
grown to 100 printed pages!  We have a solid group of committed people.

I would like to make a few comments on presentation.  The most
important comment is about section organization.  Newspaper writers
spend most of their time writing the first three paragraphs of any
article.  This part of the article is often the only part read by
readers, and is important in enticing readers to continue.  In the
same way, The first page is most likely to be the only page read by
many SIGPLAN readers.  If I had my choice of what I would ask them to
read, it would be the material in Section 0.0, the Semantics section
that notes that scheme is lexically scoped, tail recursive, weakly
typed, ... etc.  I would expand on the discussion on continutations,
as they represent one important difference between Scheme and other
languages.  The Introduction, with its history of scheme, its history
of scheme reports and meetings, and acknowledgements giving names of
people that the reader will not likely know, is not that one page I
would like all to read.  I suggest moving the history to the back of
the report, and use the first couple of pages to convince the reader
that the language documented in this report is worth studying.

On less significant presentation issues, I would like to present a
view that a less sophisicated user of Scheme may get about
continuations.  That is, this reader may conclude that continuations
are very powerful and always expensive to use.  I know that the T
compiler of 1981 generated goto's from the a catch and throw
expression that exited a loop from within a loop.  (Catch and throw is
old syntax for using continuations.)  Since we promise that
tail-recursive procedures are executed in constant space, can't we
promise something about certain simple uses of continuations?
Otherwise, they may avoided by programmers for the wrong reasons.

Random notes

[pg. 6, col. 2, +15]  In the term "meta-program" well known?

[pg. 30, col. 1]  Some note is needed explaining why there are two
different close procedures.

[pg. 29]  If call-with-current-continuation calls its argument with
the current continuation, should the I/O routines call-with-input-file
and call-with-output-file be renamed call-with-input-port and
call-with-output-port? 

John

∂27-Jun-86  1115	@MC.LCS.MIT.EDU:gls@Think.COM 	Remaining questions & remarks (2) 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jun 86  11:08:13 PDT
Received: from Godot.Think.COM by MC.LCS.MIT.EDU 27 Jun 86 13:39:25 EDT
Received: from boethius by Godot.Think.COM via CHAOS; Fri, 27 Jun 86 13:36:07 edt
Date: Fri, 27 Jun 86 13:37 EDT
From: Guy Steele <gls@Think.COM>
Subject: Remaining questions & remarks (2)
To: JAR@MIT-AI.ARPA, rrrs-authors@MIT-MC.ARPA
Cc: gls@AQUINAS
In-Reply-To: <"860626190326.1.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
Message-Id: <860627133714.3.GLS@BOETHIUS.THINK.COM>

    Date: Thu, 26 Jun 86 19:03 EDT
    From: Jonathan A Rees <JAR@MIT-AI.ARPA>
 
    1.  BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report;
	it's obvious to the world we couldn't get consensus on this one.
	Many people have told me that they don't care which one is there, so
	long as there's only one.  SEQUENCE was used heavily in S&ICP and
	for that reason I think it should be retained; thus the options I
	offer are
	  (a) leave things as they are (BEGIN essential with non-essential
	      synonym SEQUENCE),
	  (b) remove BEGIN and make SEQUENCE essential (noting in the Notes
	      section that BEGIN, like #!TRUE etc., should be supported by
	      those implementations which care about running code written in
	      the past year).
(b)
 
    2.  Similarly but less glaringly, we have a problem with the numeric
	comparisons.  Again, many people have said they don't care but they only
	want one set, with or without question marks.  Thus I offer
	the choices
	  (a) leave things as they are
	  (b) flush the alternative names  <? <=? >? >=? =?
(b)
    
    22. Was Scheme the first programming language to have first-class lexical
	closures?  Can we say anything edifying along these lines?

Don't forget, of course, to say that Algol 60 came real close.  I think you
should research the languages GEDANKEN (Reynolds) and ISWIM (Landin), as one
of those might have had closures.  I believe ISWIM was described in CACM in
the mid-1960's.

    Kelsey asks: why does ROUND round to even?  Answer: Common Lisp does it
    this way.  Ask Steele.  Probably this has to do with statistical
    niceness.

ROUND rounds to even because the integer "rounding modes" (floor, ceiling,
round, truncate) were chosen to correspond to the rounding modes required by
the IEEE floating point standard.  That standard in turn mandates rounding
to even for what indeed amounts to statistical niceness: on the average the
effects of rounding tend to cancel out.  Why round to even instead of odd?
Then further operations on those results are more likely to be exactly
representable and therefore not require further loss of accuracy due to
rounding.

--Guy

∂27-Jun-86  1653	@MC.LCS.MIT.EDU:SGR@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	[INGRIA@G.BBN.COM: Scheme for LISPM]    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jun 86  16:53:02 PDT
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 27 Jun 86 19:40:24 EDT
Received: from GROUSE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 31612; Fri 27-Jun-86 17:02:04 EDT
Date: Fri, 27 Jun 86 17:02 EDT
From: Stephen G. Rowley <SGR@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [INGRIA@G.BBN.COM: Scheme for LISPM]
To: Scheme@MIT-MC.ARPA
Message-ID: <860627170237.3.SGR@GROUSE.SCRC.Symbolics.COM>

This sounds like a question for people on this list:

Date: Thu, 26 Jun 1986  16:47 EDT
Message-ID: <INGRIA.12217972484.BABYL@G.BBN.COM>
From: INGRIA@G.BBN.COM
To:   INFO-LISPM@MC.LCS.MIT.EDU
Subject: Scheme for LISPM


	Does anyone have an implementation of Scheme that runs on
LISPMs?  It would be useful for us to have a version that runs on Rel6
on 36XXs.  Thanks in advance.

-30-
Bob



∂27-Jun-86  1930	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	typo 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jun 86  19:30:29 PDT
Received: from VAIL.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 27 JUN 86  22:28:27 EDT
Date: Fri, 27 Jun 86 22:29 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: typo
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <860627222941.1.JAR@VAIL.LCS.MIT.EDU>

Of course I meant "return the value of the second form if the first
evaluates to *true*," not false.

∂27-Jun-86  2142	@MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA 	Grandfathering Responses 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Jun 86  21:42:00 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Jun 86 00:38:15 EDT
Received: from indiana by csnet-relay.csnet id aa23894; 28 Jun 86 0:36 EDT
Date: Fri, 27 Jun 86 11:09:20 est
From: Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Grandfathering Responses

1.  BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report;
    it's obvious to the world we couldn't get consensus on this one.
    Many people have told me that they don't care which one is there, so
    long as there's only one.  SEQUENCE was used heavily in S&ICP and
    for that reason I think it should be retained; thus the options I
    offer are
      (a) leave things as they are (BEGIN essential with non-essential
	  synonym SEQUENCE),
      (b) remove BEGIN and make SEQUENCE essential (noting in the Notes
	  section that BEGIN, like #!TRUE etc., should be supported by
	  those implementations which care about running code written in
	  the past year).
    Let me know your vote if you haven't done so already.

*****>>  (a) 
 
2.  Similarly but less glaringly, we have a problem with the numeric
    comparisons.  Again, many people have said they don't care but they only
    want one set, with or without question marks.  Thus I offer
    the choices
      (a) leave things as they are
      (b) flush the alternative names  <? <=? >? >=? =?
    [The ones without question marks were used in S&ICP; moreover, they
    exist in other Lisp dialects.  The argument in favor of the ?'s is that
    it allows the simple statement: "names of predicates end in question mark".]
    Send me your vote.

******>>  (b)

3.  REC and NAMED-LAMBDA :
    Again, I sense capitulation on the part of some who have been stubborn.
    The only options permitted are:
      (a) Keep both
      (b) Flush both
    My editorial sense is that we should be able to achieve (b).  Remember,
    the language also doesn't have EVAL, environments, or macros, so if you
    want to keep these features please say how they're different from other
    "indispensible" features that the language DOESN'T have.

Named-lambda is totally unacceptable.
Letrec is often overkill and without macros we will be left
with using it.  Rec is an incredibly powerful tool.  I'd hate
to lose it from my repertoire.  However, named-lambda is an
ugly so I am forced, given these choices, to opt for (b).
 
4.  SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :
    Many people have suggested removing these.  Anyone who wants them
    retained MUST provide a convincing rationale, for inclusion in the
    report.  Otherwise I'll remove them.

****>> Remove them
 
5.  Should we say anything about the possibility of parallel or
    interleaved argument evaluation?  Remembering something I thought I
    heard Will once say, I added the innocent little phrase "or perhaps
    in parallel" to the description of procedure calling.  Richard
    Kelsey quickly pointed out that if it's mentioned as being a
    possibly legal implementation, many otherwise valid scheme programs
    may fail to run in implementations which do this, because they won't
    do necessary synchronization.  I agree; this is acceptable only if
    we provide synchronization primitives. 

****>> Yes, either provide synchonization primitives or flush the comment
 
8.  Apparently there's no difference between ABS and MAGNITUDE.  Should we
    keep both?  If so, should I change the presentation in any way?

*****>> don't keep both.
 
9.  ANGLE is what Common Lisp calls PHASE; any interest in changing the
    name? ...

*****>> I agree with the consensus.
 
10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
    can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)).  Do we
    apply Occam's razor and remove it?  If it's retained, then I'll just
    document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).

*****>> follow Occam's razor here.

11. JINX says: if PROCEDURE? exists, then a portable printer can be written.
    JAR replies (in jest):
      (define procedure?
	(lambda (obj)
	  (not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...))))
    Seriously however, I was the only holdout at Brandeis against having
    this predicate.  After thinking about this further I think it's not such
    a bad idea, even though it is of limited use.  Is anyone opposed to
    having an essential procedure PROCEDURE?, to round out the set of type
    predicates?

*****> include procedure?, but be sure that 
         (call/cc (lambda (k) (k (procedure? k)))) --> #t.

12. (if x 1) vs.  (cond (x 1)) -- this is inconsistent, as a couple of people
    have pointed out.  I would expect these two expressions to have the
    same meaning, but they don't.  The first is defined to always return
    an unspecified value.  The second is defined to return the value 1
    if x is true, and an unspecified value otherwise.  I would like to
    make this consistent, and there are two ways to do.  Take your pick:
      (a) Change IF expressions so that they return the value of the
	  second form if the first form evaluates to false.
      (b) Change COND and CASE so that they return an unspecified value if
	  there is no ELSE clause.
    Here are some arguments in favor of (a):  
     - It removes the possibility of inferring that an implementation might
       not be tail-recursive through an alternate-less IF.
     - Similarly, it makes (IF #T <exp>) mean the same as <exp>, and removes
       doubt about the meaning of things like (if x (if y 1) z).
     - It simplifies the macro expansion of COND as compared with (b).
     - Option (b) is obviously undesirable (consider the case of mutually
       exclusive test expressions in a COND).

****>> I favor including a "(when pred val) as the proper special form
for two branch-if's.  That way two branch-if's would be syntactically
illegal.  I've used them for about a year and I find less bugs creeping
into other's and my own programs.

13. Many people would like to see the (define ((((a b) c) d) e) ...)
    feature go away.  S&ICP doesn't use it, and it has a rather complicated
    syntax (look at the BNF for evidence).  Vote keep or flush.

*****>> flush it.

Presentation questions:

18. Several people have complained about Clinger's perhaps overly accurate
    description of what happens when variables become bound.  To be
    accurate, we have to say that locations are created and the initial
    value is stored in the location, but this doesn't sit well with the
    desire to have Scheme sound like an almost-functional language.
    What to do?

****> Realize that Scheme is not "almost"-functional, it's almost Algol!
      I agree wholeheartedly agree with Will's characterization.
      The best that can be said with respect to the functionality
      of Scheme is that it contains a coherent subset that is "functional".
    
19. What should the dedication be?  Sussman suggested the PDP-6, which was
    the world's first Lisp machine, but some people didn't like this joke.
    I have changed it to Christopher Strachey in the draft.

****> I prefer Christopher Strachey.
    
21. Should section numbers be zero-based?  I'm beginning to think this looks
    unprofessional; and it just doesn't look right in several places.  It
    worked well in the previous version of the report, and it's clearly more
    consistent with the language (which is zero-based), but it doesn't work
    the way I've reorganized things.  If you like zero-based section
    numbers, speak up.

*****> 1-based seems better.
    
22. Was Scheme the first programming language to have first-class lexical
    closures?  Can we say anything edifying along these lines?

*****> Landin's ISWIM was the first well-known one back in the early 60's.
       However, I would guess that the use of "function" in the
       "Lisp 1.5 Programmming Language Manual" should count as
       a first-class closure.  If all "lambda"'s were surrounded by
       (function ...) then LISP 1.5 would model them. Furthermore,
       call/cc can be written with Landin's J operat.
    
23. I flushed the historical note "CATCH could be provided by a procedure"
    sentence (again, because two or three people thought it was random and I
    agreed), but some of you have complained about this.  Why should this
    bit of history be present, but not others that are at least as
    important?  

*****> I won't argue for the history.  However, the implementor who
       thinks that catch (as in Common Lisp) and call/cc are the same
       is in for a shock.  That should perhaps be pointed out.
    
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS.  I
    flushed the reference because (a) a number of people find the name
    CALL/CC quite distasteful and (b) it is inconsistent to mention here
    that some scheme implementations provide an alternate name for this but
    not also do so for LABELS, BLOCK, and a zillion other things.

****> Carolyn Talcott in her dissertation suggested the term "note".
      I could live with that.  If call-with-current-continuation is
      the only term, this will make those of us who write about this object
      uncomfortable. I think we agreed that "call/cc" would be an 
      acceptable abbreviation and I would prefer to keep that name
      in the report.  Those who don't like the name can choose not to use it.
      In a sense I agree with your argument, but "call-with-current
      -continuation has 30 characters in it!, "labels" and "letrec", and
      "block" and "begin" each have the same number of characters.

25. How best to resolve the inconsistencies between terminology in text and
    semantics?  Namely: "I", "Ide", "identifier" in semantics vs. "variable"
    in text; "Com", "command" in semantics vs. "statement" in text.

****> "variable" is a "dangerous" word, try to expunge it.  Opinions differ
    as to what a variable is.
    
26. FORCE & DELAY are still problematic.  About half of respondents said it
    was better to put FORCE up front with DELAY, and the other half thought
    it was fine as it was.  No one gave convincing arguments.

****> I favor join them.  I don't much care where they are joined.
    
28. In section 0.0, 2nd paragraph, before the terms "variable" and
    "identifier" have been defined, it should say "variable" instead of
    "identifier" to be consistent with the rest of the report.  Is that OK?

****> See comment on 26.
    
29. There are two nonterminals in the BNF that need names.  Currently they
    are called <formals> and <formalz> which was never intended to be a
    serious suggestion (I put it there to see if anyone would actually read
    the BNF!).  Actually one or both of these can go away if NAMED-LAMBDA
    and/or (DEFINE ((( ...) ...) ...) ...) go away.  Can someone who likes
    these things take a look at the BNF and suggest names for these?

****> I hope they go away.

Language:

Removed non-essential features from examples (including the big one)
where possible:  (1+ x) --> (+ x 1), (-1+ x) --> (- x 1), (define (foo
...) ...) --> (define foo (lambda ...)), 1-armed if --> cond, named let
--> letrec.

****> I'd still prefer "add1" or "succ" and "sub1" or "pred" to the
abuse of punnery "-1+", and its slightly weaker sibling "1+".
The cuteness of "-1+" should go.  In writing for a mass audience
I have learned that there is a time and a place for clever un-pronouceable
function names.  Please remove them and find pronounceable words


Dan


∂28-Jun-86  1511	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	variable vs. identifier  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Jun 86  15:11:09 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 JUN 86  12:37:38 EDT
Date: Sat, 28 Jun 86 12:36:57 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  variable vs. identifier
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].62926.860628.JAR>

From the messages I've recieved, it apparently wasn't clear why two
distinct words are needed.  I want to make sure that the grammar
reflects the decision that we will leave it up to implementations
(i.e.  leave it "unspecified") just what things like (let ((if ...))
...)  would mean.  So at the very least these expressions have to be
excluded from the grammar.  Therefore one word is needed for things
that are lexically like symbols (and can appear inside of QUOTE
expressions), and another is needed for those things that can be bound
and referred to.  I chose "identifier" for the first and "variable"
for the second.  Thus IF is an identifier but not a variable.  I like
the way this turned out, and can't think of anything else that would
work as well.

∂28-Jun-86  1511	@MC.LCS.MIT.EDU:dfried%indiana.csnet@CSNET-RELAY.ARPA 	Grandfathering response  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Jun 86  15:11:24 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Jun 86 15:49:47 EDT
Received: from indiana by csnet-relay.csnet id aa28825; 28 Jun 86 15:37 EDT
Date: Sat, 28 Jun 86 11:50:33 est
From: Dan Friedman <dfried%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Grandfathering response

1.  BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report;
    it's obvious to the world we couldn't get consensus on this one.
    Many people have told me that they don't care which one is there, so
    long as there's only one.  SEQUENCE was used heavily in S&ICP and
    for that reason I think it should be retained; thus the options I
    offer are
      (a) leave things as they are (BEGIN essential with non-essential
	  synonym SEQUENCE),
      (b) remove BEGIN and make SEQUENCE essential (noting in the Notes
	  section that BEGIN, like #!TRUE etc., should be supported by
	  those implementations which care about running code written in
	  the past year).
    Let me know your vote if you haven't done so already.

*****>>  (a) 
 
2.  Similarly but less glaringly, we have a problem with the numeric
    comparisons.  Again, many people have said they don't care but they only
    want one set, with or without question marks.  Thus I offer
    the choices
      (a) leave things as they are
      (b) flush the alternative names  <? <=? >? >=? =?
    [The ones without question marks were used in S&ICP; moreover, they
    exist in other Lisp dialects.  The argument in favor of the ?'s is that
    it allows the simple statement: "names of predicates end in question mark".]
    Send me your vote.

******>>  (b)

3.  REC and NAMED-LAMBDA :
    Again, I sense capitulation on the part of some who have been stubborn.
    The only options permitted are:
      (a) Keep both
      (b) Flush both
    My editorial sense is that we should be able to achieve (b).  Remember,
    the language also doesn't have EVAL, environments, or macros, so if you
    want to keep these features please say how they're different from other
    "indispensible" features that the language DOESN'T have.

Named-lambda is totally unacceptable.
Letrec is often overkill and without macros we will be left
with using it.  Rec is an incredibly powerful tool.  I'd hate
to lose it from my repertoire.  However, named-lambda is an
ugly so I am forced, given these choices, to opt for (b).
 
4.  SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :
    Many people have suggested removing these.  Anyone who wants them
    retained MUST provide a convincing rationale, for inclusion in the
    report.  Otherwise I'll remove them.

****>> Remove them
 
5.  Should we say anything about the possibility of parallel or
    interleaved argument evaluation?  Remembering something I thought I
    heard Will once say, I added the innocent little phrase "or perhaps
    in parallel" to the description of procedure calling.  Richard
    Kelsey quickly pointed out that if it's mentioned as being a
    possibly legal implementation, many otherwise valid scheme programs
    may fail to run in implementations which do this, because they won't
    do necessary synchronization.  I agree; this is acceptable only if
    we provide synchronization primitives. 

****>> Yes, either provide synchonization primitives or flush the comment
 
8.  Apparently there's no difference between ABS and MAGNITUDE.  Should we
    keep both?  If so, should I change the presentation in any way?

*****>> don't keep both.
 
9.  ANGLE is what Common Lisp calls PHASE; any interest in changing the
    name? ...

*****>> I agree with the consensus.
 
10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
    can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)).  Do we
    apply Occam's razor and remove it?  If it's retained, then I'll just
    document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).

*****>> follow Occam's razor here.

11. JINX says: if PROCEDURE? exists, then a portable printer can be written.
    JAR replies (in jest):
      (define procedure?
	(lambda (obj)
	  (not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...))))
    Seriously however, I was the only holdout at Brandeis against having
    this predicate.  After thinking about this further I think it's not such
    a bad idea, even though it is of limited use.  Is anyone opposed to
    having an essential procedure PROCEDURE?, to round out the set of type
    predicates?

*****> include procedure?, but be sure that 
         (call/cc (lambda (k) (k (procedure? k)))) --> #t.

12. (if x 1) vs.  (cond (x 1)) -- this is inconsistent, as a couple of people
    have pointed out.  I would expect these two expressions to have the
    same meaning, but they don't.  The first is defined to always return
    an unspecified value.  The second is defined to return the value 1
    if x is true, and an unspecified value otherwise.  I would like to
    make this consistent, and there are two ways to do.  Take your pick:
      (a) Change IF expressions so that they return the value of the
	  second form if the first form evaluates to false.
      (b) Change COND and CASE so that they return an unspecified value if
	  there is no ELSE clause.
    Here are some arguments in favor of (a):  
     - It removes the possibility of inferring that an implementation might
       not be tail-recursive through an alternate-less IF.
     - Similarly, it makes (IF #T <exp>) mean the same as <exp>, and removes
       doubt about the meaning of things like (if x (if y 1) z).
     - It simplifies the macro expansion of COND as compared with (b).
     - Option (b) is obviously undesirable (consider the case of mutually
       exclusive test expressions in a COND).

****>> I favor including a "(when pred val) as the proper special form
for two branch-if's.  That way two branch-if's would be syntactically
illegal.  I've used them for about a year and I find less bugs creeping
into other's and my own programs.

13. Many people would like to see the (define ((((a b) c) d) e) ...)
    feature go away.  S&ICP doesn't use it, and it has a rather complicated
    syntax (look at the BNF for evidence).  Vote keep or flush.

*****>> flush it.

Presentation questions:

18. Several people have complained about Clinger's perhaps overly accurate
    description of what happens when variables become bound.  To be
    accurate, we have to say that locations are created and the initial
    value is stored in the location, but this doesn't sit well with the
    desire to have Scheme sound like an almost-functional language.
    What to do?

****> Realize that Scheme is not "almost"-functional, it's almost Algol!
      I agree wholeheartedly agree with Will's characterization.
      The best that can be said with respect to the functionality
      of Scheme is that it contains a coherent subset that is "functional".
    
19. What should the dedication be?  Sussman suggested the PDP-6, which was
    the world's first Lisp machine, but some people didn't like this joke.
    I have changed it to Christopher Strachey in the draft.

****> I prefer Christopher Strachey.
    
21. Should section numbers be zero-based?  I'm beginning to think this looks
    unprofessional; and it just doesn't look right in several places.  It
    worked well in the previous version of the report, and it's clearly more
    consistent with the language (which is zero-based), but it doesn't work
    the way I've reorganized things.  If you like zero-based section
    numbers, speak up.

*****> 1-based seems better.
    
22. Was Scheme the first programming language to have first-class lexical
    closures?  Can we say anything edifying along these lines?

*****> Landin's ISWIM was the first well-known one back in the early 60's.
       However, I would guess that the use of "function" in the
       "Lisp 1.5 Programmming Language Manual" should count as
       a first-class closure.  If all "lambda"'s were surrounded by
       (function ...) then LISP 1.5 would model them. Furthermore,
       call/cc can be written with Landin's J operat.
    
23. I flushed the historical note "CATCH could be provided by a procedure"
    sentence (again, because two or three people thought it was random and I
    agreed), but some of you have complained about this.  Why should this
    bit of history be present, but not others that are at least as
    important?  

*****> I won't argue for the history.  However, the implementor who
       thinks that catch (as in Common Lisp) and call/cc are the same
       is in for a shock.  That should perhaps be pointed out.
    
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS.  I
    flushed the reference because (a) a number of people find the name
    CALL/CC quite distasteful and (b) it is inconsistent to mention here
    that some scheme implementations provide an alternate name for this but
    not also do so for LABELS, BLOCK, and a zillion other things.

****> Carolyn Talcott in her dissertation suggested the term "note".
      I could live with that.  If call-with-current-continuation is
      the only term, this will make those of us who write about this object
      uncomfortable. I think we agreed that "call/cc" would be an 
      acceptable abbreviation and I would prefer to keep that name
      in the report.  Those who don't like the name can choose not to use it.
      In a sense I agree with your argument, but "call-with-current
      -continuation has 30 characters in it!, "labels" and "letrec", and
      "block" and "begin" each have the same number of characters.

25. How best to resolve the inconsistencies between terminology in text and
    semantics?  Namely: "I", "Ide", "identifier" in semantics vs. "variable"
    in text; "Com", "command" in semantics vs. "statement" in text.

****> "variable" is a "dangerous" word, try to expunge it.  Opinions differ
    as to what a variable is.
    
26. FORCE & DELAY are still problematic.  About half of respondents said it
    was better to put FORCE up front with DELAY, and the other half thought
    it was fine as it was.  No one gave convincing arguments.

****> I favor join them.  I don't much care where they are joined.
    
28. In section 0.0, 2nd paragraph, before the terms "variable" and
    "identifier" have been defined, it should say "variable" instead of
    "identifier" to be consistent with the rest of the report.  Is that OK?

****> See comment on 26.
    
29. There are two nonterminals in the BNF that need names.  Currently they
    are called <formals> and <formalz> which was never intended to be a
    serious suggestion (I put it there to see if anyone would actually read
    the BNF!).  Actually one or both of these can go away if NAMED-LAMBDA
    and/or (DEFINE ((( ...) ...) ...) ...) go away.  Can someone who likes
    these things take a look at the BNF and suggest names for these?

****> I hope they go away.

Language:

Removed non-essential features from examples (including the big one)
where possible:  (1+ x) --> (+ x 1), (-1+ x) --> (- x 1), (define (foo
...) ...) --> (define foo (lambda ...)), 1-armed if --> cond, named let
--> letrec.

****> I'd still prefer "add1" or "succ" and "sub1" or "pred" to the
abuse of punnery "-1+", and its slightly weaker sibling "1+".
The cuteness of "-1+" should go.  In writing for a mass audience
I have learned that there is a time and a place for clever un-pronouceable
function names.  Please remove them and find pronounceable words



∂29-Jun-86  1205	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[INGRIA@G.BBN.COM: Scheme for LISPM]    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 Jun 86  12:05:51 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUN 86  14:59:40 EDT
Date: Sun, 29 Jun 86 14:58:30 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  [INGRIA@G.BBN.COM: Scheme for LISPM]
To: INGRIA@BBNG.ARPA
cc: SGR@SCRC-STONY-BROOK.ARPA, Scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 27 Jun 86 17:02 EDT from Stephen G. Rowley <SGR at STONY-BROOK.SCRC.Symbolics.COM>
Message-ID: <[AI.AI.MIT.EDU].63300.860629.JAR>

    Date: Thu, 26 Jun 1986  16:47 EDT
    Message-ID: <INGRIA.12217972484.BABYL@G.BBN.COM>
    From: INGRIA@G.BBN.COM
    To:   INFO-LISPM@MC.LCS.MIT.EDU
    Subject: Scheme for LISPM

    	Does anyone have an implementation of Scheme that runs on
    LISPMs?  It would be useful for us to have a version that runs on Rel6
    on 36XXs.  Thanks in advance.

I wrote one last summer.  It's not great for development, since there
are no debugging facilities besides TRACE, but it works.  It is written in
Common Lisp, but it has been comditionalized to make it also work in
Rel 6 Symbolics Common Lisp (which is full of bugs).  If you're at BBN,
you should contact Don Allen and get a copy from him.  Otherwise
contact me (JAR@MIT-AI) and I'll give you more information.

Jonathan

∂29-Jun-86  2140	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  Remaining questions & remarks (2)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 29 Jun 86  21:40:26 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 Jun 86 00:37:18 EDT
Received: from indiana by csnet-relay.csnet id ab01297; 30 Jun 86 0:37 EDT
Date: Sun, 29 Jun 86 19:58:16 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: jar@MC.LCS.MIT.EDU
Subject: Re:  Remaining questions & remarks (2)
Cc: rrrs-authors@MC.LCS.MIT.EDU

   1.  BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report;
       ...
         (a) leave things as they are (BEGIN essential with non-essential
   	  ...
         (b) remove BEGIN and make SEQUENCE essential (noting in the Notes
   	  ...

(b) [I hate the name begin... I am always looking for a corresponding end]

   2.  Similarly but less glaringly, we have a problem with the numeric
       ...
         (a) leave things as they are
         (b) flush the alternative names  <? <=? >? >=? =?
       ...

(b)

   3.  REC and NAMED-LAMBDA :
       Again, I sense capitulation on the part of some who have been stubborn.
       ...
         (a) Keep both
         (b) Flush both
       My editorial sense is that we should be able to achieve (b).  Remember,
       ...

(b)
    
   4.  SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :
       Many people have suggested removing these.  Anyone who wants them
       ...

remove them
    
   5.  Should we say anything about the possibility of parallel or
       ...

remove mention of parallel argument evaluation
    
   7.  Must a port still be a port (i.e. answer true to INPUT-PORT? or OUTPUT-PORT?)
       ...

I would prefer if it was but not strongly

   9.  ANGLE is what Common Lisp calls PHASE; any interest in changing the
       name? ...

call it phase
    
   10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
       can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)).  Do we
       apply Occam's razor and remove it?  If it's retained, then I'll just
       document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).

are they not different in implementations without complex numbers?

   11. JINX says: if PROCEDURE? exists, then a portable printer can be written.
       JAR replies (in jest):
         (define procedure?
   	(lambda (obj)
   	  (not (or (pair? obj) (null? obj) (symbol? obj) (number? obj) ...))))
       Seriously however, I was the only holdout at Brandeis against having
       ...

it should be included---I would much prefer the name "closure?"

   12. (if x 1) vs.  (cond (x 1)) -- this is inconsistent, as a couple of people
       ...
         (a) Change IF expressions so that they return the value of the
   	  ...
         (b) Change COND and CASE so that they return an unspecified value if
   	  ...
       ...

(c) require if to have a consequent and include WHEN as required---this gets
    rid of the whole mess and is much cleaner.
   
   13. Many people would like to see the (define ((((a b) c) d) e) ...)
       ...

flush it
   
   14. Status of LOAD not resolved.  If, as I suggested, LOAD is only
       ...
       renamed to be INCLUDE ?

no... load implies run time, include implies compile time, if they are
different

   15. Page breaks and tabs are mentioned in the report (actually I guess I
       ...

leave them out where possible

   17. Bartley says: "the second sentence of the description of EQUAL? should
       ...

I agree with David
   
   Presentation questions:
   
   18. Several people have complained about Clinger's perhaps overly accurate
       ...

I'd say leave Will's description.
       
   19. What should the dedication be?  Sussman suggested the PDP-6, which was
       ...

how about Haskell B. Curry?

   20. Is it OK to replace "Lazy ML" with "SASL" (last paragraph of section
       ...

it does seem more appropriate; SASL predates lazy ML.

   21. Should section numbers be zero-based?  I'm beginning to think this looks
       ...

1-based seems best

   22. Was Scheme the first programming language to have first-class lexical
       closures?  Can we say anything edifying along these lines?

ISWIM (Burge) had them about ten years prior to Scheme.  might want to refer
to Burge, W.H. ``ISWIM Programming Manual,'' IBM Research Report RA129,
Yorktown Heights, New York (November 1981).

   23. I flushed the historical note "CATCH could be provided by a procedure"
       ...
       
I agree, flush it.

   24. CALL/CC was mentioned in a sentence in a rationale in the RRRS.  I
       ...

definitely keep call/cc.  call/cc has appeared in several papers, and it is
much easier to type in without making mistakes---the other name compromises
did not end us up with names 5 times as long

   25. How best to resolve the inconsistencies between terminology in text and
       semantics?  Namely: "I", "Ide", "identifier" in semantics vs. "variable"
       in text; "Com", "command" in semantics vs. "statement" in text.

I prefer identifier for all symbols, such as keywords and lexical identifiers,
and variable for lexical identifiers.

   26. FORCE & DELAY are still problematic.  About half of respondents said it
       was better to put FORCE up front with DELAY, and the other half thought
       it was fine as it was.  No one gave convincing arguments.

they should be together, I would say where FORCE now is
       
   27. Is 3.0.2 (description of procedure calls) a good place to take note that
       () is not a valid procedure call?

it should be obvious from the syntax

   28. In section 0.0, 2nd paragraph, before the terms "variable" and
       "identifier" have been defined, it should say "variable" instead of
       "identifier" to be consistent with the rest of the report.  Is that OK?

yes

   Changed variable name "loop" to "recur" in the
   call-with-current-continuation example.

please don't---recur is the name of a special form in Chez Scheme and
is used by lots of people---I'd like to avoid confusion

As for grandfathering, unless the original RRRS report was distributed
much more widely than I figure it was, I would rather see no mention of
the incompatibilities.  It is not worthwhile to support old features
when the affected group of people is fairly small (particularly for new
implementations).  Besides, the various language manuals for existing
implementations with all their differing syntaxes were much more widely
distributed in total, and their features are not being grandfathered.

Kent


∂30-Jun-86  0741	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	Re:  r3rs presentation (long)    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 30 Jun 86  07:41:40 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 30 Jun 86 10:39:57 EDT
Received: from indiana by csnet-relay.csnet id aa04496; 30 Jun 86 10:37 EDT
Date: Mon, 30 Jun 86 03:46:12 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: ramsdell%linus@MITRE-BEDFORD.ARPA
Subject: Re:  r3rs presentation (long)
Cc: rrrs-authors@MC.LCS.MIT.EDU

    On less significant presentation issues, I would like to present a
    view that a less sophisicated user of Scheme may get about
    continuations.  That is, this reader may conclude that continuations
    are very powerful and always expensive to use.  I know that the T
    compiler of 1981 generated goto's from the a catch and throw
    expression that exited a loop from within a loop.  (Catch and throw is
    old syntax for using continuations.)  Since we promise that
    tail-recursive procedures are executed in constant space, can't we
    promise something about certain simple uses of continuations?
    Otherwise, they may avoided by programmers for the wrong reasons.

The T compiler of 1981 did not support continuations, just Lisp-style
catch and throw.  However, simple uses can be compiled into jumps or
not much more.  For instance, a smart compiler can tell that

    (call/cc (lambda (k) (if (zero? x) (k x) (/ 1 x))))

requires nothing more than a goto for (k x).  The ability to perform
this improvement is easily lost; if k is returned, placed somewhere,
or invoked from within a closure that is returned or placed somewhere,
etc., the full continuation must be made.  Recursion makes things a
little more difficult, since it requires not just a goto but some way
of recording the depth of the stack.  What's more, it takes a fairly
sophisticated compiler (or some special-casing) not to trip on

    (call/cc
       (lambda (return)
          (letrec ([g (lambda (l a)
                         (cond
                            [(null? l) a]
                            [else
                             (when (zero? (car l)) (return 'oops))
                             (g (cdr l) (/ a (car l)))]))])
             (g some-list-of-numbers 1))))

because it appears that return is closed over even though g can be
implemented as a simple loop (but couldn't be, for example, if the
closure g itself were returned instead of 'oops).  But this may be
just what the "do" expression below turns into.

    (call/cc
       (lambda (return)
          (do ([l some-list-of-numbers (cdr l)]
               [a 1 (/ a (car l))])
              ((null? l) a)
              (when (zero? (car l)) (return 'oops)))))

(Actually, it's worse than that, since letrec is itself a derived
form and really appears as a convoluted combination of lambda and
set! expressions.)

Making a guarantee that call/cc produces essentially gotos in simple
situations might backfire, too, resulting in convoluted code to take
advantage of the faster call/cc.  For instance, a programmer might
abandon map in favor of hand-coded loops, or not take full advantage
of closures and recursion.

Another problem with making such a guarantee is that call/cc is a
function, not a special form, and its value might change, e.g., for
tracing or "constraining control".  Certainly, it would be possible
to generate code for the first example something like

    (if (eq? call/cc *primitive-call/cc*)
        {fancy goto code for (if (zero? x) (k x) (/ 1 x))}
        {normal application of call/cc to (lambda (k) ...)}),

but this would be clumsy and wasteful of code space.

Some implementations of Scheme currently promote some or all primitive
functions almost to special form status... if the identifier's binding
is the expected one at compile time, assume it will be at run time and
generate inline code.  For example, car and cdr might be inlined this
way.  In these systems, call/cc could presumably be nailed down too.
But it cannot be guaranteed so in the RRRS without implying that some
primitives are really special forms.

Since I have brought the issue up, how does everyone feel about this
special treatment for primitives?  Should it be explicitly allowed or
disallowed?  All of the arguments against allowing extra special forms
come in to play here as well, plus others, so I'd say it should be
disallowed, at least by default.  I have no problem with some sort of
flag controlling this behavior, e.g., (set! *benchmark-mode* #t).  Or
perhaps we want to say that all primitives are special forms or that
primitive identifiers are not assignable (I don't think so).

How about making call/cc a special form?  I've often wondered if it
should be even though its evaluation rule would be the same as for
function application.  Call/cc is basic to any system, and support
for it must be provided by the compiler, at least in the way it
represents things.  Why should something be a function and not a
special form just because its evaluation rule coincides with the
evaluation rule for function applications?

(By the way, what about "not"?  How many times have you seen someone
turn a conditional expression around to avoid the extra call?)


Kent


∂01-Jul-86  1040	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Call-with-current-continuation    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Jul 86  10:40:22 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU  1 Jul 86 13:18:51 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from jymme.sun.uucp by linus.MENET (1.1/4.7)
	id AA02064; Tue, 1 Jul 86 13:19:55 EDT
Posted-Date: Tue, 1 Jul 86 13:21:34 edt
Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3)
	id AA02532; Tue, 1 Jul 86 13:21:34 edt
Date: Tue, 1 Jul 86 13:21:34 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8607011721.AA02532@jymme.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Call-with-current-continuation

I told a white lie.  My worry about the way continuations are
perceived was generated from opinions expressed by a knowledgeable
computer scientist from Harvard, not by myself.  This person showed a
good understanding of continuations, but worried about the runtime
overhead incurred even when continuations are used to express control
patterns that can be implemented using constant space (or a stack).

Agreeing with Kent, I cannot think of any way to promise something
about the execution of certain simple uses of continuations.  I guess
we should leave the topic of how to use continuations to another
document.  

We've heard reviews of r3rs from knowledgeable users of Scheme, has
anyone received an opinion of the document from a reader that is
representative of the general programming language community?

John

PS.  Sorry about being sloppy about T's continuations.  T of 1981
restricted continuations to those that allowed stack allocation of
control structure.  You could not return from a continuation twice or
pass a continuation out of its defining environment.  Thus, a more
correct statement is that CATCH and call of a T continuation was
syntax for stack-based continuations.  In the interpreter, CATCH was
expanded to a lambda expression and a call to a procedure like
call-with-current-continuation, but the same restriction on the
continuations applied.


∂01-Jul-86  1432	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: Remaining questions & remarks (2)   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Jul 86  14:27:19 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  1 Jul 86 17:21:32 EDT
Received: from ti-csl by csnet-relay.csnet id aa02302; 30 Jun 86 15:51 EDT
Received: by tilde id AA19055; Mon, 30 Jun 86 13:55:24 cdt
Date: Mon 30 Jun 86 13:47:42-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: Remaining questions & remarks (2)
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA, 
    rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <"860626190326.1.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
Message-Id: <12218999275.23.BARTLEY@CSC60>

=======> Here are my comments.  I don't care all that much about the items
=======> I've skipped over.		--David Bartley

1.  BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report
    [...]
      (a) leave things as they are (BEGIN essential with non-essential
	  synonym SEQUENCE),
      (b) remove BEGIN and make SEQUENCE essential (noting in the Notes
	  section that BEGIN, like #!TRUE etc., should be supported by
	  those implementations which care about running code written in
	  the past year).

=======> I strongly prefer (a).  BEGIN is the traditional name and is easy
=======> to understand (even without END).  SEQUENCE is a *type* in Common
=======> LISP and is likely to cause confusion.  I thought Hal and Gerry
=======> had indicated at Brandeis that they were willing to revise the
=======> book to use BEGIN instead of SEQUENCE.  (Is my memory faulty?)
 
2.  Similarly but less glaringly, we have a problem with the numeric
    comparisons.  Again, many people have said they don't care but they only
    want one set, with or without question marks.  Thus I offer
    the choices
      (a) leave things as they are
      (b) flush the alternative names  <? <=? >? >=? =?

=======> (b)

3.  REC and NAMED-LAMBDA :
    Again, I sense capitulation on the part of some who have been stubborn.
    The only options permitted are:
      (a) Keep both
      (b) Flush both

=======> (b).
 
4.  SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :

=======> Flush them.
 
5.  Should we say anything about the possibility of parallel or
    interleaved argument evaluation?  Remembering something I thought I
    heard Will once say, I added the innocent little phrase "or perhaps
    in parallel" to the description of procedure calling.  Richard
    Kelsey quickly pointed out that if it's mentioned as being a
    possibly legal implementation, many otherwise valid scheme programs
    may fail to run in implementations which do this, because they won't
    do necessary synchronization.  I agree; this is acceptable only if
    we provide synchronization primitives. 

=======> Flush the reference to parallel evaluation.  Keep random order
=======> evaluation.
 
6.  Number input exactness:

=======> I haven't come to terms with exactness yet, so I don't have an
=======> opinion.  Has anyone implemented this yet?
 
7.  Must a port still be a port (i.e. answer true to INPUT-PORT? or OUTPUT-PORT?)
    after being closed?

=======> Yes.  (Maybe.  (I don't know.  (What a question!)))
 
8.  Apparently there's no difference between ABS and MAGNITUDE.  Should we
    keep both?  If so, should I change the presentation in any way?

=======> Flush MAGNITUDE; keep ABS.
 
9.  ANGLE is what Common Lisp calls PHASE; any interest in changing the
    name? ...

=======> Use PHASE.
 
10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
    can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)).  Do we
    apply Occam's razor and remove it?  If it's retained, then I'll just
    document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).

=======> Is there any problem with precision here?  I'll go with the
=======> consensus.

11. JINX says: if PROCEDURE? exists, then a portable printer can be written.

=======> As Dan points out, we need to make it clear whether a
=======> continuation object is a "procedure" in the sense of this
=======> predicate.  If we call it CLOSURE?, as someone (Kent Dybvig?)
=======> suggested, then it should perhaps discriminate against
=======> continuations.  Since it is implementation-dependent whether
=======> continuations are easily distinguished from closures, I prefer a
=======> PROCEDURE? that is true of both closures and continuations.

12. (if x 1) vs.  (cond (x 1))
      (a) Change IF expressions so that they return the value of the
	  second form if the first form evaluates to false. [TRUE]
      (b) Change COND and CASE so that they return an unspecified value if
	  there is no ELSE clause.

=======> (a), as amended.

13. Many people would like to see the (define ((((a b) c) d) e) ...)
    feature go away.  S&ICP doesn't use it, and it has a rather complicated
    syntax (look at the BNF for evidence).  Vote keep or flush.

=======> Flush.

14. Status of LOAD not resolved.  If, as I suggested, LOAD is only
    to be syntactically valid at top level of a file, shouldn't it be
    renamed to be INCLUDE ?

=======> I'm not sure what INCLUDE means to people.  My intuition is that
=======> INCLUDE is a conditional LOAD---it is ignored if the specified
=======> files has already been loaded.  LOAD is unconditional and more
=======> appropriate as a building block for smarter capabilities.

15. Page breaks and tabs are mentioned in the report (actually I guess I
    added them - sorry), but there are no #\PAGE or #\TAB characters.
    Can this be made consistent by documenting #\PAGE and #\TAB, or [...]

=======> Lump these under "other whitespace".  I intend to treat them as
=======> in Common LISP.

16. If page breaks are documented, should the terminate comments?  I think
    they should (but of course they don't in Common Lisp).

=======> They won't if they are just whitespace.

17. Bartley says: "the second sentence of the description of EQUAL? should
    say that EQV? is used for all objects except pairs, vectors, and
    strings."  Forcing it to use EQV? seems kind of random to me.  This
    would of course make my notion of "apparent equivalence" useless,
    destroying what I deluded myself into thinking was an elegant symmetry
    between EQV? and EQUAL?; maybe it's a bogus idea anyhow.  I
    intentionally wanted to be silent on this point, allowing EQUAL? to
    return true more often than EQV? perhaps, but I don't care that much.

=======> I think that explicitly mentioning EQV? would clarify things.
=======> In particular, people want to understand how EQ?, EQV?, and
=======> EQUAL? are related.  I think its easier to understand them if
=======> they monotonically become less discriminating; thus all things
=======> that are EQ? are also EQV? and EQUAL? and all things that are
=======> EQV? are also EQUAL?.

18. Several people have complained about Clinger's perhaps overly accurate
    description of what happens when variables become bound.  To be
    accurate, we have to say that locations are created and the initial
    value is stored in the location, but this doesn't sit well with the
    desire to have Scheme sound like an almost-functional language.
    What to do?

=======> Keep Will's description.
    
21. Should section numbers be zero-based?  I'm beginning to think this looks
    unprofessional; and it just doesn't look right in several places.  It
    worked well in the previous version of the report, and it's clearly more
    consistent with the language (which is zero-based), but it doesn't work
    the way I've reorganized things.  If you like zero-based section
    numbers, speak up.

=======> One-based.
    
23. I flushed the historical note "CATCH could be provided by a procedure"
    sentence (again, because two or three people thought it was random and I
    agreed), but some of you have complained about this.  Why should this
    bit of history be present, but not others that are at least as
    important?

=======> We need to explain that CALL/CC is more than CATCH.
    
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS.  I
    flushed the reference because (a) a number of people find the name
    CALL/CC quite distasteful and (b) it is inconsistent to mention here
    that some scheme implementations provide an alternate name for this but
    not also do so for LABELS, BLOCK, and a zillion other things.

=======> Keep CALL/CC.

Language:

Only one empty list, period.  (eq? '() '()) returns true.

=======> Yes.

A port does not become closed as a side effect of reaching end of file.
After end of file, you'll continue to read end of file objects as long
as the port is open.  It's an error to read from or write to a closed
port.

=======> Yes.  Yes.  Yes.

DISPLAY writes characters like WRITE-CHAR does.

=======> Yes.

=======> Regards,
=======> David Bartley
-------


∂01-Jul-86  1446	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: Remaining questions & remarks (2)    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Jul 86  14:34:20 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  1 Jul 86 17:28:39 EDT
Received: from tektronix by csnet-relay.csnet id ad03875; 30 Jun 86 19:09 EDT
Received: by tektronix.TEK (5.31/6.15)
	id AA15265; Mon, 30 Jun 86 14:39:28 PDT
Received: by tekchips.TEK (5.31/6.15)
	id AA08024; Mon, 30 Jun 86 14:41:11 PDT
Message-Id: <8606302141.AA08024@tekchips.TEK>
To: JAR@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU, willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Subject: Re: Remaining questions & remarks (2)
In-Reply-To: Your message of Thu, 26 Jun 86 19:03 EDT.
	     <"860626190326.1.jar@AI"@JOE-LOUIS.LCS.MIT.EDU>
Date: 30 Jun 86 14:41:09 PDT (Mon)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

1.  BEGIN vs. SEQUENCE...
      (a) leave things as they are (BEGIN essential with non-essential
	  synonym SEQUENCE),
      (b) remove BEGIN and make SEQUENCE essential (noting in the Notes
	  section that BEGIN, like #!TRUE etc., should be supported by
	  those implementations which care about running code written in
	  the past year).

*****> (a).  Fix the book so we can get rid of SEQUENCE.
 
2.  <names of arithmetic comparators>
      (a) leave things as they are
      (b) flush the alternative names  <? <=? >? >=? =?

*****> (b).  MacScheme will continue to support the alternative names.
 
3.  REC and NAMED-LAMBDA...
      (a) Keep both
      (b) Flush both

*****> (b).
 
4.  SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT!...

*****> Flush them, but encourage Chris Hanson to publish his suite of
       operations in a separate document.
 
5.  <the possibility of parallel or interleaved argument evaluation>

*****> Drop the comment.  (I use call-without-interrupts, but that
       might not be so sweet on some multiprocessors.)
 
6.  Number input exactness: two proposals have been advanced to decide whether
    a number is exact or inexact if it has no #I or #E prefix and contains no
    trailing #'s.
      (a) Inexact if there are digits following a decimal point, or if
          exponential notation is used.  Otherwise exact.  (This makes
	  exctness similar to "floatness" in CL.)
      (b) A proposal which Will advanced, which I'm unable to locate right
          now, so he'll have to re-send it.
    I'll additionally advance another alternative, and you can make up more of
    your own:
      (c) Always exact.  E.g. "1.2" is exact.
 
*****> (b).  The proposal was that exponents be treated as shorthand, so
       for example 1.2e3 would be treated as though it had been written 1200,
       1.2000e3 would be treated as though it had been written 1200.0, and so
       on; if, after getting rid of the exponent in this way, there are
       digits following a decimal point, then assume inexact; otherwise
       assume exact.
       (a) is also ok.  I think scientists and engineers would quickly
       become exasperated by (c), however.

7.  Must a port still be a port...after being closed?

*****> No, but we shouldn't make a big issue of whatever we decide.
 
8.  Apparently there's no difference between ABS and MAGNITUDE.  Should we
    keep both?  If so, should I change the presentation in any way?
 
*****> Flush MAGNITUDE.  Talk about ABS where MAGNITUDE is now talked
       about.

9.  ANGLE is what Common Lisp calls PHASE; any interest in changing the
    name? ...
 
*****> I don't care.

10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
    can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)).  Do we
    apply Occam's razor and remove it?  If it's retained, then I'll just
    document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).

*****> PLEASE don't flush two-argument ATAN, because an implementation
       that supports flonums but not complexnums is going to have a hard
       time with (ANGLE (MAKE-RECTANGULAR X Y)).

11. ...Is anyone opposed to having an essential procedure PROCEDURE?...

*****> I very much want one.  I agree with Dan that
       (call-with-current-continuation (lambda (k) (procedure? k)))
       must be true.

12. (if x 1) vs.  (cond (x 1)) -- this is inconsistent...
      (a) Change IF expressions so that they return the value of the
	  second form if the first form evaluates to [true].
      (b) Change COND and CASE so that they return an unspecified value if
	  there is no ELSE clause.

*****> (a).

13. Many people would like to see the (define ((((a b) c) d) e) ...)
    feature go away.

*****> Flush.  MacScheme will continue to support it.

14. Status of LOAD not resolved.  If, as I suggested, LOAD is only
    to be syntactically valid at top level of a file, shouldn't it be
    renamed to be INCLUDE ?

*****> LOAD should be syntactically valid only at the top level of a file.
       I suppose it should be renamed to INCLUDE, but I don't want to.
       LOAD seems a more appropriate name for something that will in fact
       be used interactively, even though we don't talk about interactive
       programming in the report.

15. Page breaks and tabs are mentioned in the report (actually I guess I
    added them - sorry), but there are no #\PAGE or #\TAB characters...

*****> Please neutralize the places that mention tabs and page breaks.
       Let's not get hung up about characters.

16. If page breaks are documented, should [they] terminate comments?

*****> I think so.

17. Bartley says: "the second sentence of the description of EQUAL? should
    say that EQV? is used for all objects except pairs, vectors, and
    strings."  Forcing it to use EQV? seems kind of random to me.  This
    would of course make my notion of "apparent equivalence" useless,
    destroying what I deluded myself into thinking was an elegant symmetry
    between EQV? and EQUAL?; maybe it's a bogus idea anyhow.  I
    intentionally wanted to be silent on this point, allowing EQUAL? to
    return true more often than EQV? perhaps, but I don't care that much.

*****> I think your "apparent equivalence" was a valiant effort on behalf
       of a lost cause.  I think Bartley's suggestion will simplify the
       report and will make the language easier to understand and use.

-----

Presentation questions:

18. Several people have complained about Clinger's perhaps overly accurate
    description of what happens when variables become bound.  To be
    accurate, we have to say that locations are created and the initial
    value is stored in the location, but this doesn't sit well with the
    desire to have Scheme sound like an almost-functional language.
    What to do?

*****> Admit that Scheme isn't functional.  Add a note to the effect that
       in programs without side effects one can safely pretend that the
       variables are bound directly to the arguments.
    
19. What should the dedication be?  Sussman suggested the PDP-6, which was
    the world's first Lisp machine, but some people didn't like this joke.
    I have changed it to Christopher Strachey in the draft.

*****> The abstract from the RRRS was a better joke, because it said
       something serious.  A dedication to DEC PDP-6 Serial Number 2
       could well offend the memory of the person to whom the Algol 60
       Report was dedicated, so I think we'd better flush it.  Do we
       have to have a dedication?  I'm not sure how many of us actually
       met Christopher Strachey.  I remember Alonzo Church from the 1982
       Lisp Conference, and he might be better; maybe we could dedicate
       the report to both.  I believe that Church died a couple of years
       ago, but I might be thinking of Haskell Curry instead.  Dan?  Mitch?

20. Is it OK to replace "Lazy ML" with "SASL"...

*****> Yes.
    
21. Should section numbers be zero-based?

*****> I've decided that zero-based numbering is perceived as cutesy.
       I've found it helpful to have an unnumbered introductory section
       at the beginning of a chapter, which I think of as section 0 of
       that chapter, but I think it's best not to number it that way.
       My apologies for setting the precedent in the RRRS.
    
22. Was Scheme the first programming language to have first-class lexical
    closures?  Can we say anything edifying along these lines?

*****> I don't think Scheme was the first.  Scheme is unique not because
       it was the first to have anything (except full continuations, and
       even there it was anticipated by one of Reynolds's unimplemented
       languages), but because it was nearly the first at many things
       and succeeded in integrating those avant garde features.
    
23. I flushed the historical note "CATCH could be provided by a procedure"
    sentence (again, because two or three people thought it was random and I
    agreed), but some of you have complained about this.  Why should this
    bit of history be present, but not others that are at least as
    important?

*****> Something needs to be said about the evolution of the special form
       into a procedure having a different name.  As the paragraph stands
       in the 3 June draft, it makes no connection between the operators
       mentioned in the paragraph and call-with-current-continuation.  The
       typical reader will wonder why the paragraph is there.  The reason
       that history is called for in this instance is that the concepts
       are completely new to most readers, and they will need help to
       appreciate their significance.  Someday the rationale will be
       unnecessary, but by then the R3RS will be a standard reference
       cited by people who want to talk about the history of
       continuations.
       I favor adding a sentence such as "CALL-WITH-CURRENT-CONTINUATION
       is equivalent in power to the 1975 CATCH, but is a procedure rather
       than a special syntax."
    
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS.  I
    flushed the reference because (a) a number of people find the name
    CALL/CC quite distasteful and (b) it is inconsistent to mention here
    that some scheme implementations provide an alternate name for this but
    not also do so for LABELS, BLOCK, and a zillion other things.
    
*****> As someone who writes manuals for a mass audience, I find the name
       CALL/CC quite distasteful.  It was in the RRRS to placate those
       who objected to the length of CALL-WITH-CURRENT-CONTINUATION.
       This was a political compromise; I suggest we leave the RRRS
       wording alone rather than try to achieve a new compromise.

25. How best to resolve the inconsistencies between terminology in text and
    semantics?  Namely: "I", "Ide", "identifier" in semantics vs. "variable"
    in text; "Com", "command" in semantics vs. "statement" in text.
    
*****> In the abstract syntax, say "identifiers (variables)" and
       "commands (statements)".

26. FORCE & DELAY are still problematic...

*****> I don't care.
    
27. Is 3.0.2 (description of procedure calls) a good place to take note that
    () is not a valid procedure call?

*****> Ok with me.
    
28. In section 0.0, 2nd paragraph, before the terms "variable" and
    "identifier" have been defined, it should say "variable" instead of
    "identifier" to be consistent with the rest of the report.  Is that OK?

*****> Yes.  Dan points out that the semantics of "variable" is highly
       variable, but we have an advantage over most authors in that people
       can turn to the formal syntax and semantics if they want to know
       what's really going on.  Section 2.0 is a pretty good informal
       description.  I think people can deal with a few loaded terms
       in an overview like section 0.0.
    
29. There are two nonterminals in the BNF that need names.  Currently they
    are called <formals> and <formalz> which was never intended to be a
    serious suggestion (I put it there to see if anyone would actually read
    the BNF!).  Actually one or both of these can go away if NAMED-LAMBDA
    and/or (DEFINE ((( ...) ...) ...) ...) go away.  Can someone who likes
    these things take a look at the BNF and suggest names for these?
    
*****> I hope NAMED-LAMBDA and the complicated DEFINE syntax depart from
       the report, but even if they do we still have to deal with <formalz>
       in the (DEFINE (FOO . X) ...) syntax; perhaps the possibilities
       could be expanded in-line.

30. Someone wanted me to avoid discussion of immutable objects in the
    discussion of operational equivalence in the 2nd paragraph before entry
    for EQV? .  I want to mention immutability there because I think it's
    important to warn users that this might be the case, otherwise they can
    easily end up writing unportable code.

*****> In my opinion, the paragraph in question is too little to deal
       with the problem.  It uses "immutable" without explaining what
       it means; worse, it appears that the typical reader is supposed
       to know as a matter of course that "mutation procedures" (whatever
       they are) can't be applied to immutable objects.  As to which
       objects are immutable, all we have is the suggestion that objects
       returned by literal expressions may be immutable.
       I believe the paragraph at the end of 3.0.1 is sufficient.  The
       report is a definition, not a tutorial.

-----

DISPLAY writes characters like WRITE-CHAR does.

*****> I assume it's ok for an implementation that represents characters as
       imaginary numbers to have (DISPLAY #\a) print "-97i"?

Peace, Will

∂02-Jul-86  0515	@MC.LCS.MIT.EDU:JMILLER@OZ.AI.MIT.EDU 	Re: Remaining questions & remarks (2)    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jul 86  05:15:44 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JUL 86  08:14:17 EDT
Date: 2 Jul 1986 08:13-EDT
Sender: JMILLER@MIT-OZ
Subject: Re: Remaining questions & remarks (2)
From: JMILLER@MIT-OZ
Reply-To: JMiller%OZ@MC
To: Bartley%ti-csl.csnet@CSNET-RELAY
Cc: RRRS-Authors@MC
Message-ID: <[MIT-OZ] 2-Jul-86 08:13:05.JMILLER>
In-Reply-To: <12218999275.23.BARTLEY@CSC60>

I suggest the name APPLICABLE?  instead of PROCEDURE?.  I
personally do not regard continuations as procedures, but I
completely understand and empathize with people on the other
side.  I think the notion of applicable is a legitimate
generalization and probably would solve Bill's portable printer
problem just as well.

--Jim

∂02-Jul-86  0557	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Call-with-current-continuation    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jul 86  05:57:07 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU  2 Jul 86 08:54:07 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from jymme.sun.uucp by linus.MENET (1.1/4.7)
	id AA16445; Wed, 2 Jul 86 08:55:09 EDT
Posted-Date: Wed, 2 Jul 86 08:56:47 edt
Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3)
	id AA03112; Wed, 2 Jul 86 08:56:47 edt
Date: Wed, 2 Jul 86 08:56:47 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8607021256.AA03112@jymme.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Call-with-current-continuation

I told a white lie.  My worry about the way continuations are
perceived was generated from opinions expressed by a knowledgeable
computer scientist from Harvard, not by myself.  This person showed a
good understanding of continuations, but worried about the runtime
overhead incurred even when continuations are used to express control
patterns that can be implemented using constant space (or a stack).

Agreeing with Kent, I cannot think of any way to promise something
about the execution of certain simple uses of continuations.  I guess
we should leave the topic of how to use continuations to another
document.  

We've heard reviews of r3rs from knowledgeable users of Scheme, has
anyone received an opinion of the document from a reader that is
representative of the general programming language community?

John

PS.  Sorry about being sloppy about T's continuations.  T of 1981
restricted continuations to those that allowed stack allocation of
control structure.  You could not return from a continuation twice or
pass a continuation out of its defining environment.  Thus, a more
correct statement is that CATCH and call of a T continuation was
syntax for stack-based continuations.  In the interpreter, CATCH was
expanded to a lambda expression and a call to a procedure like
call-with-current-continuation, but the same restriction on the
continuations applied.


∂02-Jul-86  1652	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Remaining questions & remarks (2)  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 Jul 86  16:51:54 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 JUL 86  19:49:14 EDT
Date: Wed,  2 Jul 86 19:50:46 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Remaining questions & remarks (2)
To: JMiller@OZ.AI.MIT.EDU
cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA,
    RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 2 Jul 1986 08:13-EDT from JMILLER at MIT-OZ
Message-ID: <[AI.AI.MIT.EDU].64955.860702.JAR>

    Date: 2 Jul 1986 08:13-EDT
    From: JMILLER at MIT-OZ

    I suggest the name APPLICABLE?  instead of PROCEDURE?.  I
    personally do not regard continuations as procedures, but I
    completely understand and empathize with people on the other
    side.  I think the notion of applicable is a legitimate
    generalization and probably would solve Bill's portable printer
    problem just as well.

It never occurred to me that the two words could mean anything
different.  Certainly whatever the name is, the predicate would return
true of all applicable things, including CAR, things created by
CALL-WITH-CURRENT-CONTINUATION, and values of LAMBDA-expressions.

If the term for this kind of object changes, then the word "procedure"
must be replaced by "applicable object" throughout the entire report.  The
term "procedure," which everyone has been so careful to use so far, would
become useless for any purpose I can think of, e.g. describing the
domains of procedures.  That would be unfortunate.

∂07-Jul-86  0929	@MC.LCS.MIT.EDU:VERACSD@A.ISI.EDU 	CL Compatiblity Package  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Jul 86  09:29:21 PDT
Received: from A.ISI.EDU by MC.LCS.MIT.EDU  7 Jul 86 12:24:30 EDT
Date: 7 Jul 1986 12:23-EDT
Sender: VERACSD@A.ISI.EDU
Subject: CL Compatiblity Package
From: VERACSD@A.ISI.EDU
To: scheme@MC.LCS.MIT.EDU
Cc: veracsd@A.ISI.EDU
Message-ID: <[A.ISI.EDU] 7-Jul-86 12:23:31.VERACSD>

Does anyone have a CommonLisp compatiblity package for Scheme
that they are willing to share?  I have developed a rudimentary
package for MacScheme, but am interested in something more
complete.

-- Cris Kobryn

∂07-Jul-86  1254	@MC.LCS.MIT.EDU:cth%indiana.csnet@CSNET-RELAY.ARPA 	votes and things  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Jul 86  12:53:08 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  7 Jul 86 15:51:53 EDT
Received: from indiana by csnet-relay.csnet id ai12245; 7 Jul 86 15:44 EDT
Date: Mon, 7 Jul 86 12:50:06 est
From: Chris Haynes <cth%indiana.csnet@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: votes and things
Cc: dfried%indiana.csnet@CSNET-RELAY.ARPA

The 3 in R↑3RALS is clever, but it looks just like a footnote
reference when the Report is cited.  Such puns hurt others more than
they entertain us.  How about just "Report on the Algorithmic
Language Scheme".  That's different enough from all the previous
report names to avoid confusion, and brevity is a particular virtue
in things, such as titles, that are refered to repeatedly.

I strongly second John Ramsdell's comments about the introduction.
If not religated to the end, the historical material should at least
be in a seperate section following the introduction.  I also agree
with him that call-with-{input,output}-PORT is better than ...-FILE
now that we have the ...-PORT? predicates.

I've used the words KEYWORD and IDENTIFIER for what Jonathan is
calling IDENTIFIER and VARIABLE, respectively.  I agree with Dan that
VARIABLE is confusing, because it is often used to mean LOCATION.
But I don't feel strongly.  However, it is best not to have one word
for both: if you ever mean "keyword and identifier" (or "identifier
and variable"), and not just "symbol", then say so.

My votes follow (I care most about the first and last):

1. (a) leave BEGIN alone

2. (b) flush <?, et al.

3. (b) flush REC (sigh) and NAMED-LAMBDA

4. flush SUBSTRING-MOVE-...

5. flush parallelism references, keep random order

6. (a) inexact like CL "floatness"

7. yes, objects (even ports) should never change type, or there will
be some big surprises.

8. flush MAGNITUDE

9. change ANGLE to PHASE

10. keep two-argument ATAN

11. add PROCEDURE?.  For pedagogy I like to maintain a distinction
between primitives, closures (LAMBDA expression values) and reified
continuations, and I use "procedure" to refer to any applicable object.
The programmer shouldn't be able to tell the difference, so the language
should only support PROCEDURE?.

12. (c) Flush one armed IF, and replace by WHEN, as suggested by Kent
and Dan.

13. flush (define ((a b) c) ...)

14. keep LOAD as is

15. treat page breaks and tabs as whitespace, and say no more

17. EQ?, EQV? and EQUAL? should increase in strength monotonically,
as David suggested.

18. keep Clinger's accuracy wrt variables

19. Do we really need a dedication?  If so, Strachey is more appropriate
than the PDP-6, Curry is better, and Church seems best.

20. SASL

21. one-based section numbering

22. Landin and Reynolds should be credited with introducing
first-class closures and continuations, but it should be emphasized
that Scheme was the first widely used language to support them and is
still the most used language that supports both.

23. note the difference between CATCH and continuations somewhere

24. CALL/CC should be listed under CALL-WITH-CURRENT-CONTINUATION as
an (optional) procedure. It should be mentioned in the following
discussion that it is an equivalent abbreviation, with no other
apology offered.  Dispite objections to it by some, it is more widely
used and refered to than some other things that we have kept by way
of compromise.


Regards,
Chris Haynes


∂08-Jul-86  0538	@MC.LCS.MIT.EDU:dyb%indiana.csnet@CSNET-RELAY.ARPA 	display and write-char 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 8 Jul 86  05:38:31 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  8 Jul 86 08:37:47 EDT
Received: from indiana by csnet-relay.csnet id ac19489; 8 Jul 86 8:37 EDT
Date: Tue, 8 Jul 86 01:17:19 est
From: Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>
To: jar@MC.LCS.MIT.EDU
Subject: display and write-char
Cc: rrrs-authors@MC.LCS.MIT.EDU

    DISPLAY writes characters like WRITE-CHAR does.

It seems to me that this only works if the character type is
distinct from other types.  I would not want display to print
an integer that happens to be a character (assuming integers
are used to represent characters) as the character value
instead of the expected sequence of numerals.

For example, if the character #\A is equivalent to the integer
65, then it seems that either

  1) (write-char #\A) prints A and (display 65) prints A, or

  2) (display 65) prints 65 and (write-char #\A) prints 65.

I think the original intent was that (write-char #\A) print A
and (display 65) print 65, even if #\A and 65 are the same.

Am I missing something?

Kent


∂08-Jul-86  2347	@MC.LCS.MIT.EDU:WAND%northeastern.edu@CSNET-RELAY.ARPA 	remaining questions & remarks (2) 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 8 Jul 86  23:47:40 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  9 Jul 86 02:46:51 EDT
Received: from northeastern by csnet-relay.csnet id af28296; 9 Jul 86 2:44 EDT
Date:     Tue, 8 Jul 86 13:43 EST
From:     MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>
To:       rrrs-authors@MC.LCS.MIT.EDU
Subject:  remaining questions & remarks (2)

My comments on the "remaining questions" and a few other things:

I. I second Chris Haynes's comments on the title "R↑3RS..".  It is not only 
too cutesy, but also suggests an aura of impermanence:  these guys are going 
to keep going until....

II.  Kent Dybvig should be an author, on the same basis as Kent Pitman.

Comments on the numbered issues:

1. (a) leave BEGIN essential, SEQUENCE optional.

2. (b) flush <?, etc.

3. (b) flush both REC and NAMED-LAMBDA.  I feel very uneasy, however, about 
the overall status of special forms, both system- and user-supplied.  I will 
be very unhappy if I can't have a conforming Scheme that happens to have a 
REC.  I suspect that this situation merely reflects our lack of understanding 
of this issue.

5. Flush the possibility of parallel or interleaved argument evaluation.

7. Yes, a port must be a port forever, else what's an object for?

9. Sure, use PHASE (suppress gratuitous incompatibilities)

10. Keep 2-arg ATAN.

11. Include PROCEDURE?, and make it be true of continuations.  I would also be 
happy with the name APPLICABLE?, though I prefer PROCEDURE?.  I strongly 
oppose the name CLOSURE? .

12. (a) 2-argument IF should return the value of the 2nd arg if the first is 
true.  (when pred exp) is OK too.

13. Flush (define ((((a b) c) d) e) ...)


18. DEFINITELY keep Clinger's description of variable binding.  It's the only 
hope of sanity.  As Dan pointed out, Scheme is closer to Algol than it is to a 
functional language, and that's a good bit of why it's useful.

19. I vote for Chris Strachey.  Church was still alive the last time I looked. 
 Curry was the one who died, but he had not thought much, so far as I know, 
about the computational implications of his work (even though he did some 
numerical analysis on the ENIAC in 1944-46, see Seldin & Hindley, "To H.B. 
Curry..." 1980, p. x).  I think Strachey's work, as amplified and expounded 
through Scott, Stoy, Milne, etc., is a far more direct intellectual source of 
our work (as expounded through Scheme) [the "our" here meaning the Scheme 
community, not just me.].

20. For call-by-name, how about Algol? "This is distinct from the situation in 
languages such as SASL or Algol 60, where arguments are passed by name, so 
that an argument expression is not evaluated unless its value is needed by the 
procedure".  This sentence needs to be careful not to confuse call-by-name 
with call-by-lazy or other similar things.

21. I vote for one-based section numbering.  I think zero-basing is cutesy.  
Also, if we are going to copy the Algol 60 typography, then sub*section 
numbers should always be terminated by a period e.g.,

4.5.3.1. If statement. .... (Algol report, page 10).

23. I vote to keep the historical note about CATCH being provided by a 
procedure, since Scheme IS (so far as I know) the first language to do this.

Mitch Wand

∂09-Jul-86  0340	@MC.LCS.MIT.EDU:HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	mitch wand's comments    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 9 Jul 86  03:40:15 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 JUL 86  06:39:47 EDT
Date: Wed, 9 Jul 1986  06:37 EDT
Message-ID: <HAL.12221269278.BABYL@MIT-OZ>
From: HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To:   rrrs-authors@MC.LCS.MIT.EDU
Subject: mitch wand's comments
In-reply-to: Msg of 8 Jul 1986  14:43-EDT from MITCHELL WAND <WAND%northeastern.edu at CSNET-RELAY.ARPA>


I second the vote for Strachey

∂10-Jul-86  1015	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	number syntax  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86  09:08:00 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 10 JUL 86  12:07:13 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 3966; Thu 10-Jul-86 12:08:18-EDT
Date: Thu, 10 Jul 86 12:09 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: number syntax
To: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
cc: rrrs-authors@MIT-MC.ARPA
Message-ID: <860710120911.5.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>

    Date: Tue 17 Jun 86 16:00:31-CDT
    From: David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
    To:   RRRS-Authors%mit-mc at CSNET-RELAY.ARPA
    cc:   Bartley%ti-csl.csnet at CSNET-RELAY.ARPA
    Re:   Number syntax
    Message-Id: <12215615581.31.BARTLEY@CSC60>
    
    One irritant in the Report that we have neglected to comment on until
    now (sorry!) is the syntax of numbers.  We believe that Scheme numbers
    are essentially equivalent to Common Lisp numbers except for the new
    notion of exactness.  To the extent that that is so, it seems to be a
    (shudder!) ``gratuitous difference'' from Common Lisp to have an
    incompatible syntax.
    
    The R↑3RS doesn't make clear which subset of the syntax of numbers is
    essential and what is optional.  As implementors of systems in which
    Scheme and Common Lisp must co-exist, we're faced with two potential
    compatibility issues: (1) going with an ``extended subset'' of the
    Report's number syntax that is compatible with Common Lisp, or (2)
    going with the full number syntax in the Report to be compatible with
    all other Scheme implementations.
    
    What we'd like to see is an essential syntax for numbers which is
    compatible with Common Lisp's.  Additional features, including
    exactness, would be optional extensions.  Even so, they should not
    conflict with Common Lisp.  For example, the use of `#s' and the order
    of <sign> and <prefix> are different in the two languages.
    
    Our motivation, of course, is that we'd like programmers to feel free to
    use either language and exchange files of data without irritating
    obstacles being thrown in their path.  If we can't agree on a
    consistent syntax for numbers, then we'll have to provide each language
    with two readers and the user will have to know which one to use.
    
    (There are other problems, of course, such as whether `:' is a
    constituent of an identifier or associated with Common Lisp package
    designations.  We may have to go with separate readers/modes anyway.)
    
    Does anyone agree with us?  Is there time to make such a change before
    R↑3RS goes to press?

I think everyone agrees with you, and that there is time.  Could you
please write a concrete proposal, preferably something close to being
suitable for inclusion in the report.  Also please provide BNF.  Thanks.

Jonathan

∂10-Jul-86  1016	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	call-with-*put-file  -->  call-with-*put-port
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86  09:58:39 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 10 JUL 86  12:58:04 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 3969; Thu 10-Jul-86 12:59:10-EDT
Date: Thu, 10 Jul 86 13:00 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: call-with-*put-file  -->  call-with-*put-port
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <860710130002.6.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>


    Date: Fri, 27 Jun 86 11:37:13 edt
    From: ramsdell%linus at mitre-bedford.ARPA
    To:   rrrs-authors%mc.lcs.mit.edu at mitre-bedford.ARPA
    Re:   r3rs presentation
    
    [pg. 29]  If call-with-current-continuation calls its argument with
    the current continuation, should the I/O routines call-with-input-file
    and call-with-output-file be renamed call-with-input-port and
    call-with-output-port? 

I think this is a good idea.  Does anyone object?

Jonathan

∂10-Jul-86  1228	@MC.LCS.MIT.EDU:MICHAEL@CS.COLUMBIA.EDU 	How big would a "minimal" scheme interpreter be? 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86  12:28:21 PDT
Received: from CS.COLUMBIA.EDU by MC.LCS.MIT.EDU 10 Jul 86 15:22:56 EDT
Date: Thu 10 Jul 86 15:22:04-EDT
From: Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>
Subject: How big would a "minimal" scheme interpreter be?
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12221626971.27.MICHAEL@CS.COLUMBIA.EDU>

Where minimal means just the interpreter no heap etc.

Michael
-------

∂10-Jul-86  1300	@MC.LCS.MIT.EDU:andy@sun3.ads.ARPA 	My comments on the R↑RS 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86  12:56:30 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 10 Jul 86 15:38:51 EDT
Date: Thu, 10 Jul 86 12:39:26 PDT
From: andy@sun3.ads.ARPA (Andy Cromarty)
To: jar%mit-mc@ads.arpa
Subject: My comments on the R↑RS
Cc: rrrs-authors%mit-mc@ads.arpa

Jonathan,

I've enclosed my comments on the R↑3RS in this note
separately from my answers to your specific questions you asked.
Hope this helps.  By the way, I know that putting this all together
involves a lot of work (and sometimes a lot of refereeing), and you
should be aware that your contribution isn't going unappreciated.   Thanks
for all the hard work you're putting in, and my apologies in advance
if I err here due to an insufficiently detailed reading of the report.

					asc
------------------------------------------------------------------------
1. I am concerned that we have multiple conflicting goals in the
   design of the document.   Sometimes it is a reference manual,
   and sometimes it is a technical report, and sometimes it is a
   users' guide.  Perhaps we must live with this if there is to
   be only one report, but it might be a good idea to try to 
   separate out (say) the history from the reference manual parts.
   This is reflected in the discussions about moving or removing
   the history section, for example.

2. As you might expect, I would like to see a somewhat more vigilant
   attitude in warding off the dark forces of Common Lisp.  It is not
   compatibilities or incompatibilities that are gratuitous; it is
   the very act of being concerned with compatibility at all that is
   gratuitous.  We should have our own standards of what a good LISP
   looks like and stick to them.  The first job of a good language is
   to be a good language, not to be just like another bad language
   that's familiar (nor even just like another good language that's
   familiar).  Common Lisp's goals were nearly the opposite of
   Scheme's, and however good a job the CL committee did, we owe them
   no homage.  I recognize that this is more an issue of the design
   of Scheme than of its documentation in a report, but there seems
   to me to be entirely too much concern for similarities and
   dissimilarities w.r.t. Common Lisp in the report.  It may be
   appropriate to discuss the topic of Scheme vs. CL briefly in the
   historical section, but there should be a very clear message to the
   reader that CL followed Scheme -- and continues to, in the sense
   that Scheme is meant to be a progressive attempt at (LISP) language
   design rather than a codification and standardization of existing
   ideas in prior LISPs.   The CL people should be writing reports
   that compare their work to ours, not the other way around.   ``Let
   them eat cake.''  [OK, flame off.]

3. On p.2 you list me as a Brandeis participant.  Would that it were
   true.  I will leave to your judgement whether I should be listed
   in the acknowledgements, as an author, or otherwise.

4. I agree with both your observations on the Syntax section (0.1)
   -- that it makes sense to have one there and that it isn't clear
   what it should say.   Perhaps a fairly terse or brief description of
   Scheme's simple syntax would do, e.g.

	The syntax of Scheme, like that of most LISPs, provides
	for great expressive power, largely due to its simplicity.
	An important consequence of this simplicity is the
	susceptibility of Scheme programs and data to uniform
	treatment by other Scheme programs.  As with other LISPs,
	the ``read'' function actually parses its input; that is, it
	performs syntactic as well as lexical decomposition of what
	it reads, rendering input in a uniform internal representation
	and making it particularly easy to manipulate Scheme programs
	and data in a correspondingly direct and uniform fashion.

	Scheme employs a parenthesized-list Polish notation to
	describe programs and (other) data, with lists recursively
	defined as being composed of lists and what are
	sometimes referred to as ``atomic'' objects (numbers,
	symbols, etc.) \foot{Unlike most LISPs, Scheme does not
	explicitly provide a predicate for assessing atomicity,
	although it does contain predicates for determining whether an
	object is a list, symbol, number, etc.} The syntax of Scheme
	expressions is described formally in greater detail later in
	this report.

5. Identifiers & keywords: Sections 1.0 and 2.0 gave me pause,
   because I have been concerned for some time with the keyword
   problem in Scheme (and I admit to being dissatisfied with the
   most common solution).  The statement

	``Any identifier which is not a syntactic keyword  may be
          used as a variable....''

   which appears in both sections implies that there are keywords in
   the language, although (a) there aren't guaranteed to be and (b)
   you haven't said anything previously about keywords in the
   document.   The astute reader will then turn to the index to find
   out what she has missed, only to discover that there is no entry
   at all for keywords.  Later on there is a discussion of keywords,
   but it is essentially an afterthought, and by now the reader may
   have decided that Scheme really is Pascal after all (Andrew, bite
   your tongue).  Something needs to be done to clear up the
   potential confusion from the initial presentation of identifiers
   vs. keywords.  The inline "Note:" on p.6 probably does not serve
   to clarify things as much as it might.

6. P. 6, SS 2.0: Yes, mention that there are no guarantees that a
   ``top-level'' exists.  (Then encourage the rest of the RRRRS
   authors read that paragraph....)

7. SS 2.1, p.6 implies that there are other values besides #f that
   count as false.  Except for the optional #!false, I'm not sure I
   see what these are.   Perhaps you count things like (NOT #T) as
   false for the purposes of this section?

8. p. 7, SS3.0.2 -- Typo at bottom of page, ``combinations.  .''

9. p.7 SS 3.0.2: It may not be clear to non-LISPophiles what
   ``+`` evals to, or why ``+'' gets evaluated in the example

		(+ 3 4)			=>	7
		((if #f + *) 3 4)	=>	12

   The idea of a function name evaluating to a functional object
   will not be intuitive for most readers, who probably think in
   languages that don't have first-class procedures.  Perhaps
   something can be done to make this clearer.

10. There are a few minor report points that reflect major
    underlying problems we really have yet to solve in the design
    of Scheme, involving things like COND, IF, and perhaps LET.  The
    syntax definitions provided earlier on in the report make (COND ((X)))
    a legal expression, and we've already had the n-armed IF argument.
    Similarly, (LET () (DOSOMETHING)) is legal, although perverse and
    not obviously useful.  (The latter expression actually appears in
    the report, at the top of p.10 col2, although I can see no reason
    to have used it -- the example would have worked fine without it.)

    I think what has happened is that we never resolved the issue of
    ``functions'' that don't return values.  Instead we developed, or
    permitted the random evolution of, a hodgepodge of mutually
    inconsistent local solutions: DEFINE is not an expression, IF may
    (or may not) have an undefined return value, (COND ((X))) returns
    (X), etc.  We still have design work to do.

11. On a related syntax (or is it design?) point, on p.9, SS3.1.0, the
    expression (CASE TEST (() (FOO))) is permitted.  It's not clear to me
    why we want to permit this, nor what it means if we do.  Strictly, 
    it would always be ignored, in which case it's spurious.
    Similarly, (CASE TEST) is legal; strictly it returns <unspecified>
    but seems senseless nonetheless.

12. I cannot refrain from observing that DO is truly ugly, a
    veritable pig of a construct, and we could have done better.
    We are indeed fortunate that its use under practical circumstances
    is rarely necessary.

13. The Note: on p.11 about DO in which you describe assignment vs.
    rebinding is guaranteed to be lost on the majority of readers.
    An example of how it differs from other LISPs' DO might help.

14. On p.12 where QUASIQUOTE is introduced, as a purely typographic
    observation, we really need a better backquote character.  It's
    very hard to read the character at all in the copy of the report
    I have, especially at that point size.  At first glance I thought
    in all honesty that it was a speck of ink on my copy.  (I believe
    my hardcopy came from MIT, although its route was sufficiently
    mysterious that it might have been printed at Berkeley instead.)

15. SS 4.0 talk about the ``top level,'' as if there is one; cf. my
    point #6 above.

16. SS 4.1, p.12, first sentence: I find this ambiguous:

	Definitions are not valid in all contexts where expressions
	are allowed; they are only valid at the top level [sic] of
	a <program> and at the beginning of a lambda body.

    This could mean any of several things, e.g.:

	Definitions are invalid in all contexts where expressions are
	allowed (i.e. there are no contexts in which definitions are
	valid where expressions are allowed)....

    or

	Definitions are invalid in some contexts where expressions
	are allowed (i.e. there exist contexts where expressions are
	allowed but wherein definitions are not allowed)....

    This probably needs to be rephrased for people who don't already
    know what it's trying to say.

17. Top of p.13 col1: You have ``(.  <variable>) would be understood
    to mean simply <variable>.''  Why permit this?  It offers no
    additional functionality and strikes me as an unclean misfeature.

18. p.14, SS 5.1: Misspelling, ``distint'' => ``distinct''.

19. p.17, SS5.2: Misspelling, ``decsription'' => ``description''.

20. Predicates: As far as I could see, we never actually commit to
    putting ``?'' at the end of predicates, although we do
    mention on p.18 that functions like ASSV don't end in ``?''
    because they aren't predicates.  This convention would be a good
    thing to assert.  (It also would blow the people who dislike >?
    out of the water, I'm afraid.)

21. p. 18, SS 5.3, First sentence: ``entirely'' is massive
    overstatement here.  There are lots of bases for the utility of
    symbols -- like their use as printable undoublequoted objects, which
    seems to me to have been lost almost entirely [sic] on the
    Scheme community (hence the rejection of upper/lower case
    distinction).  (Incidentally, CommonLisp also gets control of
    UC/LC terribly wrong, to my eternal annoyance when I build
    distributed multiprocessing mostly-LISP-based systems that want
    to communicate by passing case-varying symbol tokens instead of
    strings.)

22. p.28, SS 5.8: What happened to TeX in the middle of column 2
    where it says ``The escape procedure''?  Misplaced manual
    linebreak, perhaps.

23. NOTES, p.35ff.: This material should stay somehow.  We need to
    make it clear that R↑3 Scheme is not being touted as Yet Another
    Ultimate Solution To The Programming Language Problem, but rather
    as a snapshot of a *process* of good design, for which not all
    answers have yet been found.  We also ought to use the opportunity
    for publicity afforded us by SIGPLAN to advertise some of the thorny
    unsolved problems that need further research, and encourage
    language designers to work on them.

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

∂10-Jul-86  1313	@MC.LCS.MIT.EDU:MICHAEL@CS.COLUMBIA.EDU 	[Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>: How big would a "minimal" scheme interpreter be?]    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86  13:13:16 PDT
Received: from CS.COLUMBIA.EDU by MC.LCS.MIT.EDU 10 Jul 86 15:59:39 EDT
Date: Thu 10 Jul 86 15:58:42-EDT
From: Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>
Subject: [Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>: How big would a "minimal" scheme interpreter be?]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12221633641.27.MICHAEL@CS.COLUMBIA.EDU>

Return-Path: <@MC.LCS.MIT.EDU:Network←Server@MIT-MULTICS.ARPA>
Received: from MC.LCS.MIT.EDU by CS.COLUMBIA.EDU with TCP; Thu 10 Jul 86 15:53:57-EDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 10 Jul 86 15:28:35 EDT
Received: from MC.LCS.MIT.EDU by MIT-MULTICS.ARPA TCP; 10-Jul-1986 15:28:06-edt
Received: from CS.COLUMBIA.EDU by MC.LCS.MIT.EDU 10 Jul 86 15:22:56 EDT
Date: Thu 10 Jul 86 15:22:04-EDT
From: Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>
Subject: How big would a "minimal" scheme interpreter be?
To: scheme@MC.LCS.MIT.EDU
Message-ID: <12221626971.27.MICHAEL@CS.COLUMBIA.EDU>

Where minimal means just the interpreter no heap etc.

Michael
-------


-------

∂10-Jul-86  1342	@MC.LCS.MIT.EDU:wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA 	Re: Remaining questions & remarks (2)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86  13:42:30 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 10 Jul 86 16:09:15 EDT
Received: from indiana by csnet-relay.csnet id ah09559; 10 Jul 86 15:54 EDT
Date: Thu, 10 Jul 86 14:06:35 est
From: Perry Wagle <wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: Re: Remaining questions & remarks (2)
Cc: wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA

(2)   <, >, etc are composed solely of "special symbols", and classically are
    predicates.  With this view in mind, perhaps the exception is not so big
    as naive application of Occam's Razor would suggest.  I support essential
    <, >, etc, and the removal of their "xxx?" counterparts.

(5)   Many otherwise portable Scheme programs would die under unrestrained
    interleaving.  I claim that a Scheme should have the semantics of a
    single logical processor no matter what the underlying architecture is.
    I think that mention of parallelism should be left out altogether, as
    any mention would call for ad hoc measures (synchronization primitives?
    bleagh!), and restraint to a "single logical processor" is probably an
    obituary (within ten years or so?).

(7)  I would like to guard input and output commands with INPUT-PORT? and
    OUTPUT-PORT? respectively.  I think closed ports SHOULD be ports, but
    not input or output ports;  I support the predicate: PORT?.

(11)  I would very much like PROCEDURE? and consider continuation objects
    to be procedures.  While appealing, I don't support APPLICABLE? as it
    would be the only type predicate that doesn't name the type its checking
    for.

(12)  I oppose one-armed IFs.  I've been happy with WHEN and UNLESS that
    return NIL when the condition isn't met.

(14)  I have "meta"-procedures that invoke LOAD.  I *demand* that you not cut
    my arms and legs off for "esthetic reasons".

(15)  I think that *all* ASCII characters should be "legibly typable" (e.g.
    #\null, etc), but then I only run on ASCII machines.


∂10-Jul-86  1540	@MC.LCS.MIT.EDU:andy@sun3.ads.ARPA 	My answers to your thirty questions on R↑RS 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86  15:35:50 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 10 Jul 86 18:30:06 EDT
Date: Thu, 10 Jul 86 15:31:12 PDT
From: andy@sun3.ads.ARPA (Andy Cromarty)
To: jar%mit-mc@ads.arpa
Subject: My answers to your thirty questions on R↑RS
Cc: rrrs-authors%mit-mc@ads.arpa

Jonathan,

Here is my list of answers to the specific report-related questions
you posed to the group.  I've only answered the ones I have strong
opinion on.

1. The presence of BEGIN in Scheme is frankly somewhat of an
   embarrasment.  It really should be flushed, but politically
   it's probably too late.  Still, I vote (b).

2. Keep the >? forms.  All predicates should end in ? for
   uniformity.  This kind of consistency is much more important for
   pedagogical purposes than is similarity to CL, Pascal, or any
   other existing language.

4. Substring-move-*: flush.  I think I have simple Scheme definitions
   for these, if anyone needs them once they're flushed.

5. Simply make it clear that evaluation order is unspecified (and
   should not be depended on); to guarantee sequential evaluation 
   of a collection of combinations, use SEQUENCE.

7. Port = port.  Safer that way.

11.  Yes, PROCEDURE?  would be welcome.

12. (if x 1) vs. (cond ((x 1)): I suggest

	(if x 1)			=> 1 iff x, else <unspecified>
	(cond ((x 1)))			=> 1 iff x, else <unspecified>
	(case (not (not x)) ((#t) 1))	=> 1 iff x, else <unspecified>

   This follows the general principle that if you fall off the end
   of a control construct, the results are not guaranteed.  If you
   want a guaranteed return value in your program, you specify one
   using ELSE or the two-armed IF as appropriate; that's what they're
   there for.  This should be phrased to say that ``it is an error''
   to rely on the result of a control construct that returns an
   <unspecified> result.

13.  Flush (define ((((a b) c) d) e) ...) syntax.

14. To me, INCLUDE means "include."  If we want the effect to be
    equivalent to having the loaded text be lexically present,
    INCLUDE is an excellent name, and helps avoid some of the
    concerns people have had about what it means to have a dynamic
    programming environment for a lexically scoped language.  I would,
    however, want to see a resolution to such problems as
	 (IF X (INCLUDE "FOO"))
    If this evaluation depends on the dynamics of the binding
    environment, then "LOAD" is more appropriate.  INCLUDE would
    have to be a non-expression statement, e.g. the above example
    would only be syntactically correct if "FOO" happened to contain
    exactly one or two expressions at the top level of the file, and
    the INCLUDE would always get performed regardless of X's value.

21.  One-based sections.

24.  I guess some people don't like to type and have bad editors, or
    maybe bad pretty-printers.  CALL/CC is scarcely an intuitive
    name; its chief virtue seems to be the number of characters it
    contains.  But it seems to be regionally entrenched; keep it
    "informally optional" to the standard CALL-WITH-CURRENT-CONTINUATION
    if necessary.  (It will not appear in our Scheme implementations.)

26. FORCE and DELAY are new ideas to most readers of the report, at
    least for its SIGPLAN incarnation.  Good pedagogy suggests they
    be put together if possible.

27.  Yes for () in 3.0.2.

30.  I thought the question of immutable objects was lightly treated
    overall.  Rather than remove the reference on p. 14 SS 5.1, I'd
    prefer to see more detail, and perhaps (a) something explicitly
    noting that  set-car!  and set-cdr! are destructors (or
    mutators if you prefer) and (b) the explicit assertion that
    destructors end in ``!'' in Scheme.

------------------------------------------------------------------------
Other topics:

-1+ : I prefer to see this kept, in inessential status.  When I first
    saw it, it struck me as the first time any LISP had gotten this
    right.  It says exactly what it means.  Better no decrement 
    function at all, however, than using "1-" to mean decrement; "1-"
    says exaactly what it *doesn't* mean.

    Since there was a complaint, I might suggest ``minus one plus''
    as the pronunciation for "-1+", as in "minus one plus 3" for 
    (-1+ 3) (or "negative one plus three," if you prefer).  I
    scarcely find SUCC pronounceable in any socially acceptable way,
    and it certainly doesn't seem to me to be a serious alternative.

WHEN: This probably seems like a good idea to people who don't do
    concurrent programming.  When you deal with time in your
    programs, ``when'' already has a confusing enough meaning without
    overloading it to mean IF. For that matter, a couple years from
    now we may want to use WHEN for event management.

S&ICP: I do not know what it means to (as one person admonished)
    ``fix the book''; in particular, I don't know how you recall
    thousands of copies.  Independent of the quality of the
    presentation and choices reflected in S&ICP, which I admit to
    admiring tremendously, I believe that this book has done
    more for Scheme than any other single force in Scheme's history,
    and I believe we should endeavor to support a Scheme compatible
    with it.  Most of my colleages who own the book have it because
    they were interested in obtaining a good book on LISP or a good
    book on programming, and to a person every one with whom I've
    spoken agrees that it is probably the best available for both
    purposes.  Let's not kill the goose that lays our golden eggs.

∂10-Jul-86  1941	@MC.LCS.MIT.EDU:whill%hplabsc@hplabs.HP.COM 	Re:  [Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>: How big would a "minimal" scheme interpreter be?]
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Jul 86  19:41:01 PDT
Received: from hplabs.HP.COM by MC.LCS.MIT.EDU 10 Jul 86 22:35:05 EDT
Received: from hplabsc by hplabs.HP.COM ; Thu, 10 Jul 86 19:32:17 pdt
Received: by hplabsc ; Thu, 10 Jul 86 19:33:39 pdt
Date: Thu, 10 Jul 86 19:33:39 pdt
From: Walt Hill <whill%hplabsc@hplabs.HP.COM>
Message-Id: <8607110233.AA15511@hplabsc>
To: MICHAEL@CS.COLUMBIA.EDU, scheme@MC.LCS.MIT.EDU
Subject: Re:  [Michael van Biema <MICHAEL@CS.COLUMBIA.EDU>: How big would a "minimal" scheme interpreter be?]

MIT CScheme will run on an HP Integral PC with 1.5Meg RAM with room for only
40K items in the heap.

         Walt Hill

∂11-Jul-86  0336	@MC.LCS.MIT.EDU:bc@MEDIA-LAB.MIT.EDU 	MacScheme   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jul 86  03:36:43 PDT
Received: from MEDIA-LAB.MIT.EDU by MC.LCS.MIT.EDU 11 Jul 86 06:31:52 EDT
Received: by MEDIA-LAB.MIT.EDU (5.31/4.8)  id AA06695; Fri, 11 Jul 86 06:31:17 EDT
Date: Fri, 11 Jul 86 06:31:17 EDT
From: William H Coderre <bc@MEDIA-LAB.MIT.EDU>
Message-Id: <8607111031.AA06695@MEDIA-LAB.MIT.EDU>
To: scheme@mc.lcs.mit.edu
Subject: MacScheme



Can someone summarize the MacScheme situation?
I've played briefly with a fairly old version.
I heard there was a new version.
Graphics? Toolbox? Editor (I remember it being a loser)?
Compatibility?

Thank You
"Tzima Narki"......................,...........,.............bc


∂11-Jul-86  0925	@MC.LCS.MIT.EDU:gls@Think.COM 	My comments on the R↑RS 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jul 86  09:25:24 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 11 Jul 86 12:21:28 EDT
Received: from botolph by Godot.Think.COM via CHAOS; Fri, 11 Jul 86 12:18:24 edt
Date: Fri, 11 Jul 86 12:19 EDT
From: Guy Steele <gls@Think.COM>
Subject: My comments on the R↑RS
To: andy@sun3.ads.ARPA, jar%mit-mc@ads.ARPA
Cc: rrrs-authors%mit-mc@ads.ARPA, gls@AQUINAS.ARPA
In-Reply-To: <8607101959.AA12928@Zarathustra.Think.COM>
Message-Id: <860711121914.1.GLS@BOTOLPH.THINK.COM>

    Date: Thu, 10 Jul 86 12:39:26 PDT
    From: andy@sun3.ads.ARPA (Andy Cromarty)

    Jonathan,

    I've enclosed my comments on the R↑3RS in this note
    separately from my answers to your specific questions you asked.
    Hope this helps.  By the way, I know that putting this all together
    involves a lot of work (and sometimes a lot of refereeing), and you
    should be aware that your contribution isn't going unappreciated.   Thanks
    for all the hard work you're putting in, and my apologies in advance
    if I err here due to an insufficiently detailed reading of the report.

Hear, hear!

    ...
    2. As you might expect, I would like to see a somewhat more vigilant
       attitude in warding off the dark forces of Common Lisp.  It is not
       compatibilities or incompatibilities that are gratuitous; it is
       the very act of being concerned with compatibility at all that is
       gratuitous.  We should have our own standards of what a good LISP
       looks like and stick to them.  The first job of a good language is
       to be a good language, not to be just like another bad language
       that's familiar (nor even just like another good language that's
       familiar).  Common Lisp's goals were nearly the opposite of
       Scheme's, and however good a job the CL committee did, we owe them
       no homage.  I recognize that this is more an issue of the design
       of Scheme than of its documentation in a report, but there seems
       to me to be entirely too much concern for similarities and
       dissimilarities w.r.t. Common Lisp in the report.  It may be
       appropriate to discuss the topic of Scheme vs. CL briefly in the
       historical section, but there should be a very clear message to the
       reader that CL followed Scheme -- and continues to, in the sense
       that Scheme is meant to be a progressive attempt at (LISP) language
       design rather than a codification and standardization of existing
       ideas in prior LISPs.   The CL people should be writing reports
       that compare their work to ours, not the other way around.   ``Let
       them eat cake.''  [OK, flame off.]

[a] I think that many papers on Common Lisp have correctly attributed its
debt to Scheme.

[b] I disagree that concern with compatibility is gratuitous.  Perhaps that
concern should be subordinate to other concerns, but when everything else is
truly equal then compatibility is a reasonable criterion for breaking ties.
This is because it is better to be able to tie a feature to something already
familiar than to make a user learn something new.

[c] There should be a very clear message to the reader that Scheme certainly
does owe debts to other sources, and one of them is Common Lisp.  While
Scheme certainly has been the pioneer in the treatment of closures and
functional programming in a Lisp framework, I think it is fair to say that
Common lisp pioneered a rational (forgive the pun) treatment of numeric data
types in a Lisp framework, and my impression is that Scheme learned
something in this area from the Common Lisp experience.

[d] Don't forget that there are some people who worked on both Scheme and
Common Lisp at the same time (I do not count myself as one, by the way), to
whom I am grateful because they learned certain lessons in both contexts at
once and served to transfer ideas in both directions.

    12. I cannot refrain from observing that DO is truly ugly, a
	veritable pig of a construct, and we could have done better.
	We are indeed fortunate that its use under practical circumstances
	is rarely necessary.

I strongly disagree.  DO is a construct that emphasizes the notion that
an iteration can proceed by initializing some state variables and then
repeatedly transforming them while maintaining some invariant until
a condition is reached.  In particular, it emphasizes the fact that
outputs of the iteration as well as inputs can and should be expressed
as iterator-controlled variables.  This is a lesson that the "algebraic"
languages ought to learn.  It is an abomination to see
    sum = 0
    do i = 1 to 10 by 1
      sum = sum + a(i)
    end do
instead of
    do i = 1 to 10 by 1; sum = 0 by a(i); result sum od

    23. NOTES, p.35ff.: This material should stay somehow.  We need to
	make it clear that R↑3 Scheme is not being touted as Yet Another
	Ultimate Solution To The Programming Language Problem, but rather
	as a snapshot of a *process* of good design, for which not all
	answers have yet been found.  We also ought to use the opportunity
	for publicity afforded us by SIGPLAN to advertise some of the thorny
	unsolved problems that need further research, and encourage
	language designers to work on them.

Yes.


--Guy

∂11-Jul-86  0935	@MC.LCS.MIT.EDU:cscott@bfly-vax.bbn.com 	tiny scheme   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jul 86  09:35:10 PDT
Received: from BFLY-VAX.BBN.COM by MC.LCS.MIT.EDU 11 Jul 86 12:26:51 EDT
Date:     Fri, 11 Jul 86 12:22:23 EDT
From:     "Curtis A. Scott" <cscott@bfly-vax.bbn.com>
To:       michael@cs.columbia.edu
cc:       scheme@mc.lcs.mit.edu
Subject:  tiny scheme

It depends on the level of functionality you desire.  A minimal kernel
with only the basic operations as primitives could be very small.  I
wrote a student subset kernel in Z80 assembler which was much less
than 32K bytes, and I believe someone did one for the Apple II of
similar size.  You have then moved much of the size of the system off
into interpreted code in the heap.  None of the "real" systems are
this small; the MIT handcoded 68000 scheme was around 64K of code.


∂11-Jul-86  1142	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: My comments on the R↑RS   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jul 86  11:42:36 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 11 Jul 86 14:42:04 EDT
Received: from ti-csl by csnet-relay.csnet id ab20493; 11 Jul 86 14:24 EDT
Received: by tilde id AA08236; Fri, 11 Jul 86 11:05:52 cdt
Date: Fri 11 Jul 86 10:59:37-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: My comments on the R↑RS
To: andy%sun3.ads@CSNET-RELAY.ARPA, jar%mit-mc%ads@CSNET-RELAY.ARPA
Cc: rrrs-authors%mit-mc%ads@CSNET-RELAY.ARPA,
        Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: Message from "Andy Cromarty <andy@sun3.ads.ARPA>" of Fri 11 Jul 86 04:08:40-CDT
Message-Id: <12221852261.67.BARTLEY@CSC60>

>Date: Thu, 10 Jul 86 12:39:26 PDT
>From: Andy Cromarty <andy@sun3.ads.ARPA>
>   [...]
>2. As you might expect, I would like to see a somewhat more vigilant
>   attitude in warding off the dark forces of Common Lisp.  It is not
>   compatibilities or incompatibilities that are gratuitous; it is
>   the very act of being concerned with compatibility at all that is
>   gratuitous.  ...

I feel that this point of view is not in Scheme's best interest.  Although
many potential converts to Scheme are unsullied by contact with lesser
lisps, others must either be won away from Common Lisp or must live with
both.  Gratuitous differences in syntax and in the naming of standard
procedures make it much more difficult for them to give Scheme a fair
trial.  Also, many of us are working on implementations in which Scheme
and Common Lisp programs want to share data and call each other.
Gratuitous differences in the data types and in the syntax of numbers (for
example) can make this very frustrating.  I fear that Scheme will usually
be the one that loses if a development team decides the two languages are
not sufficiently compatible.

>            ... We should have our own standards of what a good LISP
>   looks like and stick to them.  The first job of a good language is
>   to be a good language, not to be just like another bad language
>   that's familiar (nor even just like another good language that's
>   familiar).  Common Lisp's goals were nearly the opposite of
>   Scheme's, and however good a job the CL committee did, we owe them
>   no homage.  ...

Although a certain amount of compromise is necessary in agreeing on what
is "gratuitous", it certainly is true that any compromise that changed
Scheme from a "good" language to a "bad" one would not be gratuitous.

>          ...  I recognize that this is more an issue of the design
>   of Scheme than of its documentation in a report, but there seems
>   to me to be entirely too much concern for similarities and
>   dissimilarities w.r.t. Common Lisp in the report.  It may be
>   appropriate to discuss the topic of Scheme vs. CL briefly in the
>   historical section, but there should be a very clear message to the
>   reader that CL followed Scheme -- and continues to, in the sense
>   that Scheme is meant to be a progressive attempt at (LISP) language
>   design rather than a codification and standardization of existing
>   ideas in prior LISPs.   The CL people should be writing reports
>   that compare their work to ours, not the other way around.   ``Let
>   them eat cake.''  [OK, flame off.]

I think we've all agreed that explicit references to Common Lisp in the
Report should be minimized.

Regards,
David Bartley
-------


∂11-Jul-86  1642	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	test 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Jul 86  16:41:58 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 JUL 86  18:04:12 EDT
Date: Fri, 11 Jul 86 18:04:44 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  test
To: scheme@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].68642.860711.JAR>

Test message.  Please ignore.

∂12-Jul-86  1837	@MC.LCS.MIT.EDU:RPG@SU-AI.ARPA 	Compatibility with Common Lisp: A meta comment       
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 12 Jul 86  18:37:17 PDT
Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 12 Jul 86 21:37:07 EDT
Date: 12 Jul 86  1835 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Compatibility with Common Lisp: A meta comment   
To:   rrrs-authors@MC.LCS.MIT.EDU


Andy Cromarty comments that it is ``the very act of being concerned with
compatibility at all that is gratuitous.''

I regard it as lucky that this message only went to RRRS-authors, because
it represents a low point in political thinking. Although I am not an
active participant in the Scheme design, many of you know that I use
Scheme in my teaching, my research papers, and my research. When put on
the spot regarding the future of Lisp - in any forum - I point to Scheme
as the hope for the future.

However, I regard myself as a member of the Common Lisp community, and I
had a fair amount to do with its design and acceptance. When I read Andy's
message I felt insulted. Perhaps someone less sympathetic to the Scheme
movement would be completely turned away from Scheme by reading his
message.

If Andy wants to battle the dark forces, they are indeed lined up at the
perimeter. To the vast audience, Common Lisp and Scheme are
indistinguishable.  The alternative is C. If Lisp cannot make a go of it
because other languages are seen as `better,' there will be less interest
in learning Lisp, and fewer people will be able to see the beauty of
Scheme. The battle is to win people over to `lisp programming,' which in
its best clothes is Scheme programming.

To an outsider, a `gratuitious' difference between Common Lisp and Scheme
is seen as evidence that the Lisp world is too religious to understand
real-world concerns. Unless there is a compelling reason to vary from Common
Lisp, I think compatibility is wise.

The Common Lisp community has learned and is learning a lot about how
people are won over to a new standard, and this community has many members
who are Scheme lovers. Perhaps it is a smart move to avoid alienating
them with comments like Andy's? Perhaps the Scheme community would like to
enlist the aid of the large Common Lisp community in advocating Scheme?

Don't let anyone outside this list see Andy's message.

			-rpg-

ps. To be a pissant about it. I guess Andy feels that, because the goals of
Common Lisp were nearly the opposite of Scheme's, the goals of Scheme
are to be:

	non-common
	non-portable
	inconsistent
	inexpressive
	incompatible
	inefficient
	not powerful
	unstable

Common Lisp's goals were not bad. They were the stated ones, plus several
others: gain support among competing dialects, gain advocates from the
commercial Lisp programming world, and develop compromises among enemies. The
stated goals plus these three are such that we are lucky that the result
is as reasonable as it is.


∂13-Jul-86  1528	@MC.LCS.MIT.EDU:andy@sun3.ads.ARPA 	Scheme's DO construct   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 13 Jul 86  15:28:40 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 13 Jul 86 18:29:06 EDT
Date: Sat, 12 Jul 86 19:07:07 PDT
From: andy@sun3.ads.ARPA (Andy Cromarty)
To: rrrs-authors%mit-mc@ads.arpa
Subject: Scheme's DO construct
Cc: andy@ads.arpa, gls%think@ads.arpa
Reply-To: andy@ADS.arpa

Hmm, I seem to have generated some controversy.  I'll attempt to
provide clarifications and responses separately on each topic to
help keep the discussions distinct.  I'll start with "DO."
------------------------------------------------------------------------
	I cannot refrain from observing that DO is truly ugly.... [asc]

	I strongly disagree.  DO is a construct that emphasizes the 
	notion that an iteration can proceed by initializing some state 
	variables and then repeatedly transforming them while maintaining 
	some invariant until a condition is reached. ... [gls]


I think Guy misguessed the source of my displeasure with DO. So I'll
clarify. (Warning: not a short message.)

I have no prima facie objection to the use of iterative constructs,
and in particular, none to supporting iteration in Scheme.   Indeed, I think 
that it is often very effective to think procedurally and iteratively rather
than functionally and recursively.  (I understand these are apples and 
oranges, but the styles are usually associated with each other.)  

There may be interesting extremist arguments in favor of relying solely on 
recursion for repetition,  presumably based on strict minimalism and some 
arguments concerning the elegance of recursion.  But I probably wouldn't buy
them, and in any case that's not what my complaint is about.  If we were going
to be minimalism extremists, we wouldn't provide IF, COND, and CASE in the same
language.  Instead, I think we are trying to design an effective programming
environment while remaining "reasonably" elegant.  The touchstone for the
appropriate degree of minimalism is that we provide the constructs that
a programmer will need, separating functionality out when the programmer's
abstraction of the control process is different (as opposed to merely the
underlying computation being different; hence CASE, IF, and COND).

So given the assumption that we are going to have one or more iteration
constructs, what should they look like and how should we select them?
My claim is that the DO we are using is a poor choice, and moreover,
that it probably reflects a correspondingly poor choice in selection criteria.

In a nutshell, DO does too much.  It creates variables, binds them,
provides iteration, rebinds variables at tactically pleasing times,
tests a conditional expression, applies an implicit SEQUENCE to most
of its arguments, returns the result of evaluating an optionally present
expression... whew!

I submit that we have CommonLisp's DO (which is in use in other LISPS too,
of course) principally because it was being used by other LISPs and no one
really stopped to think what a good iteration construct for Scheme would
look like starting from first principles.  We just grabbed what (some) (LISP)
programmers currently are using without treating this as an important
design problem.

I also submit that DO is too complex and that this complexity violates
two fundamental principles of good programming language construct design:

1. Keep constructs simple so people can learn, understand, read, debug, 
   and maintain them easily.
2. Each function should do one thing, and do it well.  (No pun intended.)

Just to take a few pot shots at DO: we don't need variable binding and
creation, since we already have the LET family to do that nicely for us.
We don't need to confuse conditional exit from an iteration (i.e. using
a predicate expression) with FOR-class iteration that occurs, e.g.,
a predictable number of times and/or over a predictable set of values.
Certainly it's nice to have all these things around when you want them;
my point is simply that an iteration construct doesn't need to provide
all of them, that we can make intelligent choices about which ones
a given construct is to provide, and that if DO needs to contain all of
them, then the burden of proof is on those who would make that claim.

To reframe the challenge, the question is not whether you can come up
with times when you need conditional exit, and times when you need
FOR-style iteration, and... etc.; but rather, whether you can convincingly
demonstrate that all are needed in one iteration construct that appears in
the language definition.

Let me pose a few alternatives.  Bear in mind that these are strawman
options, for illustrative purposes. If you don't like keywords in your
control constructs, imagine the examples without them.

(FOR i IN <list> DO <forms>) -- Evaluates <forms>, to which an implicit
SEQUENCE is applied, with i bound to successive values of <list>.

[This is like FOR-EACH except that you have the current value bound to
a lexically apparent locally-created locally-bound variable i.  This is about
as similar to FOR-EACH as, say, COND and CASE are to each other.]


(VARYING i FROM n TO m BY s DO <forms>) -- Binds i to n, n+s, n+2s, ...
and evaluates <forms>, to which an implicit SEQUENCE is applied, for
each such binding, until i>m.  Returns the result of the last evaluation
of <forms>.

[This is the classic FOR-loop construct used when you know the range
of values in advance, e.g. when you are stepping through a vector.]


(REPEAT n TIMES <forms>) -- Evaluates <forms>, to which an implicit
SEQUENCE is applied, n times. Returns the result of the last evaluation
of <forms>.

[Not frequently used, but highly perspicuous on those occasions when
this is exactly what you want to do.]


(WHILE <test> DO <forms>) -- Repeatedly evaluates <forms>, to which an
implicit SEQUENCE is applied, until <test> evaluates to #F, like
Pascal's WHILE.

[There's some interesting research by Jeff Bonar, among others,
with empirical results suggesting that Pascal's WHILE loop is actually
a dangerous, hard-to-learn construct.  This is because (a) the classic
phase problem that occurs when you use a WHILE loop in a PROCESS,READ
paradigm is harder to learn than the more intuitive READ,PROCESS model,
and (b) beginners often think that WHILE really means "while," i.e.
"whenever <test> is true, do <forms>" or "the moment <test> would become
false, exit the loop."  I also dislike the cooption of this word for this
iterative processing application, since its more intuitive meanings
actually might be useful in concurrent processing applications.  In any
case, when not used in a PROCESS,READ paradigm, the construct (whatever
its name) is often quite useful.]


Hmm, that's a lot of extra stuff in a language to take the place of
one DO construct, isn't it?  But that's precisely the point.  DO is
a microcosm of MacLisp's and, by inheritance, Common Lisp's invasive 
featurism.  In the extreme, we could create a function F(x) and specify
which entire program we wanted simply by feeding F the proper number.
Many people would regard such a Goedlization of programs as a positive
step, if only they could determine which number to feed F. But: we wouldn't
call it programming; we wouldn't call F a "control construct" in the
sense that we normally use the word; and perhaps most importantly, we
wouldn't know how to meaningfully specify the x.  Forgiving the hyperbole,
that is also true of DO: it is an expert's construct with options sticking 
out all over and no coherent design principles underneath, hard to learn 
and remember and even harder to read and understand quickly on sight.

I have performed the following informal experiment.  I had one or
two of the people working with me who were true devotees of LOOP
and DO go back and recode fairly large (5000-15000 lines) LISP programs,
ripping out LOOP and DO and putting in DOLIST, DOTIMES, and mapping
functions.  I should say that they did it "kicking and screaming," not
because of the work involved but because they so loved all the features
that LOOP offered.  But a couple weeks later, they came back and said:

"You know, LOOP is really evil!"
"My code is infinitely easier to read and maintain now."
"I had no idea how ugly and impenetrable all that DO and LOOP code was
 from all those `features' of DO and LOOP I was using."
"You have to have something seriously wrong with your head to be able to
 use DO fluently."
"I'm not going to use LOOP again!"

I should say that the principal guy I have in mind here got his degree at
MIT.  We're talking the hardest of sells, and when the dust had cleared,
he came to the conclusion that DO and LOOP are morally reprehensible.

We need to remember that programs are written not only to be executed,
but also to be read; and that well over 50% of programmer time is
spent maintaining existing code.  Clear, clean, well-designed control
constructs can go a long way towards easing this burden.   DO does not
seem to qualify as such a construct; rather, it seems like the incidental
union of numerous such constructs.  We might be able to make a major
contribution to the utility of LISP in "practical" programming applications
by updating Scheme's iteration constructs so they provide better, cleaner,
more direct support for the variety of iteration models that are already
implicit in the code we write.
						asc

∂14-Jul-86  0252	@MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Flaws of form   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  02:52:43 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Jul 86 05:52:54 EDT
Received: from tektronix by csnet-relay.csnet id aa01226; 14 Jul 86 5:49 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA28438; Sun, 13 Jul 86 10:01:39 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA21626; Sun, 13 Jul 86 10:04:09 PDT
Date: Sun, 13 Jul 86 10:04:09 PDT
From: Norman Adams <adams%tekchips.tek.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607131704.AA21626@tekchips.TEK>
Subject: Flaws of form
To: rrrs-authors@MC.LCS.MIT.EDU

I would prefer to see no dedication in preference to making the dedication
serious.  I think a serious dedication would read as insincere because
the Scheme report is an obvious parody of the Algol 60 report.

As much for my asusement as for anything else, I wrote this explanation:

The Algol 60 report is gravely earnest.  Among its many firsts, Algol was
first to use a grammar-like construct to define its syntax.  The first
report -- "Preliminary report - International Algebraic Language" -- as
well as the revision, were published as cover stories in the
@i(Communucations of the ACM) (*).  The report was the culmination of an
international effort, followed with international attention.  In the style
of world war commentary, the reader learns of the Zurich meeting, the Paris
meeting, and of the seven European representatives who held a final
prepatory meeting in Mainz in December 1959.  And let us not forget the
seven American representatives with a similar quest, in Boston that same
year.  We are spared the details of the lunch meats; judged, with Ph.D.
precision I am certain, to be expendable from the accounting.  In each
re-reading, I look (in vain) for the mention of Teller and Oppenheimer;
surely they were involved too.  It is in this intensely sober context that
we read the full page eulogy of William Turanski (**), who died after being
struck by a car the day before the 1960 conference in Paris.  

(*)  CACM v1 #12, 1958; CACM v6 #1, 1963
(**) CACM v3 #5, 1960, p 298

Scheme is fun and happy, and a bit quirky -- or are CDR and CAR and so many
relatives the ideal names for those procedures?  Scheme is as serious as
LAMBDA, but as casual as CAR.  Alas, what has become of dear PROGN?  The
names are arbitrary and incidental; CAR and CDR remind us.  Scheme is as
much an approach as a detailed concrete specification.  But to be taken
seriously, for Scheme to be widely used, we must have the details and
concretions; they are essential but unimportant.

The Algol 60 report is almost ludicrous in its sobriety.  If we use the form
of Algol 60 to present happy little Scheme, we cannot avoid the parody;
try as we might.

Still, I think there is good reason to use the form.  Presenting Scheme in
the form of the Algol 60 report may capture the attention of those who
clump together and ignore all Lisp-like languages because the culture is so
different from what they know.  The contrast with @i(Chine Nual) and
@i(CLtL) is important.  Perhaps Lisp can be other than a bag of features of
a metastasizing runtime environment.  Perhaps it can even be described in
the style of the day!  

Following the model of Algol 60 exactly points out that the form of
description is itself an arbitrary convention; and the point is made in
perfect Scheme style.  Just as Scheme can provide the "their" control
constructs, it can be described in "their" form.  

The parody pokes fun at all those essential but unimportant details.  
It is the perfect couch for Scheme.

So for all this, I find a serious dedication inappropriate.  Algol 60's
dedication was grave; to an Algol soldier, killed in his prime (he was 35).
Scheme's dedication should be to something unimportant.  "Dedicated to the
memory of dynamic binding.", as Jonathan once suggested, fits well.  It
seems to me so much better than to try to be as somber and important as
Algol 60.  I think we would look foolish in the attempt.  

-Norman
-------

∂14-Jul-86  0325	@MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Flaws of form   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  03:24:56 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Jul 86 06:25:26 EDT
Received: from tektronix by csnet-relay.csnet id aa01226; 14 Jul 86 5:49 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA28438; Sun, 13 Jul 86 10:01:39 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA21626; Sun, 13 Jul 86 10:04:09 PDT
Date: Sun, 13 Jul 86 10:04:09 PDT
From: Norman Adams <adams%tekchips.tek.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607131704.AA21626@tekchips.TEK>
Subject: Flaws of form
To: rrrs-authors@MC.LCS.MIT.EDU

I would prefer to see no dedication in preference to making the dedication
serious.  I think a serious dedication would read as insincere because
the Scheme report is an obvious parody of the Algol 60 report.

As much for my asusement as for anything else, I wrote this explanation:

The Algol 60 report is gravely earnest.  Among its many firsts, Algol was
first to use a grammar-like construct to define its syntax.  The first
report -- "Preliminary report - International Algebraic Language" -- as
well as the revision, were published as cover stories in the
@i(Communucations of the ACM) (*).  The report was the culmination of an
international effort, followed with international attention.  In the style
of world war commentary, the reader learns of the Zurich meeting, the Paris
meeting, and of the seven European representatives who held a final
prepatory meeting in Mainz in December 1959.  And let us not forget the
seven American representatives with a similar quest, in Boston that same
year.  We are spared the details of the lunch meats; judged, with Ph.D.
precision I am certain, to be expendable from the accounting.  In each
re-reading, I look (in vain) for the mention of Teller and Oppenheimer;
surely they were involved too.  It is in this intensely sober context that
we read the full page eulogy of William Turanski (**), who died after being
struck by a car the day before the 1960 conference in Paris.  

(*)  CACM v1 #12, 1958; CACM v6 #1, 1963
(**) CACM v3 #5, 1960, p 298

Scheme is fun and happy, and a bit quirky -- or are CDR and CAR and so many
relatives the ideal names for those procedures?  Scheme is as serious as
LAMBDA, but as casual as CAR.  Alas, what has become of dear PROGN?  The
names are arbitrary and incidental; CAR and CDR remind us.  Scheme is as
much an approach as a detailed concrete specification.  But to be taken
seriously, for Scheme to be widely used, we must have the details and
concretions; they are essential but unimportant.

The Algol 60 report is almost ludicrous in its sobriety.  If we use the form
of Algol 60 to present happy little Scheme, we cannot avoid the parody;
try as we might.

Still, I think there is good reason to use the form.  Presenting Scheme in
the form of the Algol 60 report may capture the attention of those who
clump together and ignore all Lisp-like languages because the culture is so
different from what they know.  The contrast with @i(Chine Nual) and
@i(CLtL) is important.  Perhaps Lisp can be other than a bag of features of
a metastasizing runtime environment.  Perhaps it can even be described in
the style of the day!  

Following the model of Algol 60 exactly points out that the form of
description is itself an arbitrary convention; and the point is made in
perfect Scheme style.  Just as Scheme can provide the "their" control
constructs, it can be described in "their" form.  

The parody pokes fun at all those essential but unimportant details.  
It is the perfect couch for Scheme.

So for all this, I find a serious dedication inappropriate.  Algol 60's
dedication was grave; to an Algol soldier, killed in his prime (he was 35).
Scheme's dedication should be to something unimportant.  "Dedicated to the
memory of dynamic binding.", as Jonathan once suggested, fits well.  It
seems to me so much better than to try to be as somber and important as
Algol 60.  I think we would look foolish in the attempt.  

-Norman
-------

∂14-Jul-86  0641	@MC.LCS.MIT.EDU:OXLEY%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: Compatibility with Common Lisp: A meta comment       
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  06:40:56 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Jul 86 09:41:16 EDT
Received: from ti-csl by csnet-relay.csnet id aa01646; 14 Jul 86 9:37 EDT
Received: by tilde id AA09613; Mon, 14 Jul 86 08:20:24 cdt
Date: Mon 14 Jul 86 08:11:52-CDT
From: Don Oxley <OXLEY%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: Compatibility with Common Lisp: A meta comment   
To: RPG%su-ai@CSNET-RELAY.ARPA, rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
In-Reply-To: Message from "Dick Gabriel <RPG@su-ai.ARPA>" of Sat 12 Jul 86 18:35:00-CDT
Message-Id: <12222608155.17.OXLEY@CSC60>

I must second Dick Gabriel's reply.  A little "friendly rivalry" with
Common Lisp is fine, but the ultimate acceptance of Lisp (of either
dialect) is the crucial concern.  I am probably as biased toward Scheme
as anyuone, but if Scheme is to succeed, it will owe a significant debt
to Common Lisp. 

        --Don
-------


∂14-Jul-86  0741	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Common Lisp   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  07:41:27 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 14 Jul 86 10:41:54 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from jymme.sun.uucp by linus.MENET (1.1/4.7)
	id AA19058; Mon, 14 Jul 86 10:41:36 EDT
Posted-Date: Mon, 14 Jul 86 10:38:32 edt
Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3)
	id AA07736; Mon, 14 Jul 86 10:38:32 edt
Date: Mon, 14 Jul 86 10:38:32 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8607141438.AA07736@jymme.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Common Lisp

I certainly qualify an no fan of Common Lisp, however, I too would
like to point out a simple argument against gratuitous
incompatibilities with Common Lisp.  Scheme's impact will be limited
if it is very difficult to convert CL code to Scheme, even if many
agree it is a superior language.  The best way to port CL to Scheme is
in an environment that supports both languages.  To me, Scheme would
be an excellent language in which to implement Common Lisp.  A Scheme
implementation of Common Lisp would facilitate the conversion of CL
code by allowing versions the program to be written in a mixture of
both languages.  Let's not make a Scheme implementation of Common Lisp
such a pain that no one will do it.
John

∂14-Jul-86  1008	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[ANDY: dedication]  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  10:08:39 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 JUL 86  13:09:07 EDT
Date: Mon, 14 Jul 86 13:08:53 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  [ANDY: dedication]
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].69636.860714.JAR>

Date: Mon 14 Jul 86 02:09:08-PDT
From: Andy Freeman <ANDY at sushi.STANFORD.EDU>
To:   jar at AI.AI.MIT.EDU
Re:   dedication
Message-ID: <12222563967.24.ANDY@sushi.STANFORD.EDU>

Has everyone else forgotten that Knuth dedicated his series to a 650
at case?

-andy

∂14-Jul-86  1337	@MC.LCS.MIT.EDU:RPG@SU-AI.ARPA 	Use of DO in Common Lisp Code    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  13:33:33 PDT
Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Jul 86 16:33:54 EDT
Date: 14 Jul 86  1332 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Use of DO in Common Lisp Code
To:   rrrs-authors@MC.LCS.MIT.EDU


I looked at a spectrum of code in the Lucid implementation of Common
Lisp to see how DO is used where DOLIST and DOTIMES could not
be used. The breakdown of use of iteration is this:

	the frequency of use of DO is the same as the use of DOTIMES 
	and DOLIST combined

	the use of LABELS/FLET is used as often as DOLIST.

The uses of DO in place of DOTIMES and DOLIST are interesting. 
Sometimes the stepper is not CDR, so the use of DO is exactly
like DOLIST, but with the stepper (and end test) different; typically:

	(DO ((current data-structure (next-data current)))
	    ((empty-data current)) ...)

Sometimes the use is exactly like DOLIST, but the test is different.

	(DO ((l l (cdr l)))
	    ((end-test l)) 
	    (let ((x (car l)))
	     ...))

But the most frequent use (by a margin of 3 to 1) is a combination of
DOTIMES and DOLIST:

	(do ((l l (cdr l))
	     (i 0 (1+ i)))
	    ((null l))
	    (let ((x (car l)))
	     ...))

The use of DO outside of these paradigms is almost non-existent. Hairier
control structures are usually done with LABELS/FLET, and there are
3 large ATN's in the implementation, written with (glarg) TAGBODY.

One principle of Lisp design that DO follows is that the binding of the
iterator, its initial value, and its updator are apparent immediately upon
inspection - they are usually on one line. This principle is the basis of
(LET ((x value)) ...) being preferred to ((lambda (x ...) ...) value ...):
X and VALUE are not near each other on the page.

I don't have a proposal to make, but this data might be of use in thinking
about iteration in Scheme.

			-rpg-


∂14-Jul-86  1448	@MC.LCS.MIT.EDU:goodhart%cod@nosc.ARPA 	Scheme Request 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  14:46:18 PDT
Received: from bass.ARPA by MC.LCS.MIT.EDU 14 Jul 86 17:27:39 EDT
Received: by bass.ARPA (5.31/4.7)
	id AA09836; Mon, 14 Jul 86 14:25:49 PDT
Received: by cod.ARPA (5.31/4.7)
	id AA13068; Mon, 14 Jul 86 14:25:46 PDT
Date: Mon, 14 Jul 86 14:25:46 PDT
From: Curtis L. Goodhart <goodhart%cod@nosc.ARPA>
Message-Id: <8607142125.AA13068@cod.ARPA>
To: scheme@mit-mc.ARPA
Cc: goodhart@nosc.ARPA
Subject: Scheme Request

-------

I am interested in obtaining a version of Scheme that will run on a
VAX 11/780 running VMS 4.2 OR a PDP-11/70 running Unix 2.9 .

Can you provide me some info on this?

I also recall that I may be able to FTP a copy of Scheme?

Are there user manuals available too?

Also, I will be at MIT in the Fall and probably take Ableson, and Sussman's
course, in which Scheme is used.  Are there any crucial differences 
between the version I might get through you and the version and MIT?

Thanks,

       Curt Goodhart  (goodhart@nosc     on the arpanet)

-------


∂14-Jul-86  1514	@MC.LCS.MIT.EDU:andy@sun3.ads.ARPA 	Scheme vs. Common Lisp, #1: Politics   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  15:13:31 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 14 Jul 86 17:33:32 EDT
Date: Mon, 14 Jul 86 14:31:19 PDT
From: andy@sun3.ads.ARPA (Andy Cromarty)
To: rrrs-authors%mit-mc@ads.arpa
Subject: Scheme vs. Common Lisp, #1: Politics
Cc: andy@ads.arpa, gls%think@ads.arpa, rpg%su-ai@ads.arpa
Reply-To: andy@ads.arpa

This is the first of two notes on CommonLisp vs. Scheme.  I have
written two notes in an attempt to separate political concerns
from design concerns, in part to keep them clear in my own mind and
in part in consideration of those of you who, like me, generally
have neither the time nor the temperment for long political debates
on the ARPANET.  This note concerns the politics, or what I
think of (perhaps a little unkindly) as the "form rather than
the content" of the CL-Scheme issue.  Those of you who stick it out
and read through this note (and the ones that are sure to follow)
should bear in mind that, as we've already seen, politics is
necessarily a somewhat more personal discipline than is the
technology most of us are really interested in, and for that reason
writing styles for the political notes can be expected to differ
from those composed with primarily technical purposes in mind.
					asc
------------------------------------------------------------------------
Shortly after receiving Dick's flame, the following scenario popped
into my head.  You are listening in on a phone conversation somewhere
in Arlington, Virginia.

	Squires: Clint, I hear a rumor that Andy Cromarty is concerned
		 about CommonLisp's influence on the development of
		 Scheme.

	Kelly: Scheme?

	Squires: Yes, another kinky LISP dialect being designed by some
		 researchers.  It only has a fraction of CommonLisp's
		 features and they can't quite seem to decide what
		 it should look like.

	Kelly: Well, Steve, I guess I'll have to ask you to simply
		rescind DARPA's support for CommonLisp, then, and
		from now on we'll require all our AI projects to
		use Structured COBOL.


I suppose I should be flattered at the suggestion that a few sentences
from me would reshape the course of LISP history, especially coming as
it does from Dick Gabriel.  But somehow I give the research funding
community and the commercial tool market a little more credit for
indepedence of thought than this scenario (or Dick's note) suggests.

Perhaps more importantly, I am somewhat troubled by the idea that
Dick would advocate censorship of ideas and opinions concerning LISP
design and development (viz. his instructions that we "Don't let
anyone outside this list see Andy's message.").  My assumption is
that the RRRS-AUTHORS list exists for the purpose of supporting "open
discussion within a closed community" concerning what form Scheme
should take, and that we all implicitly agree to attempt to ground
our argumentation for our favored alternative views on a substantive
technical basis.  In this regard, I probably agree with the
suggestion that my comment "represents a low point in political
thinking."  I think the implied converse option -- that we all need
to suppress concern or public discussion about the *costs* of CL
compatibility, or for that matter, any other dangerous thoughts we
might have -- represents a new high water mark in politicization
of the Scheme design process, and I would not feel complimented to be
accused of having set that new standard.  Certainly there are others
in the Scheme community with whom I disagree, but I cannot imagine
proposing (for example) that we censor Dan Friedman because his
ideas about internal DEFINE differ from mine.  Quite the contrary: I
look forward to hearing why alternative views are held; and when I
decide I can't stand the heat, *I* get out of the kitchen.

But yes, please don't repeat my messages outside this community.  I
think we all assume that our discussions are held reasonably private
by this community, since this is still a design-in-progress, and at
the present I'm sensitized by having been poorly quoted a little too
often in the press recently.  (And anyway, if anyone at DARPA
wants to know what I think of CL, they have my phone number.)

Now let's take a good hard political look at who disagreed most
vocally with my comment.  The few responses I've received so far all
have been from competent LISP designers and implementors, to be sure.
But it is also true that they have been from: the implementor(s) of
Texas Instruments' Common Lisp and Scheme products; the author of the
premier Common Lisp text; and the president of the most successful
and best know Common Lisp product company in the world.  In addition,
many or most of these people were personally involved in the Common
Lisp design effort.  Their credentials are impeccable, but their
goals and commitments may not be the same as those of, say, a
professor who is using Scheme for its pedagogical value and has no
career or financial stake per se in the long-term viability or
political acceptance of this year's best production quality LISP
environment.  I certainly believe that having their views represented
is critical to a good Scheme's development, and I made it clear in my
original note that I do consider myself to be an outlying point in
the distribution of views on CL vs. Scheme.  But I think they are,
too; and let us not assume that the most vociferous advocates of
extreme positions (myself included) represent either the norm or the
best compromise position to take.

Since Dick couldn't see from his location down the street that my
tongue was towards the side of my mouth when I used the term "dark
forces," let me say that (a) I think Common Lisp is one of the most
successful technology results of any standardization committee I've
seen and (b) my reference was to the risk of Scheme becoming just
like Common Lisp, rather than a criticism of the quality of Common Lisp 
as a LISP.  Overall, Common Lisp is very good at being what it tries to
be.  I am utterly unconvinced that that's what Scheme is trying to
be, however.  I will treat the question of the goals of the two
languages in my companion note, but for now suffice it to say that
the idea that these languages have (forgive the pun) common goals
strikes me as nonsensical.  If that were true, we could submit Guy's
excellent book to SIGPLAN and retire this list.  I might go so far as
to say that it is precisely because Scheme exists that Common Lisp
can be successful, in the following sense: Those of us who are
concerned with what LISP should look like for the next several
decades can preoccupy ourselves with design debates over Scheme
morality, while people like Dick and Guy go on to take a snapshot of
what the community knows about good LISP design and then integrate
that knowledge, addressing and overcoming all the political obstacles
along the way, to produce a viable, saleable LISP product.  And good
luck to them; but I do not see that Lucid's chimeras need to be ours.

Rather than worry that people will learn that there is more than one
LISP, let's advertise the fact.  Let's make it clear that LISP is an
ideal language for embedding new constructs in, and that the presence
of a good heavily-featured standardized dialect has not quenched the
long-standing historical drive for LISPers to remain at the
forefront of programming language and programming environment design.
Let's advocate a plethora of LISP-like languages to get people out of
the Pascal-derivative language design syndrome and instead get them
directly and cleanly addressing individual hard language design
problems, like the keyword shadowing problem, design of appropriate
multiprocessing constructs, embedding of evidential reasoning
techniques into a programming language, integration of advanced
database technology into the programming environment in a coherent
fashion, getting distributed inheritance graphs to work across
loosely-coupled processors, and (somebody, please!) developing a
reasonable model of I/O.  Let's get them thinking that LISP is not
dead, that it is not a "solved problem," that it's there to
experiment with, and that there are and will continue to be good
reasons for all the debates we engage in on how languages should be
designed.

					asc

p.s. Dick, if you're still pissed off at me, we can go out for
     dinner at the LISP conference and you can throw darts at me.

∂14-Jul-86  1607	@MC.LCS.MIT.EDU:RPG@SU-AI.ARPA 	Politics     
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  16:07:16 PDT
Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Jul 86 18:59:35 EDT
Date: 14 Jul 86  1557 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Politics 
To:   rrrs-authors@MC.LCS.MIT.EDU


Naturally I'm not pissed at Andy. Were I truly pissed, and truly
flaming, my message would have begun, ``Andy, you total and complete
bagbiter, you are such a big loser that they had to extend the
city limits to include....''

My point was that I could imagine someone forwarding Andy's vitriol
to Common-Lisp or ARPA-BBOARDS and thereby lose some allies that
we, who are Scheme lovers one and all, would prefer to not lose if
at all possible. 

Someday I'd like Lucid to be the ``most successful and best-known
supplier of Scheme products,'' on that happy day when Common Scheme
becomes the standard.

Homage, an item of low cost to the RRRS-authors, buys a lot from the
Common Lisp troops. Messages like Andy's, keyboard-in-cheek as they
may be, possibly buy more grief than the fun of typing them gains.

Politics and science are not so radically removed from each other. When
one propose some technical viewpoint, his goal is to have it accepted,
usually before he dies. Having his viewpoint accepted helps his
self-esteem, his quest for fame as a scientist, his reach for tenure. This
isn't much different from politics, in which the goals are probably
self-esteem, fame, and a reach for office.  Although there may be more
technical content to a technical debate, the tactics used in arguing for a
political end really don't differ significantly.

This design committee should aim at producing the best possible Lisp.
If that happens to mean that nothing in it is like the corresponding
thing in Common Lisp, that's fine. All technical debate regarding these
choices should be open. If nothing in Scheme is like the corresponding thing
in Common Lisp simply because Common Lisp is bad, and disjointness is a
goal, then I think this design committee will have blown it.

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

On a related note, now that there has been a fair bit of experience with
Common Lisp, it might be worthwhile for this group to ask some of the 
Common Lisp hackers about their experience with the parts of Common Lisp
that the Schemers find objectionable. Similarly, it might be instructive to
look at what the Common Lisp hackers find nice about Common Lisp that might
be surprising.

			-rpg-


∂14-Jul-86  1702	@MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA 	call-with-xput-port vs. call-with-xput-file 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  17:00:48 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Jul 86 19:42:14 EDT
Received: from indiana by csnet-relay.csnet id ac02754; 14 Jul 86 19:26 EDT
Date: Mon, 14 Jul 86 11:47:21 est
From: Kent Dybvig <dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: call-with-xput-port vs. call-with-xput-file

I favor changing call-with-input-file and call-with-output-file to
call-with-input-port and call-with-output-port.  However, I have some
questions related to the change and to ports in general.

1.  I saw lots of confusion over the fact that you open a file (with
open-input-file and open-output-file) but close a port (with close-
input-port and close-output-port).  Changing the "call-with" names
could increase the confusion.  Should we change open-input-file and
open-output-file to open-input-port and open-output-port?

2.  I have added string ports to Chez Scheme and need to choose names.
If we have call-with-...-file and open-...-file, I can introduce the
names call-with-...-string and open-...-string.  On the other hand,
if we have call-with-...-port and open-...-port, I can introduce the
names call-with-...-string-port and open-...-string-port.  The names
are longer but perhaps more descriptive.  How do these names sound?
The point of this question is that any names we choose should
generalize to other types of ports.

3.  Currently, there is no way to change the current ports to anything
other than a freshly-opened file (as with the inessential with-input-
from-file and with-output-to-file).  Stylistically, I think it is
better to never change the standard ports.  But if they can be changed,
I'd like to have a way for a debugger, say, to change them back to an
existing file (usually the original current ports), so that anything
the user executes goes to the expected place.  Without this we cannot
hope to write a reliable portable debugger (and debug code with calls
to with-input-from-file or with-output-to-file).

4.  Also, there is no way to change the current ports permanantly.
That is, it is not possible to write (set-current-input! <port>) or
(set-current-output! <port>).  Again, I don't think this is good
practice, but some might rue the inability to do so.

5.  Why is call-with-input-file essential and open-input-file not?
If call-with-input-file is analogous to call-with-current-continuation,
why do we not have (call-with-new-string <length> <proc>) instead of
make-string or (call-with-pair <obj1> <obj2> <proc>) instead of cons,
etc?  Because call-with-current-continuation is special---a function
make-continuation would be problematic.  In short, while I see the
merit in with-input-from-file since it closes the file and rebinds a
standard port, I cannot see the merit in call-with-input-file.  Can
we flush call-with-input-file and call-with-output-file and promote
open-input-file and open-output-file to essential status?


∂14-Jul-86  1814	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Scheme Request 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  18:06:40 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 JUL 86  21:00:38 EDT
Date: Mon, 14 Jul 86 20:58:54 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Scheme Request
To: goodhart@NOSC-COD.ARPA
cc: goodhart@NOSC.ARPA, scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 14 Jul 86 14:25:46 PDT from Curtis L. Goodhart <goodhart%cod at nosc.ARPA>
Message-ID: <[AI.AI.MIT.EDU].69927.860714.JAR>

    Date: Mon, 14 Jul 86 14:25:46 PDT
    From: Curtis L. Goodhart <goodhart%cod at nosc.ARPA>

    I am interested in obtaining a version of Scheme that will run on a
    VAX 11/780 running VMS 4.2 OR a PDP-11/70 running Unix 2.9 .

I think most or all of your questions are answered by the contents of
the file "LSPMAI;SCHEME IMPLS" available on Internet hosts MIT-MC,
MIT-MX, and MIT-AI (I have copied it around to improve its
accessibility, in case one or two of these machines are down).

By the way, I'll mail this file (about 17K) to anyone who requests it,
although if you can FTP it that's preferable.  These machines aren't
finicky about usernames or passwords or things like that.

Jonathan

∂14-Jul-86  2156	@MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA 	the colon (:) in identifier syntax
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  21:55:58 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Jul 86 00:56:25 EDT
Received: from indiana by csnet-relay.csnet id aj05326; 15 Jul 86 0:48 EDT
Date: Mon, 14 Jul 86 21:34:01 est
From: Kent Dybvig <dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: the colon (:) in identifier syntax

Can we omit colon (:) from the enumeration of characters that can
be used in identifiers, to allow implementations to support some
sort of package system using colon as the separator?


∂14-Jul-86  2159	@MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA 	exp versus expt    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86  21:59:46 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Jul 86 00:56:33 EDT
Received: from indiana by csnet-relay.csnet id ak05326; 15 Jul 86 0:49 EDT
Date: Mon, 14 Jul 86 21:47:54 est
From: Kent Dybvig <dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: exp versus expt

We have a way to find an exponent of e (exp n) and of an arbitrary
base (expt b n).  We have a function to find the log base e (log n)
but not the log in an arbitrary base.  How about adding (log n b)?

Why do we have (expt b n)?  We could instead give exp an optional
argument specifying the base, i.e., (expt b n) => (exp n b).  Why
is it not done this way in Common Lisp, as it is for log?  Perhaps
because the argument order would seem backwards?

Kent


∂15-Jul-86  0951	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	convergence    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jul 86  09:50:59 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 JUL 86  12:51:31 EDT
Date: Tue, 15 Jul 86 12:51:27 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  convergence
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].70360.860715.JAR>

Apparently we could go on forever thinking of and arguing over ways to
improve the language.  If you have changes you want considered for the
SIGPLAN version of the report, please send them right way (actually,
send them in several months ago).  Otherwise PLEASE just sit on them for
a while, and when this report is out, then let's start discussing the
next version.  For now, orient your messages towards achieving
stability.  If you want perfection then nothing will ever get published.
And, as they say in the soaps, I need to get on with my life.

Thanks
Jonathan

∂15-Jul-86  1807	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: Scheme's DO construct 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jul 86  18:07:03 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Jul 86 21:07:47 EDT
Received: from tektronix by csnet-relay.csnet id aa14951; 15 Jul 86 20:49 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA29117; Tue, 15 Jul 86 15:50:33 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA19578; Tue, 15 Jul 86 15:52:54 PDT
Message-Id: <8607152252.AA19578@tekchips.TEK>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: Scheme's DO construct
Date: 15 Jul 86 15:52:52 PDT (Tue)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

There are two things to be said in defense of Scheme's DO:

    1.  Unlike most general purpose iteration constructs, DO is useful
        for functional programming.
    2.  DO is the only general purpose iteration construct in Scheme
        that doesn't force you to think up a name (such as LOOP) for
        the loop.

This is a long message, but the two points above are the gist of it.

It seems to me that Andy has missed the first point entirely, considering
his remarks that:

    I have no prima facie objection to the use of iterative constructs,
    and in particular, none to supporting iteration in Scheme.   Indeed, I
    think that it is often very effective to think procedurally and
    iteratively rather than functionally and recursively.  (I understand
    these are apples and oranges, but the styles are usually associated
    with each other.)

    ...

    I have performed the following informal experiment.  I had one or
    two of the people working with me who were true devotees of LOOP
    and DO go back and recode fairly large (5000-15000 lines) LISP programs,
    ripping out LOOP and DO and putting in DOLIST, DOTIMES, and mapping
    functions.  I should say that they did it "kicking and screaming," not
    because of the work involved but because they so loved all the features
    that LOOP offered.

LOOP is indefensible, but Andy is mistaken to lump DO with LOOP.

If by "mapping functions" Andy here means the standard Scheme mapping
functions, then MAP is the only functional alternative to DO that Andy
offered his people.  MAP isn't general enough to replace DO, and DOLIST,
DOTIMES, and FOR-EACH are completely useless for functional programming.
Thus it seems that in the name of style Andy was coercing his people to
convert functional programs that use DO into non-functional programs.

It seems to me that if we truly want to discourage people from writing
functional programs, a more effective way to do it would be to change
Scheme so people can't program in the functional style until they master
a set of arbitrarily chosen rules for inserting tokens like #' and FUNCALL
into their programs.

Let's consider the functional alternatives to DO using a simple example.
The example is not too simple; it cannot easily be written using Scheme's
standard mapping procedures.  (Aside:  In the example, SEQUENCE is a
procedure, not a special form, so this is not portable Scheme code.
The name SEQUENCE was meaningful to my audience, so I used it anyway.
As I recall the discussion at Brandeis, SEQUENCE as a special form was
supposed to disappear over time so we could use the name for such higher
purposes, and I was very disappointed that the recent vote was phrased
as a referendum on dropping BEGIN rather than on dropping SEQUENCE.)
The example is:

(define find-word-break
  (lambda (x k2)
    (do ((x x (rest x)))
        ((or (empty? x) (not (break? (first x))))
         (do ((x x (rest x))
              (word '() (concat word (sequence (first x)))))
             ((or (empty? x) (break? (first x)))
              (k2 word x)))))))

The most straightforward elimination of DO yields:

(define find-word-break
  (lambda (x k2)
    (letrec ((loop1
              (lambda (x)
                (if (or (empty? x) (not (break? (first x))))
                    (letrec ((loop2
                              (lambda (x word)
                                (if (or (empty? x) (break? (first x)))
                                    (k2 word x)
                                    (loop2 (rest x)
                                           (concat word
                                                   (sequence (first x))))))))
                      (loop2 x '()))
                    (loop1 (rest x))))))
      (loop1 x))))

This code is rather forbidding, so I would probably define loop1 and loop2
in a single LETREC.  That works in this case but would not work if a
variable introduced by the outer DO were free within the inner DO.

REC or NAMED-LAMBDA would improve the code a little.

Can Scheme do better?  I could instead use named LET, which would have
the advantage of moving the initialization expression for each loop
variable into proximity with its binding, and would make some of the
LAMBDAs invisible:

(define find-word-break
  (lambda (x k2)
    (let loop1
      ((x x))
      (if (or (empty? x) (not (break? (first x))))
          (let loop2
               ((x x)
                (word '()))
            (if (or (empty? x) (break? (first x)))
                (k2 word x)
                (loop2 (rest x)
                       (concat word (sequence (first x))))))
          (loop1 (rest x))))))

This version still has two disadvantages: (1) I had to think about (or avoid
thinking about!) the names LOOP1 and LOOP2; and (2) it is hard to find the
new bindings for the loop variables.  The way to overcome these disadvantages
is to invent a new special form that moves the expressions that compute the
new values for the loop variables next to their bindings (Dick Gabriel has
already pointed out the value of doing this) and to suppress the names of
the loops; in other words, to invent DO.

Having invented DO, we still have to decide on its syntax.  The syntax of
Scheme's DO is less than optimal for functional programming primarily
because it is designed to support an additional feature: you can insert
non-functional statements to be executed every time around the loop. 
Because Scheme is not a purely functional language, this is a reasonable
feature to support; even I use it on occasion.  Unless we can come up with
a significantly better syntax, we might as well enjoy the advantages of
Lisp tradition and compatibility, while fixing any randomness (as we did
by flushing the implicit binding of RETURN and by using binding instead of
assignment for the loop variables).

I could go on and talk about why functional loops such as the ones you
write using tail recursion or DO are easier to understand than imperative
loops such as the ones you write using DOTIMES, DOLIST, FOR-EACH, or
Andy's straw FOR, VARYING, REPEAT, or WHILE, but I don't think it's
necessary for this audience.

Peace, William Clinger


∂15-Jul-86  2019	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	rrrs-authors   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jul 86  20:18:55 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 JUL 86  23:19:19 EDT
Date: Tue, 15 Jul 86 23:19:07 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  rrrs-authors
To: adams%tekchips.tek.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 15 Jul 86 14:30:07 PDT from Norman Adams <adams%tekchips.tek.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].70741.860715.JAR>

    Date: Tue, 15 Jul 86 14:30:07 PDT
    From: Norman Adams <adams%tekchips.tek.csnet at CSNET-RELAY.ARPA>
    To:   jar at AI.AI.MIT.EDU
    Re:   rrrs-authors
    Message-Id: <8607152130.AA18643@tekchips.TEK>

    Who is on the rrrs-authors list?  I'm just curious ...  -N

Here's the current membership of the list.  It's pretty much the same
people as were on the SCHEME mailing list before it was opened up to the
general public.
- Jonathan

;;; -*- Mode:LISP; -*-
;;; Authors of the Revised↑3 Report on the Algorithmic Language Scheme
;;; To be added or deleted, send mail to SCHEME-REQUEST.

;;; Sorted alphabetically by name of institution, and alphabetically
;;; within institution, except for MIT, which appears first.

(file [LSPMAI;RRRS MAIL])		;Local archive file
(SCHEME-RRRS MIT-OZ)			;Oz people

;;; Also on SCHEME-TEAM
(LS.SRB EE)
(cherian vx)
YEKTA					;Yekta Gursel
JAR					;?
(katz vx)
(alco vx)
(CPH AI)

;;; Others
ALAN
NICK					;Nick Papadakis
RHH					;Bert Halstead
Daniel					;Daniel Weise
RDZ					;Ramin Zabih

;;; Non-MIT
(jleech aids-unix)			;AI & DS / Jay Leech
(william aids-unix)			;	   William Bricken
(andy aids-unix)			;	   Andy Cromarty
(wand%northeastern CSNET-Relay)		;Brandeis / Mitch Wand
(dyb%indiana CSNET-Relay)		;Indiana / Kent Dybvig
(scheme-rrrs%indiana CSNET-Relay)	;Indiana / ...
(linus!ramsdell Mitre-Bedford)		;MITRE / John Ramsdell
("#COMSCH.MSG[SCH,LSP]" SU-AI)		;Stanford / File archive
(ANDY SU-SUSHI)				;	    Andy Freeman
(RPG SU-AI)				;	    Dick Gabriel
KMP					;Symbolics / Kent Pitman
(adams%tekchips%tektronix csnet-relay)	;Tektronix / Norman Adams
(willc%tekchips%tektronix csnet-relay)	;	     Will Clinger
(Scheme-Local%TI-CSL CSNET-Relay)	;TI / ...
GLS					;TMI / Guy Steele
(patel CS.UCLA.EDU)			;UCLA / Dorab Patel
(Hudak Yale)				;Yale / Paul Hudak
(Kelsey Yale)				;	Richard Kelsey
(Kranz Yale)				;	David Kranz
(Philbin-Jim Yale)			;	Jim Philbin

∂15-Jul-86  2105	@MC.LCS.MIT.EDU:jleech@sun6.ads 	the rrrs authors 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jul 86  21:05:30 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 16 Jul 86 00:05:50 EDT
Date: Tue, 15 Jul 86 21:03:00 PDT
From: jleech@sun6.ads (Jay Leech)
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: the rrrs authors
Cc: andy@sun3.ads.ARPA

Myself and a couple of others on the rrrs-authors mailing list were
associated with AI & DS.

We have changed our company name to Advanced Decision Systems, and
our arpanet address should now be ads or ads-unix.

Also, good work!  I am looking forward to the publication of the report.

--  Jay Leech

∂16-Jul-86  1731	@MC.LCS.MIT.EDU:brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA 	Substring & friends 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 16 Jul 86  17:31:44 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 16 Jul 86 16:21:33 EDT
Received: from ti-csl by csnet-relay.csnet id aq04187; 16 Jul 86 15:26 EDT
Received: by tilde id AA18614; Wed, 16 Jul 86 11:01:18 cdt
Date: Wed, 16 Jul 86 11:01:18 cdt
From: Gary Brooks <brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Substring & friends


As stated in the R↑3 Report, the documentation for the <start> and <end>
indices for substring & friends is consfused.  The report states that
<start> and <end> must be valid indices (with <start> <= <end>).  This
is certainly not the case if you are taking the substring of an entire
string, where the index for <end> must be one greater than the largest
valid index.  The previous report, RRRS, included a paragraph explaining
that <start> is inclusive and <end> is exclusive, which is clearer
though still inconsistant with the documentation for substring.  This
inconsistency should be rectified.

On the other hand <start> and <end> could be defined to both be
inclusive.  Now, I realize that there are probably too many instances of
substring & friends running around, and that this would be incompatible
with CL's subsequence, but I for one dislike the notion of (exclusive)
indices that may not be (really) valid indices.  Comments?

			-- brooks


∂16-Jul-86  1732	@MC.LCS.MIT.EDU:Bartley%TI-CSL.CSNET@CSNET-RELAY.ARPA 	Re: number syntax   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 16 Jul 86  17:32:08 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 16 Jul 86 16:22:46 EDT
Received: from ti-csl by csnet-relay.csnet id bn04187; 16 Jul 86 15:40 EDT
Received: by tilde id AA19590; Wed, 16 Jul 86 11:21:40 cdt
Date: Wed 16 Jul 86 10:53:32-CDT
From: David Bartley <Bartley%TI-CSL.CSNET@CSNET-RELAY.ARPA>
Subject: Re: number syntax
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA
Cc: rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA, 
    Bartley%TI-CSL.CSNET@CSNET-RELAY.ARPA
In-Reply-To: <860710120911.5.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>
Message-Id: <12223161873.35.BARTLEY@CSC60>

> Date: Thu, 10 Jul 86 12:09 EDT
> From: Jonathan A Rees <JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA>
>
>    Date: Tue 17 Jun 86 16:00:31-CDT
>    From: David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
>    
>    One irritant in the Report that we have neglected to comment on until
>    now (sorry!) is the syntax of numbers.  We believe that Scheme numbers
>    are essentially equivalent to Common Lisp numbers except for the new
>    notion of exactness.  To the extent that that is so, it seems to be a
>    (shudder!) ``gratuitous difference'' from Common Lisp to have an
>    incompatible syntax.      [...]
>    
>    What we'd like to see is an essential syntax for numbers which is
>    compatible with Common Lisp's.  Additional features, including
>    exactness, would be optional extensions.  Even so, they should not
>    conflict with Common Lisp.  For example, the use of `#s' and the order
>    of <sign> and <prefix> are different in the two languages.     [...]
>    
>    Does anyone agree with us?  Is there time to make such a change before
>    R↑3RS goes to press?
>
>I think everyone agrees with you, and that there is time.  Could you
>please write a concrete proposal, preferably something close to being
>suitable for inclusion in the report.  Also please provide BNF.  Thanks.
>
>Jonathan

Here's a stab at it---we expect and welcome debate over the details.

The major differences between the syntax of numbers in Common Lisp (CL)
and heretofore in Scheme (R↑3RS) are:

(1) CL has the prefix denoting base precede the sign; R↑3RS has the sign
precede the prefix, which includes the base specifier.  I see no reason to
differ from CL.

(2) CL uses several exponent markers to specify levels of precision for
floating point numbers; R↑3RS specifies precision levels (S and L) in the
prefix.  Again, why differ from CL?

(3) CL does not provide for the use of `#' to indicate insignificant
digits.  Making this a non-essential feature in R↑3RS seems reasonable.

(4) CL provides only the #C(real real) notation for complex numbers; R↑3RS
provides infix notations for both polar and rectangular forms.  For
compatibility with CL, R↑3RS should support the #C notation and the infix
forms should be non-essential extensions.

(5) CL integers may optionally terminate in a decimal point; R↑3RS permits
such a number to be treated as floating point and it is debated whether it
is to be considered exact.  This is a serious problem, since many
procedures are defined to accept only integer values.  Is the call
(INTEGER->CHAR 55.) valid?  We propose that this be a non-essential
feature in R↑3RS.

(6) CL integers and ratios are not permitted to have exponent markers.
This feature should be a non-essential extension to Scheme.

(7) CL does not have the concept of exactness.  Most (all?) existing
implementations of Scheme do not support this feature, so it should be
non-essential.

We propose the following syntax for numbers in Scheme.  (Recall that
letter case is insignificant in the grammar and that the rules for <ureal
R>, <prefix R>, etc., should be replicated for R = 2, 8, 10, and 16.)

<number>  -->  <real>  |  #c( <real>  <real> )

<real>  -->  <prefix R> <sign> <ureal R>

<prefix R>  -->  <exactness> <radix R>
  
<exactness>  -->  <empty>  |  #i  |  #e

<radix 2>  -->  #b
<radix 8>  -->  #o
<radix 10>  -->  <empty>  |  #d
<radix 16>  -->  #x

<sign>  -->  <empty>  |  +  |  -

<ureal R>  -->  <integer R>  |  <ratio R>  |  <flonum R>

<integer R>  -->  <digit R>+ #* 

<ratio R>  -->  <digit R>+ #* / <digit R>+ #*

<flonum R>  -->  . <digit R>+ #* <expon>
   |  <digit R>+ . <digit R>* #* <expon>
   |  <digit R>+ #* . #* <expon>

<expon>  -->  <empty>  |  <expon-marker> <sign> <digit>+

<expon-marker>  -->  e  |  f  |  d  |  l  |  s

<digit 2>  -->  0  |  1
<digit 8>  -->  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7
<digit 10>  -->   <digit 8>  |  8  |  9
<digit 16>  -->  <digit 10>  |  a  |  b  |  c  |  d  |  e  |  f


Although we have incorporated <exactness> and the use of `#' above, they
should be stated to be non-essential features of Scheme.  

Nonessential feature: integers with optional decimal points.  

<integer R>  -->  <digit R>+ #* .

Nonessential feature:  integers and ratios with exponents.

<integer R>  -->  <digit R>+ #* <expon>
<ratio R>  -->  <digit R>+ #* <expon> / <digit R>+ #* <expon>

Nonessential number productions representing complex numbers.  We worry
that the forms <real>+<ureal>i and <real>-<ureal>i can be hard to parse.
Perhaps combining the suffix `i' with the infix `+' or `-' would be
palatable to those who want this feature.

<number>  -->  <real> +i <ureal>
   |   <real> -i <ureal>
   |   <real> @ <real>

Regards,
David Bartley
Mark Meyer
-------


∂16-Jul-86  1921	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	July 15 draft sent  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 16 Jul 86  19:20:50 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 16 JUL 86  22:21:14 EDT
Date: Wed, 16 Jul 86 22:21:24 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  July 15 draft sent
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].71397.860716.JAR>


Today I US-mailed another draft to everyone (except GLS, KMP, and people
at MIT, who I'll get to Thursday or Friday, or who can steal them from
my desk).  It is closer to done than the previous one was, but note that
it does NOT reflect any changes in number syntax, LOAD, or names of
call-with-*put-port.  There are a few other things I didn't get to,
which I can't recall right now, but I'm confident that y'all will miss
them and tell me.

I probably won't start another pass over it until a week from tomorrow
(i.e. the 17th), so don't feel guilty if you don't send your remarks to
me before that.  After the 20th is when you can start feeling guilty.

Jonathan

∂17-Jul-86  0851	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	Substring & friends 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jul 86  08:50:17 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUL 86  11:50:47 EDT
Date: Thu, 17 Jul 86 11:50:46 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject:  Substring & friends
To: brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 16 Jul 86 11:01:18 cdt from Gary Brooks <brooks%tilde%TI-CSL.CSNET at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].71736.860717.CPH>

I object to changing the substring indexing scheme.  I chose the
imbalanced inclusive-start/exclusive-end pair because it has a some
nice properties:

1. The pair for the entire string is (0, length(string)), which is
trivially computable.

2. The pair for the empty string is (i, i) for any i <=
length(string).  There is no natural representation for this if both
indices are inclusive.

Don't think that no thought went into this.  I know that on first
encountering this scheme it seems unintuitive, but experience has
shown it to be quite effective, and once learned, easy to remember.

I don't think that the issue of whether or not the end index is a
valid index for the string is very interesting.  In practice, it is
easy to decide whether a given index pair is valid:

0 <= start <= end <= length(string)

∂17-Jul-86  1217	@MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	Re: Substring & friends  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jul 86  12:17:21 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUL 86  15:00:16 EDT
Date: Thu 17 Jul 86 13:09:44-EDT
From: "Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Re: Substring & friends
To: CPH@AI.AI.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <[AI.AI.MIT.EDU].71736.860717.CPH>
Message-ID: <12223437888.36.GJS@OZ.AI.MIT.EDU>

I agree with CPH about his choice of "half-open interval"
representations of strings.  I believe that the choice he made is
pretty optimal because of good nesting and adjacency relations that
are clear if one thinks abstractly.
-------

∂17-Jul-86  1412	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[jtv%fingate.bitnet: Scheme Request]    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jul 86  14:12:40 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 17 JUL 86  17:01:37 EDT
Date: Thu, 17 Jul 86 16:39:45 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  [jtv%fingate.bitnet: Scheme Request]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].71910.860717.JAR>

If someone could translate the following for me, or even identify what
language it's written in, I'd be grateful.

Thanks,
Jonathan


Date: Tue, 15 Jul 86 20:12:38 +0200
From: Jukka Virtanen <jtv%fingate.bitnet at WISCVM.ARPA>
To:   JAR at AI.AI.MIT.EDU
Re:   Scheme Request

        Tjaah, ei meilla KAI ole schemea...
        JOs on, en tieda siita. Juha Heinasella (tre)
        jh@tut on sellainen REF manual, jota ketselin
                                             katselin
        chanlmersiin mentaessa.

        Etkos tilannut scheme listat?

        Vois ton tilata tuolta, jos viitsit.

                                        Juki

∂17-Jul-86  1442	@MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: Substring & friends   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jul 86  14:42:01 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 17 Jul 86 17:39:23 EDT
Received: from tektronix by csnet-relay.csnet id ah14030; 17 Jul 86 16:04 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA02159; Thu, 17 Jul 86 09:42:29 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA10005; Thu, 17 Jul 86 09:44:56 PDT
Date: Thu, 17 Jul 86 09:44:56 PDT
From: Norman Adams <adams%tekchips.tek.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607171644.AA10005@tekchips.TEK>
Subject: Re: Substring & friends
To: Gary Brooks <brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA>
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Gary Brooks <brooks%tilde%TI-CSL.CSNET@csnet-relay.CSNET>, Wed, 16 Jul 86 11:01:18 cdt

    
    On the other hand <start> and <end> could be defined to both be
    inclusive.  Now, I realize that there are probably too many instances of
    substring & friends running around, and that this would be incompatible
    with CL's subsequence, but I for one dislike the notion of (exclusive)
    indices that may not be (really) valid indices.  Comments?

Here's a comment:
    
Currently, if given <start> and <length>, then <end> = <start> + <length>;
whereas with inclusive indices <end> = <start> + <length> - 1.  I prefer
to not have to adjust by 1 in index computations.

-Norman    
    
    
-------

∂18-Jul-86  0012	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: Substring & friends   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 18 Jul 86  00:12:20 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 18 Jul 86 03:13:19 EDT
Received: from tektronix by csnet-relay.csnet id af00418; 18 Jul 86 2:58 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA19060; Thu, 17 Jul 86 15:26:12 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA14145; Thu, 17 Jul 86 15:28:40 PDT
Message-Id: <8607172228.AA14145@tekchips.TEK>
To: brooks%tilde%TI-CSL.CSNET@CSNET-RELAY.ARPA
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: Substring & friends
In-Reply-To: Your message of Wed, 16 Jul 86 11:01:18 cdt.
	     <8607170501.AA05456@tekchips.TEK>
Date: 17 Jul 86 15:28:38 PDT (Thu)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

An advantage of an inclusive <start> and an exclusive <end> is that
(substring s 0 (string-length s)) is the entire string.  If both
were inclusive you'd have to say (substring s 0 (-1+ (string-length s))),
which seems less convenient.  Using (- x 1) instead of (-1+ x) makes it
even harder to read.

An aside on -1+:  As Marianne Moore said, I too dislike it.  I can't
agree that it can't be pronounced, however, since I pronounce (-1+ x)
as "the predecessor of x" or "one less than x".  As Kent Pitman once
pointed out, we can pronounce things however we like.  (Kent wanted
things like EQ? to be pronounced "eek-pee".  I propose that EQ? be
pronounced "eek-hunh?", with a rising inflection.  Just kidding.)
By the way, I don't care whether 1+ and -1+ go or stay; whatever
Jonathan decides is fine with me.

Peace, Will

∂18-Jul-86  1428	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[jtv%fingate.bitnet: Scheme Request]    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 18 Jul 86  14:27:42 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 JUL 86  17:23:00 EDT
Date: Fri, 18 Jul 86 17:22:04 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  [jtv%fingate.bitnet: Scheme Request]
To: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 18 Jul 86 12:01:19 MDT from Fons Botman <mcvax!vu44!fons at seismo.CSS.GOV>
Message-ID: <[AI.AI.MIT.EDU].72425.860718.JAR>


Thanks to everyone who replied to my query about the Finnish mail I
received.

Jonathan

∂21-Jul-86  0448	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	typos    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86  04:38:44 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 21 Jul 86 07:39:53 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from jymme.sun.uucp by linus.MENET (1.1/4.7)
	id AA02999; Mon, 21 Jul 86 07:38:54 EDT
Posted-Date: Mon, 21 Jul 86 07:35:50 edt
Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3)
	id AA12384; Mon, 21 Jul 86 07:35:50 edt
Date: Mon, 21 Jul 86 07:35:50 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8607211135.AA12384@jymme.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: typos

1) [Page 5, col 2, line 8] atsign => at-sign.

2) [Page 5, col 2, line -1] The note seems out of place.
	I suggest deleting it.

3) [Page 5, col 1, line 19] #fand => #f and.

4) [Page 9, col 1, line 21] Odd indent.

5) [Page 10, col 2] Program example not indented correctly.

6) [Page 10, col 2, line -l] comma/at-sign/expression =>
	comma at-sign expression OR comma-at-sign-expression.

7) [Page 12, col 2, line -14] In the phrase "equal? is the coarsest
	or most liberal", liberal has too many meanings; I suggest
	dropping the phrase "or most liberal".

8) [Page 20, col 1, line -20] rouding => rounding.

9) [Page 22, col 2, line -19] uppper => upper.

10) [Page 27, col 2] call-with-xxput-file => call-with-xxput-port.

11) [Page 38, col 1, ref 14] No page numbers.

Wow! What an improvement!  
John

∂21-Jul-86  0737	@MC.LCS.MIT.EDU:Mike←Wilson%CARLETON.BITNET@WISCVM.WISC.EDU 	Performance and Evaluation of Scheme Systems...  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86  07:37:40 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 21 Jul 86 10:35:36 EDT
Received: from wiscvm.wisc.edu by CSNET-RELAY.ARPA id aa26311;
          21 Jul 86 10:33 EDT
Received: from (MIKE←WIL)CARLETON.BITNET by WISCVM.ARPA on 07/21/86 at
  09:26:48 CDT
Received: from Mike←Wilson by CARLETON.BITNET on 21 Jul 86 08:37:12 EDT
Date:     21 Jul 86 08:04:00 EDT
From:       Mike Wilson <Mike←Wilson%CARLETON.BITNET@WISCVM.WISC.EDU>
To:  scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
MMDF-Warning:  Parse error in original version of preceding line at CSNET-RELAY.ARPA
Subject:  Performance and Evaluation of Scheme Systems...


Hi,
    I've just been looking through the book ←Performance and Evaluation
of Lisp Systems← (Richard P. Gabriel, The MIT Press). It's got benchmark
results for several simple programs run on the more common lisp systems.
Has anyone run these tests in CScheme/MacScheme/TIScheme? It would be
interesting to see how we stack up. (I have to admit I am *impressed*
with their times for the IBM 3081 and CRAY-XMP. Oh well...)

                                                    .Mike

∂21-Jul-86  0808	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	schedule  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86  08:08:44 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JUL 86  11:01:29 EDT
Date: Mon, 21 Jul 86 11:00:01 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  schedule
To: ramsdell%linus@MITRE-BEDFORD.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 21 Jul 86 07:47:45 edt from ramsdell%linus at mitre-bedford.ARPA
Message-ID: <[AI.AI.MIT.EDU].73291.860721.JAR>

    Date: Mon, 21 Jul 86 07:47:45 edt
    From: ramsdell%linus at mitre-bedford.ARPA

    I cannot keep up with your schedule.  I received the July 15th draft
    on Friday afternoon, and did not have access to a computer until this
    morning.  There is no way I could have gotten my reply to you by July
    20th.

Jeez, did I tell people to send me comments by the 20th?  I meant to say
that I won't be doing anything until the 24th, so don't kill yourself to
get stuff to me before that.  Within 5 days after the 24th would be very
nice.  The main guideline is this: the report must absolutely be in its
final form before the Lisp conference; in fact, it probably has to be
done by Thursday July 31, so that there's time to make zillions of
copies of it to hand out at the conference.

Jonathan

∂21-Jul-86  0827	@MC.LCS.MIT.EDU:CLOWNEY@BLUE.RUTGERS.EDU 	Logic Continuations (Abstract)   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86  08:20:45 PDT
Received: from BLUE.RUTGERS.EDU by MC.LCS.MIT.EDU 21 Jul 86 11:18:22 EDT
Date: 21 Jul 86  11:11 EDT (Mon)
From: Les <Clowney@BLUE.RUTGERS.EDU>
To:   Chris Haynes <cth%indiana.csnet@CSNET-RELAY.ARPA>
Cc:   scheme@MC.LCS.MIT.EDU, clowney@BLUE.RUTGERS.EDU
Subject: Logic Continuations (Abstract)

Hi Chris, 
    I am generally interested in reports on Scheme that have come
out of Indiana University, and  am currently interested in the report
on continuations as applied to the implementation of logic programming in
Scheme   (Computer Science Department Technical Report No. 183). Where
should I inquire about this report and a general index of Scheme
related reports? 
    

				  les

∂21-Jul-86  1014	@MC.LCS.MIT.EDU:gls@Think.COM 	Scheme's DO construct   
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86  10:14:48 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 21 Jul 86 12:40:47 EDT
Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 12:36:35 edt
Date: Mon, 21 Jul 86 12:37 EDT
From: Guy Steele <gls@Think.COM>
Subject: Scheme's DO construct
To: andy@AIDS-UNIX.ARPA, rrrs-authors%mit-mc@AIDS-UNIX.ARPA
Cc: gls@AQUINAS.ARPA
In-Reply-To: <8607132227.AA23925@Zarathustra.Think.COM>
Message-Id: <860721123716.3.GLS@BOETHIUS.THINK.COM>

Well, you have constructed a great case based on anecdotal evidence,
which is worth having, but I think you have not even addressed my main
point.  The other constructs you mentioned (FOR, REPEAT, and WHILE) have
what I regard as an important flaw:  a reliance on side effects to
accomplish some part of the iterative process.  There is seldom any use
in stepping just one variable in an iteration; you want to step two or
more.  Because FOR, REPEAT, and WHILE (and for that matter DOLIST and
DOTIMES) each step at most one variable, it is necessary to have some
side effect in the body to get anything done.

DO is the only iteration construct we have (other than LOOP) that
encapsulates completely the notion of iteration: the iterative
transformation of a state (normally a compound state, therefore
consisting of two or more quantities) in such a way that an invariant is
maintained at each step, terminated when the state satisfies some
condition. The problem is not that DO has too many features, but that
each of the other iteration constructs is incomplete in a way that must
be patched up using side effects.

I would be quite happy to eliminate one feature of DO: the body!  If the
body is used, then side effects are necessarily involved.  The most
perspicuous uses of DO have no body.

The other problem with DO is that sometimes there is more than one
reason to exit.  I admit that as a flaw; but then again, sometimes there
is reason to return more than one value from a function, and I believe
SCHEME is not yet addressing that either with explicit features.
(Having a body compensates somewhat for that:

	(defun memq (x l)
	  (do ((z l (cdr z)))
	      ((null z) nil)
	    (when (eql x (car z)) (return z))))

This leads me to propose that a good iteration construct would be
like DO but instead of having a body would have more COND clauses.)

--Guy

∂21-Jul-86  1057	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: Performance and Evaluation of Scheme Systems...    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86  10:57:44 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 21 Jul 86 13:55:04 EDT
Received: from ti-csl by csnet-relay.csnet id aa27733; 21 Jul 86 13:37 EDT
Received: by tilde id AA15867; Mon, 21 Jul 86 11:06:17 cdt
Date: Mon 21 Jul 86 10:52:21-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: Performance and Evaluation of Scheme Systems...
To: Mike←Wilson%CARLETON.BITNET%wiscvm.wisc.edu@CSNET-RELAY.ARPA, 
    scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: Message from "Mike Wilson <Mike←Wilson%CARLETON.BITNET%wiscvm.wisc.edu@CSNET-RELAY.ARPA>" of Mon 21 Jul 86 08:04:00-CDT
Message-Id: <12224472379.36.BARTLEY@CSC60>

  >Date:     21 Jul 86 08:04:00 EDT
  >From: Mike Wilson
  >Subject:  Performance and Evaluation of Scheme Systems...
  >
  >    I've just been looking through the book ←Performance and Evaluation
  >of Lisp Systems← (Richard P. Gabriel, The MIT Press). It's got benchmark
  >results for several simple programs run on the more common lisp systems.
  >Has anyone run these tests in CScheme/MacScheme/TIScheme? It would be
  >interesting to see how we stack up. (I have to admit I am *impressed*
  >with their times for the IBM 3081 and CRAY-XMP. Oh well...)

I will be presenting a paper on TI's PC Scheme at the conference on LISP
and Functional Programming in Cambridge the first week of August.  Part of
the paper consists of a brief comparison of PC Scheme and other PC-based
LISP implementations on 7 benchmark programs, some of which come from
Gabriel's test suite.  After the conference, I'll be glad to forward this
information to anyone interested.

Regards,
David Bartley
-------


∂21-Jul-86  1143	@MC.LCS.MIT.EDU:bc@MEDIA-LAB.MIT.EDU 	Bobcat scheme    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86  11:43:10 PDT
Received: from MEDIA-LAB.MIT.EDU by MC.LCS.MIT.EDU 21 Jul 86 14:40:25 EDT
Received: by MEDIA-LAB.MIT.EDU (5.31/4.8)  id AA03625; Mon, 21 Jul 86 14:38:21 EDT
Date: Mon, 21 Jul 86 14:38:21 EDT
From: William H Coderre <bc@MEDIA-LAB.MIT.EDU>
Message-Id: <8607211838.AA03625@MEDIA-LAB.MIT.EDU>
To: scheme@mc.lcs.mit.edu
Subject: Bobcat scheme


I did a rather trivial test between CScheme on Bobcat and MacScheme.
I suspect my data, since it appeared that CScheme was GCing a LOT.


Silly Question:

Does anybody know offhand how to tell unix to give Scheme more memory?
We have the "deluxe" bobcats with graphics stuff andapproximately 8
megs of core, and we'd like to use them!


"Tzima Narki"............................................................bc

∂21-Jul-86  1228	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Logic Continuations (Abstract)
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86  12:27:49 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JUL 86  15:08:31 EDT
Date: Mon, 21 Jul 86 15:06:42 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Logic Continuations (Abstract)
To: Clowney@BLUE.RUTGERS.EDU
cc: cth%indiana.csnet@CSNET-RELAY.ARPA, scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of 21 Jul 86  11:11 EDT (Mon) from Les <Clowney at BLUE.RUTGERS.EDU>
Message-ID: <[AI.AI.MIT.EDU].73379.860721.JAR>

    Date: 21 Jul 86  11:11 EDT (Mon)
    From: Les <Clowney at BLUE.RUTGERS.EDU>

    ... Where should I inquire about this report and a general index of
    Scheme related reports?

I'm trying to maintain a moderately thorough bibliography.  Here's what
it looks like at present (this is the bibliography for the new version
of the scheme report).  If anyone has additions to suggest, please send
me mail.

- Jonathan


\begin{thebibliography}{99}

\bibitem{SICP}
Harold Abelson and Gerald Jay Sussman with Julie Sussman.
{\em Structure and Interpretation of Computer Programs.}
MIT Press, Cambridge, 1985.

\bibitem{Bartley86}
David H.~Bartley and John C.~Jensen.
The implementation of PC Scheme.
To appear in {\em Proceedings of the 1986 ACM Conference on Lisp
  and Functional Programming}.

\bibitem{Scheme81}
John Batali, Edmund Goodhue, Chris Hanson, Howie Shrobe, Richard
  M.~Stallman, and Gerald Jay Sussman.
The Scheme-81 architecture---system and chip.
In {\em Proceedings, Conference on Advanced Research in VLSI},
  pages 69--77.
Paul Penfield, Jr., editor.
Artech House, 610 Washington Street, Dedham MA, 1982.

\bibitem{RRRS}
William Clinger, editor.
The revised revised report on Scheme, or an uncommon Lisp.
MIT Artificial Intelligence Memo 848, August 1985.
Also published as Computer Science Department Technical Report 174,
  Indiana University, June 1985.

\bibitem{Clinger84}
William Clinger.
The Scheme 311 compiler: An exercise in denotational semantics.
In {\em Conference Record of the 1984 ACM Symposium on Lisp and
  Functional Programming}, pages 356--364.

\bibitem{Dybvig86}
R.~Kent Dybvig, Daniel P.~Friedman, and Christopher T.~Haynes.
Expansion-passing style: Beyond conventional macros.
To appear in {\em Proceedings of the 1986 ACM Conference on Lisp and
  Functional Programming.}

\bibitem{Eisenberg85}
Michael A.~Eisenberg.
Bochser: an integrated Scheme programming system.
MIT Laboratory for Computer Science Technical Report 349,
  October 1985.

\bibitem{Feeley86}
Marc Feeley.
Deux approches \`{a} l'implantation du language Scheme.
M.Sc.~thesis, Department of Computer Science and Operations Research,
  University of Montreal, May 1986.

\bibitem{Felleisen86}
Matthias Felleisen, Daniel P.~Friedman, Eugene Kohlbecker, and Bruce Duba.
Reasoning with continuations.
In {\em Proceedings of the Symposium on Logic in Computer Science},
  pages 131--141.
IEEE Computer Society Press, Washigton DC, 1986.

\bibitem{Scheme311}
Carol Fessenden, William Clinger, Daniel P.~Friedman, and Christopher Haynes.
Scheme 311 version 4 reference manual.
Indiana University Computer Science Technical Report 137, February 1983.

\bibitem{Scheme84}
D.~Friedman, C.~Haynes, E.~Kohlbecker, and M.~Wand.
Scheme 84 interim reference manual.
Indiana University Computer Science Technical Report 153, January 1985.

\bibitem{Friedman85}
Daniel P.~Friedman and Christopher T.~Haynes.
Constraining control.
In {\em Proceedings of the Twelfth Annual Symposium on Principles of
  Programming Languages}, pages 245--254.
ACM, January 1985.

\bibitem{Haynes84}
Christopher T.~Haynes, Daniel P.~Friedman, and Mitchell Wand.
Continuations and coroutines.
In {\em Conference Record of the 1984 ACM Symposium on Lisp and
  Functional Programming,} pages 293--298.

\bibitem{Haynes86}
Christopher T.~Haynes.
Logic continuations. 
In {\em Proceedings of the Third International Conference on
  Logic Programming,\/} pages \todo{x--y}.
Springer-Verlag, July 1986.
% and to appear in {\it The Journal of Logic Programming.}

\bibitem{Engines}
Christopher T.~Haynes and Daniel P.~Friedman.
Engines build process abstracions.
In {\em Conference Record of the 1984 ACM Symposium on Lisp and
  Functional Programming,\/} pages 18--24.

\bibitem{Henderson82}
Peter Henderson.  Functional Geometry.
In {\em Conference Record of the 1982 ACM Symposium on Lisp and
  Functional Programming}, pages 179--187.

\bibitem{Kohlbecker86}
Eugene Edmund Kohlbecker~Jr.
{\em Syntactic Extensions in the Programming Language Lisp.}
PhD thesis, Indiana University, August 1986.

\bibitem{Kranz86}
David Kranz, Richard Kelsey, Jonathan Rees, Paul Hudak, James Philbin,
  and Norman Adams.
Orbit: An optimizing compiler for Scheme.
In {\em Proceedings of the SIGPLAN '86 Symposium on Compiler
  Construction}, pages 219--233.
ACM, June 1986.

\bibitem{Landin65}
Peter Landin.
A correspondence between Algol 60 and Church's lambda notation: Part I.
{\em Communications of the ACM} 8(2):89--101, February 1965.

\bibitem{McDermott80}
Drew McDermott.
An efficient environment allocation scheme in an interpreter for a
  lexically-scoped lisp.
In {\em Conference Record of the 1980 Lisp Conference,} pages
  154--162.
The Lisp Conference, P.O.~Box 487, Redwood Estates CA,
  August 1980.

\bibitem{MITScheme}
MIT Department of Electrical Engineering and Computer Science.
Scheme manual, seventh edition.
September 1984.

\bibitem{Muchnick80}
Steven S.~Muchnick and Uwe F.~Pleban.
A semantic comparison of Lisp and Scheme.
In {\em Conference Record of the 1980 Lisp Conference}, pages 56--64.
The Lisp Conference, August 1980.

\bibitem{Naur63}
Peter Naur et al.
Revised report on the algorithmic language Algol 60.
{\em Communications of the ACM} 6(1):1--17, January 1963.

\bibitem{Penfield81}
Paul Penfield, Jr.
Principal values and branch cuts in complex APL.
In {\em APL '81 Conference Proceedings,} pages 248--256.
ACM SIGAPL, San Francisco, September 1981.
Proceedings published as {\em APL Quote Quad} 12(1), ACM, September 1981.

\bibitem{Pitman83}
Kent M.~Pitman.
The revised MacLisp manual (saturday evening edition).
MIT Artificial Intelligence Laboratory Technical Report 295, May 1983.

\bibitem{Pitman80}
Kent M.~Pitman.
Special forms in Lisp.
In {\em Conference Record of the 1980 Lisp Conference}, pages 179--187.
The Lisp Conference, August 1980.

\bibitem{Rees82}
Jonathan A.~Rees and Norman I.~Adams IV.
T: A dialect of Lisp or, lambda: The ultimate software tool.
In {\em Conference Record of the 1982 ACM Symposium on Lisp and
  Functional Programming}, pages 114--122.

\bibitem{Rees84}
Jonathan A.~Rees, Norman I.~Adams IV, and James R.~Meehan.
The T manual, fourth edition.
Yale University Computer Science Department, January 1984.

\bibitem{Reynolds72}
John Reynolds.
Definitional interpreters for higher order programming languages.
In {\em ACM Conference Proceedings}, pages 717--740.
ACM, \todo{month?}~1972.

\bibitem{Rozas84}
Guillermo J.~Rozas.
Liar, an Algol-like compiler for Scheme.
S.~B.~thesis, MIT Department of Electrical Engineering and Computer
  Science, January 1984.

\bibitem{Smith84}
Brian C.~Smith.
Reflection and semantics in a procedural language.
MIT Laboratory for Computer Science Technical Report 272, January 1982.

\bibitem{Stallman80}
Richard M.~Stallman.
Phantom stacks---if you look too hard, they aren't there.
MIT Artificial Intelligence Memo 556, July 1980.

\bibitem{Imperative}
Guy Lewis Steele Jr.~and Gerald Jay Sussman.
Lambda, the ultimate imperative.
MIT Artificial Intelligence Memo 353, March 1976.

\bibitem{Declarative}
Guy Lewis Steele Jr.
Lambda, the ultimate declarative.
MIT Artificial Intelligence Memo 379, November 1976.

\bibitem{Debunking}
Guy Lewis Steele Jr.
Debunking the ``expensive procedure call'' myth, or procedure call
  implementations considered harmful, or lambda, the ultimate GOTO.
In {\em ACM Conference Proceedings}, pages 153--162.
ACM, 1977.

\bibitem{Macaroni}
Guy Lewis Steele Jr.
Macaroni is better than spaghetti.
In {\em Proceedings of the Symposium on Artificial Intelligence and
  Programming Languages}, pages 60--66.
These proceedings were published as a special joint issue of {\em
  SIGPLAN Notices} 12(8) and {\em SIGART Newsletter} 64, August 1977.

\bibitem{Rabbit}
Guy Lewis Steele Jr.
Rabbit: a compiler for Scheme.
MIT Artificial Intelligence Laboratory Technical Report 474, May 1978.

\bibitem{CLoverview}
Guy Lewis Steele Jr.
An overview of Common Lisp.
In {\em Conference Record of the 1982 ACM Symposium on Lisp and
  Functional Programming}, pages 98--107.

\bibitem{CLtL}
Guy Lewis Steele, Jr.
{\em Common Lisp: The Language.}
Digital Press, Burlington MA, 1984.

\bibitem{Scheme78}
Guy Lewis Steele, Jr.~and Gerald Jay Sussman.
The revised report on Scheme, a dialect of Lisp.
MIT Artificial Intelligence Memo 452, January 1978.

\bibitem{TAOTI}
Guy Lewis Steele, Jr.~and Gerald Jay Sussman.
The art of the interpreter, or the modularity complex (parts zero, one,
  and two).
MIT Artificial Intelligence Memo 453, May 1978.

\bibitem{DOALBP}
Guy Lewis Steele, Jr.~and Gerald Jay Sussman.
Design of a Lisp-based processor.
{\em Communications of the ACM} 23(11):628--645, November 1980.

\bibitem{Dream}
Guy Lewis Steele, Jr.~and Gerald Jay Sussman.
The dream of a lifetime: a lazy variable extent mechanism.
In {\em Conference Record of the 1980 Lisp Conference}, pages 163--172.
The Lisp Conference, August 1980.

\bibitem{Scheme75}
Gerald Jay Sussman and Guy Lewis Steele, Jr.
Scheme: an interpreter for extended lambda calculus.
MIT Artificial Intelligence Memo 349, December 1975.

\bibitem{Scheme79}
Gerald Jay Sussman, Jack Holloway, Guy Lewis Steele, Jr., and Alan Bell.
Scheme-79---Lisp on a chip.
{\em IEEE Computer} 14(7):10--21, July 1981.

\bibitem{Stoy77}
Joseph E.~Stoy.
{\em Denotational Semantics: The Scott-Strachey Approach to
  Programming Language Theory.}
MIT Press, Cambridge, 1977.

\bibitem{TI85}
Texas Instruments, Inc.
{\em TI Scheme Language Reference Manual.}
Preliminary version 1.0, November 1985.

\bibitem{Wand78}
Mitchell Wand.
Continuation-based program transformation strategies.
{\em Journal of the ACM} 27(1):174--180, 1978.

\bibitem{Wand80}
Mitchell Wand.
Continuation-based multiprocessing.
In {\em Conference Re\-cord of the 1980 Lisp Conference}, pages 19--28.
The Lisp Conference, August 1980.

\end{thebibliography}

∂21-Jul-86  1325	@MC.LCS.MIT.EDU:gls@Think.COM 	Re: Scheme's DO construct    
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86  13:22:39 PDT
Received: from Godot.Think.COM by MC.LCS.MIT.EDU 21 Jul 86 16:10:31 EDT
Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 15:12:23 edt
Date: Mon, 21 Jul 86 15:13 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: Scheme's DO construct
To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA, rrrs-authors@MC.LCS.MIT.EDU
Cc: gls@AQUINAS
In-Reply-To: <8607152252.AA19578@tekchips.TEK>
Message-Id: <860721151311.0.GLS@BOETHIUS.THINK.COM>

    Date: 15 Jul 86 15:52:52 PDT (Tue)
    From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
    ...
    It seems to me that if we truly want to discourage people from writing
    functional programs, a more effective way to do it would be to change
    Scheme so people can't program in the functional style until they master
    a set of arbitrarily chosen rules for inserting tokens like #' and FUNCALL
    into their programs.

Heh, heh, heh.  Well put, Will!
--Guy

∂21-Jul-86  1357	@MC.LCS.MIT.EDU:YEKTA@AI.AI.MIT.EDU 	Bobcat scheme
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86  13:56:49 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 21 JUL 86  16:53:21 EDT
Date: Mon, 21 Jul 86 16:37:10 EDT
From: Yekta Gursel <YEKTA@AI.AI.MIT.EDU>
Subject:  Bobcat scheme
To: bc@MEDIA-LAB.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 21 Jul 86 14:38:21 EDT from William H Coderre <bc at MEDIA-LAB.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].73422.860721.YEKTA>

Just say "scheme -heap nnn" where "nnn" is the number of kilo-items...
I think the default is 150 and I have run programs with heaps as high as 1200.
(You should have enough swap space for that if you are planning run at that 
heap value).

Best,   Yekta

∂22-Jul-86  0710	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	title wars
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86  07:10:16 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86  10:11:32 EDT
Date: Tue, 22 Jul 86 10:10:29 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  title wars
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].73688.860722.JAR>

The title I chose for the report is under siege.  I guess this means we
need to discuss what it should be.  I think the complaint is that the
superscript will pose typesetting and pronunciation problems for people
who cite the report.  But think of the hundreds of papers with "SL←2(R)"
in their title.  Oh well.

The main thing that's important to me is that it be as similar as
possible to "Revised Report on the Algorithmic Language ALGOL 60".
Beyond that I don't much care.  Here are other possibilities:

- Dan Friedman has suggested "Revised Report on the Algorithmic Language
  SCHEME" but this could be confused much too easily with the "Revised
  Report on Scheme".

- "Another Report on the Algorithmic Language SCHEME"
  (suggestive of YACC.)  I sort of like this one.

- "A Report on the Algorithmic Language SCHEME"

- "Thrice Revised Report on the Algorithmic Language SCHEME"
  This raises fomatting problems, since without the "thrice" it's
  already as wide as it can be without deviating from the Algol report
  layout.

- "Fourth Report on the Algorithmic Language SCHEME"
  This has the advantage that it makes the next version easier to name.

"Report #4 on...", "The Next Report on ..." [imitative of "the
next whole earth catalog"], ...

or we could give the language a new name? no.

∂22-Jul-86  0717	@MC.LCS.MIT.EDU:HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	title wars
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86  07:16:59 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86  10:17:57 EDT
Date: Tue, 22 Jul 1986  10:16 EDT
Message-ID: <HAL.12224716985.BABYL@MIT-OZ>
From: HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To:   Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc:   rrrs-authors@MC.LCS.MIT.EDU
Subject: title wars
In-reply-to: Msg of 22 Jul 1986  10:10-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>


i like the title as it is.  

∂22-Jul-86  1143	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	title wars
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86  11:42:28 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86  14:09:25 EDT
Date: Tue, 22 Jul 86 14:08:30 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject:  title wars
To: JAR@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 22 Jul 86 10:10:29 EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].73801.860722.CPH>

A minor note: I'd prefer that the word "Scheme" not be upper-cased in
the report.  While this is appropriate for an acronym like "ALGOL", it
does not seem to be for "Scheme", which is not an abbreviation for
anything.

I don't really feel strongly about this, I just thought I would point
it out.

BTW, if we *must* change the title, I vote for "Fourth Report...".

∂22-Jul-86  1157	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	title wars
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86  11:57:24 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86  14:58:42 EDT
Date: Tue, 22 Jul 86 14:57:41 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  title wars
To: CPH@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 22 Jul 86 14:08:30 EDT from Chris Hanson <CPH at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].73822.860722.JAR>

    Date: Tue, 22 Jul 86 14:08:30 EDT
    From: Chris Hanson <CPH at AI.AI.MIT.EDU>

    A minor note: I'd prefer that the word "Scheme" not be upper-cased in
    the report.  While this is appropriate for an acronym like "ALGOL", it
    does not seem to be for "Scheme", which is not an abbreviation for
    anything.

Rationale:
I agree that "Scheme" generally shouldn't generally be in upper case,
and I think that it's "Scheme" everywhere else in the report.  However,
I wanted to capitalize it in the title because this helps make it look
like the Algol 60 report.

∂22-Jul-86  1243	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: title wars 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86  12:43:15 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Jul 86 15:44:34 EDT
Received: from ti-csl by csnet-relay.csnet id aa08670; 22 Jul 86 15:37 EDT
Received: by tilde id AA23855; Tue, 22 Jul 86 13:40:20 cdt
Date: Tue 22 Jul 86 13:32:20-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: title wars
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA, 
    rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <[AI.AI.MIT.EDU].73688.860722.JAR>
Message-Id: <12224763647.36.BARTLEY@CSC60>

I have no real problem with leaving the title the way it is.  Another
alternative would be ``1986 Revised Report ...''.

David Bartley
-------


∂22-Jul-86  1252	@MC.LCS.MIT.EDU,@YALE-BULLDOG.ARPA:hudak@YALE.ARPA 	Re: Performance and Evaluation of Scheme Systems...  
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86  12:52:28 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Jul 86 15:46:50 EDT
Received: from yale-bulldog.arpa by CSNET-RELAY.ARPA id aa08705;
          22 Jul 86 15:45 EDT
Received: by Yale-Bulldog.YALE.ARPA; 22 Jul 86 15:13:41 EDT (Tue)
Date: 22 Jul 86 15:13:41 EDT (Tue)
From: Paul Hudak <hudak@YALE.ARPA>
Message-Id: <8607221913.AA06470@Yale-Bulldog.YALE.ARPA>
Subject: Re: Performance and Evaluation of Scheme Systems...
To: Mike Wilson <Mike←Wilson%CARLETON.BITNET@WISCVM.WISC.EDU>
Cc: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
In-Reply-To: Mike Wilson <Mike←Wilson%CARLETON.BITNET@WISCVM.WISC.EDU>, 21 Jul 86 08:04:00 EDT

    I've just been looking through the book ←Performance and Evaluation
    of Lisp Systems← (Richard P. Gabriel, The MIT Press). It's got benchmark
    results for several simple programs run on the more common lisp systems.
    Has anyone run these tests in CScheme/MacScheme/TIScheme? It would be
    interesting to see how we stack up. (I have to admit I am *impressed*
    with their times for the IBM 3081 and CRAY-XMP. Oh well...)
    
The following is an excerpt from the paper:

    Kranz, D., Kelsey, R., Rees, J., Hudak, P., Philbin, J., and Adams, N.
    "ORBIT: an optimizing compiler for Scheme" in Proceedings of ACM
    SIGPLAN '86 Symposium on Compiler Construction, June 1986, pp. 219-233.  
    Also to be published as SIGPLAN Notices Vol. 21, No. 7, July 1986.


                     Orbit vs. Other Lisp Engines:

                        Orbit    3600  Dorado   8600     780
        Program       (SUN III)  +IFU         (Dec CL) (Dec CL)
        -------------------------------------------------------
        Tak             0.25    0.43    0.52    0.45    1.83  
        Takl            1.63    4.95    3.62    2.03    7.34  
        Boyer          15.84    9.40   17.08   12.18   46.79
        Browse         40.28   21.43   52.50   38.69  118.51
        Destructive     1.24    2.18    3.77    2.10    6.38
        Deriv           3.62    3.79   15.70    4.27   13.76
        Dderiv          4.92    3.89   17.70    6.58   19.00
        IDiv2           0.24    1.51    3.43    1.65    5.00
        RDiv2           0.36    2.50    4.08    2.52    9.84
        Triangle       84.36  116.99  252.20   99.73  360.85
        Fprint          2.18    2.60    2.93    1.08    3.94
        Fread           2.62    4.60    1.57    2.34    7.24
        Tprint          1.66    4.89    5.55    0.70    2.85
                                    

                      Orbit vs. PSL vs. Franz:

                             Orbit     PSL     Franz 
               Program       DN300    DN300   Sun II      
               -------------------------------------
               Tak            1.34     1.62     2.37    
               Takl           6.21    12.90    12.82    
               Boyer         63.16    46.92    37.94    
               Destructive    7.91    10.16     9.57    
               Dderiv        28.12    28.95    16.95    
  

                  Orbit vs. Algol-like Languages:

                                           DEC      DEC    
        Program   Orbit  Unix C  DEC C   Pascal  Modula II    
        ---------------------------------------------------
        Perm       1.26    2.6    2.5     2.5     2.0    
        Tower      1.65    2.6    2.7     2.6     1.9    


ORBIT was built (primarily) at Yale, and its availability will be
announced at the upcoming LISP Conference.  If you want more details
about ORBIT or the benchmarks, please read the above cited paper.

    -Paul

∂22-Jul-86  1529	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: title wars 
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86  15:28:33 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Jul 86 18:11:14 EDT
Received: from ti-csl by csnet-relay.csnet id al09489; 22 Jul 86 17:49 EDT
Received: by tilde id AA28902; Tue, 22 Jul 86 15:46:53 cdt
Date: Tue 22 Jul 86 15:37:57-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: title wars
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA, CPH%ai.ai.mit.edu@CSNET-RELAY.ARPA
Cc: rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA, 
    Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <[AI.AI.MIT.EDU].73822.860722.JAR>
Message-Id: <12224786515.36.BARTLEY@CSC60>

    Date: Tue, 22 Jul 86 14:57:41 EDT
    From: Jonathan A Rees <JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA>

        Date: Tue, 22 Jul 86 14:08:30 EDT
        From: Chris Hanson <CPH at AI.AI.MIT.EDU>

        A minor note: I'd prefer that the word "Scheme" not be upper-cased in
        the report.  While this is appropriate for an acronym like "ALGOL", it
        does not seem to be for "Scheme", which is not an abbreviation for
        anything.

    Rationale:
    I agree that "Scheme" generally shouldn't generally be in upper case,
    and I think that it's "Scheme" everywhere else in the report.  However,
    I wanted to capitalize it in the title because this helps make it look
    like the Algol 60 report.

I agree with Chris -- Scheme is a word, not an acronym.  ALGOL is an
acronym and should be written in all caps.  If you want it to look EXACTLY
like the Algol 60 report, name the language ALGOL!

David Bartley
-------


∂22-Jul-86  1755	@MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	title
Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86  17:55:00 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 JUL 86  20:56:23 EDT
Date: Tue 22 Jul 86 20:41:50-EDT
From: "Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: title
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12224830912.34.GJS@OZ.AI.MIT.EDU>

I think that the current title -- R↑4 and all -- is really nice.
-------

∂24-Jul-86  1244	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	call-with-xput-port vs. call-with-xput-file  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86  12:22:56 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 24 JUL 86  15:24:28 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 4905; Thu 24-Jul-86 15:13:30-EDT
Date: Thu, 24 Jul 86 15:12 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: call-with-xput-port vs. call-with-xput-file
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <860724151248.1.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>

    Date: Mon, 14 Jul 86 11:47:21 est
    From: Kent Dybvig <dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA>
    To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
    Subject: call-with-xput-port vs. call-with-xput-file
    
    I favor changing call-with-input-file and call-with-output-file to
    call-with-input-port and call-with-output-port.  However, I have some
    questions related to the change and to ports in general.
    
    1.  I saw lots of confusion over the fact that you open a file (with
    open-input-file and open-output-file) but close a port (with close-
    input-port and close-output-port).  Changing the "call-with" names
    could increase the confusion.  Should we change open-input-file and
    open-output-file to open-input-port and open-output-port?
    
    2.  I have added string ports to Chez Scheme and need to choose names.
    If we have call-with-...-file and open-...-file, I can introduce the
    names call-with-...-string and open-...-string.  On the other hand,
    if we have call-with-...-port and open-...-port, I can introduce the
    names call-with-...-string-port and open-...-string-port.  The names
    are longer but perhaps more descriptive.  How do these names sound?
    The point of this question is that any names we choose should
    generalize to other types of ports.

I see these two points (together with general conservatism) as arguments
AGAINST changing the names.  I am now inclined not to make the change.
    
    5.  Why is call-with-input-file essential and open-input-file not?

This resulted from a general spirit of minimalism at the Brandeis
meeting.  The first is sufficient while the second isn't.  Personally, I
never use the second.

    If call-with-input-file is analogous to
    call-with-current-continuation, why do we not have
    (call-with-new-string <length> <proc>) instead of make-string or
    (call-with-pair <obj1> <obj2> <proc>) instead of cons, etc?  Because
    call-with-current-continuation is special---a function
    make-continuation would be problematic.  In short, while I see the
    merit in with-input-from-file since it closes the file and rebinds a
    standard port, I cannot see the merit in call-with-input-file.

The merit is that it makes certain that the port gets closed.  If we had to
deallocate resources and locks associated with allocated objects like strings,
then I think it would be a good idea to have call-with things for
those too.

Jonathan.

∂25-Jul-86  0022	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	Re: July 15 draft sent   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86  00:22:18 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Jul 86 03:24:07 EDT
Received: from ti-csl by csnet-relay.csnet id ab19183; 25 Jul 86 3:23 EDT
Received: by tilde id AA27498; Fri, 25 Jul 86 00:40:16 cdt
Date: Fri 25 Jul 86 00:35:05-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: Re: July 15 draft sent
To: JAR%ai.ai.mit.edu@CSNET-RELAY.ARPA, 
    rrrs-authors%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
In-Reply-To: <[AI.AI.MIT.EDU].71397.860716.JAR>
Message-Id: <12225408585.58.BARTLEY@CSC60>

    I probably won't start another pass over it until a week from tomorrow
    (i.e. the 17th), so don't feel guilty if you don't send your remarks to
    me before that.  After the 20th is when you can start feeling guilty.

I received my copy of the new revision to the R↑3RS yesterday (July 23)
and enclose my detailed comments below (boy, do I feel guilty!).  I am
quite impressed overall with the current state of the document and want to
commend Jonathan for the success of his efforts!  Nearly all of my
objections to the previous draft have been resolved satisfactorily.  I
will repeat below some that have not, but in general I am content to leave
their resolution in JAR's hands.

[page 1]
  I prefer to change "SCHEME" in the title to "Scheme", since it is not an
acronym.

[page 3]
  I prefer to change "Snobol" to "SNOBOL", since it IS an acronym.

[page 4]
  [line 4, left col] Change "if the feature is not AS essential feature"
to "if the feature is not AN essential feature".
  [line 21, left col] Change "for a call to the procedures" (plural) to
"for a call to the procedure" (singular).
  [line 29, left col] Change "indicates that THE in" to "indicates that, in".
  [first bullet under 2.1] Remove the comma after "Certain identifiers".

[page 5]
  [first paragraph of 2.2] Whitespace may also occur in the space
character (denoted by "#\ ").
  [near the end of 2.3] You say that #T and #F are boolean CONSTANTs and
that #\ introduces a character CONSTANT; shouldn't you say that #(
introduces a vector CONSTANT also?
  [last 2 lines of 2.3] If my proposed number syntax is adopted, #S and #L
will not exist.
  [last 2 lines, right col] Flush the "Note: ..."; I assume it is a note
to yourself (?).

[page 6]
  [section 3.2] Change "#fand" to "#f and".
  [paragraph 6, sec 3.2] Change "Note that THAT the" to "Note that the".

[page 7]
  [last paragraph of sec. 4.1.3] Change "Note also that in many
dialects..." to "{\em Note:} In many dialects...".

[page 8]
  [line 6, right col] Shouldn't the notation (<test> => <recipient>) be
listed as a non-essential syntax in the heading rather than buried as an
implementation note in the body of the text?
  [last paragraph, right col] I was very happy with your use of {\em
Syntax:} and {\em Semantics:} headers but they disappeared from AND
onward.  I guess you ran out of time...

[page 9]
  [first paragragh, sec 4.2.2] There is a mysterious whitespace at the
beginning of the fourth line of the paragragh.
  [description of LET*] Shouldn't you replicate the description of
<bindings> and <body>?  You do for LETREC.
  Try to avoid the "widow" line for the heading of LET*.
  [last line, right col] Here, and elsewhere, you have incomplete sentences
in which the subject is missing.  This doesn't particularly offend me, and
it seems to read well, so I see no reason to correct it right away...

[page 10]
  [end of 4.2.4] The indenting for the "(LET LOOP ((NUMBERS ..." example
has gone awry.

[page 12]
  [end of 6.1] I'd like to see the example (EQ? NIL 'NIL) ==> #F added.
This reinforces the wording in the last paragraph of the left column,
which might be missed by someone looking only at the definition of NIL.

[page 14]
  [last paragraph of the description of EQ?] Omit the words "instead of as
a subroutine call".  It seems to imply that anything other than a pointer
comparison must be performed out of line, or that a pointer comparison
would necessarily be performed in line.

[page 17]
  [lines 10, 11 of left col] Omit the sentence: "It is questionable
whether these features [slashification and uninterned symbols] are worth
their complexity, so they are not standard in Scheme."  This editorial
comment is unnecessary and invites the response: "Then why is
SYMBOL->STRING worth while?"

[page 22]
  [sec 6.6] Clarify the sentence: "This rule resolves the ambiguous case
... the space character AS AS the ...".

[page 30]
  [sec 7.1.2, syntax of numbers] I mailed out a proposal for a syntax of
numbers compatible with Common Lisp last week but haven't received any
feedback.  Did it fail to make it to the mailing list or is it that
non-controversial?

[page 36]
  Try to avoid the "widow" line for the subtitle "EXAMPLE".

[Index]
  Add #T and #F, and possibly #!TRUE and #!FALSE (page 12), to the index.

Regards,
David Bartley
-------


∂25-Jul-86  1026	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: number syntax    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86  10:17:32 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Jul 86 13:19:12 EDT
Received: from tektronix by csnet-relay.csnet id ab23107; 25 Jul 86 12:51 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA08596; Wed, 23 Jul 86 11:48:49 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA29292; Wed, 23 Jul 86 11:51:24 PDT
Message-Id: <8607231851.AA29292@tekchips.TEK>
To: Bartley%TI-CSL.CSNET@CSNET-RELAY.ARPA
Cc: JAR@AI.AI.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: number syntax
In-Reply-To: Your message of Wed 16 Jul 86 10:53:32-CDT.
	     <12223161873.35.BARTLEY@CSC60>
Date: 23 Jul 86 11:51:22 PDT (Wed)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

After studying the recent proposal by David Bartley and Mark Meyer, I'm
afraid I have to object to using it in the report.  I probably just don't
understand it, and I might change my mind if they'll explain it to me
better.  I don't have much problem with the syntactic changes they propose.
The main problem I have with their proposal is that it addresses the syntax,
which I don't much care about, but doesn't address the semantic properties
like exactness and integer-ness.  I have repeated most of their proposal
(indented two spaces) in order to point out the parts I object to.

  (4) CL provides only the #C(real real) notation for complex numbers; R↑3RS
  provides infix notations for both polar and rectangular forms.  For
  compatibility with CL, R↑3RS should support the #C notation and the infix
  forms should be non-essential extensions.

Shouldn't the #C syntax be inessential also, since integer-only
implementations are allowed?  Shouldn't all productions with decimal
points or slashes be inessential as well?

  (5) CL integers may optionally terminate in a decimal point; R↑3RS permits
  such a number to be treated as floating point and it is debated whether it
  is to be considered exact.  This is a serious problem, since many
  procedures are defined to accept only integer values.  Is the call
  (INTEGER->CHAR 55.) valid?  We propose that this be a non-essential
  feature in R↑3RS.

It seems to me that most procedures that are currently defined to accept
only integer values should have been defined to accept only exact integer
values.  Our concept of an integer needs to be tightened up.  I propose
that INTEGER? be defined to be compatible with

    (define integer?
      (lambda (x)
        (and (real? x) (= x (truncate x)))))

With a definition such as this it seems likely that 55. will be an integer.
The real question is whether it is exact.  I haven't been able to answer
that question on the basis of the proposal.

  We propose the following syntax for numbers in Scheme.  (Recall that
  letter case is insignificant in the grammar and that the rules for <ureal
  R>, <prefix R>, etc., should be replicated for R = 2, 8, 10, and 16.)

  <number>  -->  <real>  |  #c( <real>  <real> )

  <real>  -->  <prefix R> <sign> <ureal R>

  <prefix R>  -->  <exactness> <radix R>
  
  <exactness>  -->  <empty>  |  #i  |  #e

  <radix 2>  -->  #b
  <radix 8>  -->  #o
  <radix 10>  -->  <empty>  |  #d
  <radix 16>  -->  #x

  <sign>  -->  <empty>  |  +  |  -

  <ureal R>  -->  <integer R>  |  <ratio R>  |  <flonum R>

  <integer R>  -->  <digit R>+ #* 

  <ratio R>  -->  <digit R>+ #* / <digit R>+ #*

  <flonum R>  -->  . <digit R>+ #* <expon>
     |  <digit R>+ . <digit R>* #* <expon>
     |  <digit R>+ #* . #* <expon>

  <expon>  -->  <empty>  |  <expon-marker> <sign> <digit>+

I believe the <digit>+ in the above production was intended to be
<digit 10>+.

  <expon-marker>  -->  e  |  f  |  d  |  l  |  s

  <digit 2>  -->  0  |  1
  <digit 8>  -->  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7
  <digit 10>  -->   <digit 8>  |  8  |  9
  <digit 16>  -->   <digit 10>  |  a  |  b  |  c  |  d  |  e  |  f


  Although we have incorporated <exactness> and the use of `#' above, they
  should be stated to be non-essential features of Scheme.  

  Nonessential feature: integers with optional decimal points.  

  <integer R>  -->  <digit R>+ #* .

This production is redundant, since all the strings it generates are
generated by the third production for <flonum R>.  I judge by this
and other redundancies that the name of the non-terminal is intended
to carry semantic freight, but I can't tell what semantics is intended.
This is my fundamental objection to the proposal:  it is a syntax
without a semantics.

  Nonessential feature:  integers and ratios with exponents.

  <integer R>  -->  <digit R>+ #* <expon>
  <ratio R>  -->  <digit R>+ #* <expon> / <digit R>+ #* <expon>

Similarly the production above for <integer R> is redundant, since it is
exactly the same as the first production for <flonum R>.

  Nonessential number productions representing complex numbers.  We worry
  that the forms <real>+<ureal>i and <real>-<ureal>i can be hard to parse.
  Perhaps combining the suffix `i' with the infix `+' or `-' would be
  palatable to those who want this feature.

  <number>  -->  <real> +i <ureal>
     |   <real> -i <ureal>
     |   <real> @ <real>

I'm not sure that this syntax is any easier to parse than the old syntax,
but it isn't any worse.

  Regards,
  David Bartley
  Mark Meyer
  -------

Peace, Will Clinger

∂25-Jul-86  1127	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	(eqv? #e1 #i1) 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86  11:25:02 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 JUL 86  14:26:41 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 5047; Fri 25-Jul-86 14:24:41-EDT
Date: Fri, 25 Jul 86 14:25 EDT
From: Jonathan A Rees <JAR@MIT-AI.ARPA>
Subject: (eqv? #e1 #i1)
To: rrrs-authors@MIT-MC.ARPA
Message-ID: <860725142516.4.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>

    Date: 22 Jul 86 11:31:02 PDT (Tue)
    From: willc%tekchips.tek.csnet at CSNET-RELAY.ARPA

    Technical question relating to exactness:  Are 1 and 1.0 operationally
    equivalent?  (That is, if we wind up adopting the proposal that 1 be
    read as an exact integer while 1.0 is read as an inexact integer, then
    (EQV? 1 1.0) must be false.  This is incompatible with the RRRS, which
    says that EQV? returns true when its arguments are numbers that are
    equal according to the = procedure.  This incompatibility is not listed
    in the notes on page 35.  I wonder if the incompatibility was recognized
    and intended.)

I assumed that this detail was an unintentional omission from RRRS.
Clearly #e1 and #i1 are distinguishable.  I'll list this in the notes
section.

- Jonathan

∂25-Jul-86  1346	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	July 15th draft    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86  13:46:05 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 25 Jul 86 15:47:55 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from clyde.sun.uucp by linus.MENET (1.1/4.7)
	id AA09549; Fri, 25 Jul 86 15:45:49 EDT
Posted-Date: Fri, 25 Jul 86 15:42:54 edt
Received: by clyde.sun.uucp (2.0/SMI-3.0DEV3)
	id AA01028; Fri, 25 Jul 86 15:42:54 edt
Date: Fri, 25 Jul 86 15:42:54 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8607251942.AA01028@clyde.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: July 15th draft

On title wars, I am reminded of Norman's comments:

  Scheme is fun and happy, and a bit quirky -- or are CDR and CAR and so many
  relatives the ideal names for those procedures?  Scheme is as serious as
  LAMBDA, but as casual as CAR.  Alas, what has become of dear PROGN?  The
  names are arbitrary and incidental; CAR and CDR remind us.  Scheme is as
  much an approach as a detailed concrete specification.  But to be taken
  seriously, for Scheme to be widely used, we must have the details and
  concretions; they are essential but unimportant.

While publishers will most likely want to put out contracts on the
typing fingers of those who perpetrated the weird title, I think we
should have a little fun and keep the superscript in the title.
However, I do like the idea of NOT using all caps for Scheme in the
title. 

David Bartley suggests changing "Snobol" into "SNOBOL" because it is
an acronym.  If we do that, shouldn't we change "Algol" into "ALGOL"
and "Lisp" into "LISP"?

1) [Page 2, col 1, line 3] I am worried about the phrase "with
absolutely no restrictions on how they are composed".  Certainly, the
expressions "1" and "2" should not be composed as "(1 2)".  Doesn't
Scheme show that a small number of rules for forming expression
combined with a simple, uniform method of combining the expressions,
suffices to form a practical and efficient programming language?

2) [Page 5, col 1, paragraph 2] Too many parentheses.  Only the first
pair are needed.  Use commas for the others.  

3) [Page 3, col 1, paragraph 3] Too many parentheses.

4) [Page 6, col 1, paragraph 1] From my reading of the paragraph, I
conclude that Common Lisp has no dynamic variables.  After all, it
says that "To each place where a variable is bound in a program there
corresponds a region of the program text within which the binding is
effective."  The lack of dynamic variables distinguishes Scheme from
Common Lisp and makes the above statement true.

5) [Page 10, col 1, line -16] Odd space between the words "region" and
"of". 

6) [Page 10, col 2, line 1] Change to "general looping construct than
do, and may also be used to express recursive procedures."

7) [Page 14, col 1, line 22] The previous page states that there is
only one empty string.  Therefore, (eqv? "" "") => #t, which implies
that (eq? "" "") => #t.  If I am wrong, what does the statement about
the existence of one empty string mean?

8) [Page 27, col 2] I will simply say that, in my opinion,
call-with-xxput-port gives a user a better idea of what is going on,
as compared to call-with-xxput-file.  In the interest of harmony, I
will rest my case unless I hear support from others.

John

∂26-Jul-86  2137	@MC.LCS.MIT.EDU:cth%iuvax.indiana.edu@CSNET-RELAY.ARPA 	corrections and suggestions  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86  21:37:14 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 Jul 86 00:39:23 EDT
Received: from indiana by csnet-relay.csnet id ac11703; 27 Jul 86 0:39 EDT
Date: Thu, 24 Jul 86 17:21:19 est
From: Chris Haynes <cth%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: corrections and suggestions

I prefer "A Report ..." or "Fourth Report ...".  In any case, remove
the bit about the ↑3 not being a footnote.  No one is apt to mistake 
the title's ↑3, for it is big and bold.  It is *references* to the title
in other publications where the ↑3 will cause confusion, and the note
in the report won't do any good then.  

I prefer "C.T. Haynes" in the author list, and "Christopher Haynes" in the 
Background (p. 2).

In the summary, delete "and very few different ways to form expressions",
which is unnecessary and questionable.

p. 2: make those features --> make additional features
      first real programming language --> 
          first widely used programming language
      sub-dialects --> dialects
      , while many others remain to be adopted. --> .

With Kent Dybvig, I would prefer that : not be an extended
alphabetic character, but be reserved for special uses.

2.3. unspecified future uses --> possible extensions in
discussion of [ ] and { }.

3.1. may name --> names
Question: Why say "A variable that does so is said to be bound to the
location."  Is it possible to have variables that aren't bound to
locations?  If so, how?  The reader should not be kept in the dark.

Delete "Note: internale definitions not mentioned here."

3.2. #fand --> #f and

4.1 and 4.2.  The "Syntax:" and "Semantics:" paragraph flags are
nice, but are not used after "case" (p. 8).  I suggest flushing them.
Better to be consistent, and they aren't necessary for understanding.

4.2.4. Some implementations of Scheme permit a ... --> This ...

       pretty printing of (let loop ...) is messed up.

5.1. consists a sequence --> consists of a sequence

6.2. if applying a mutation procedure to one causes the other to
     change as well.
        -->
     if they have operationally equivalent values in corresponding
     positions and applying a mutation procedure to one causes the 
     other to change as well.

     For example, two pairs are equivalent if a set-car! operation on
     one changes the car field of the other.
        -->
     For example, two pairs are not equivalent if a set-car!
     operation on one does not change the car field of the other.

     Questions: is "side-effect" defined anywhere?  (A referee
     recently critisized me for not defining it.)

6.4. (in the sense of eqv?) --> (in the sense of eq?)
        [[the reader should be encouraged to think eq? on symbols]]

6.9, p. 27.  is an ordinary Scheme procedure --> is a Scheme procedure

     The classic use --> A common use

     flush "when programmers need to do something fancy,"

I don't like the last sentence of 6.9.  Opinions also differ on the
merits of SEQUENCE, but we didn't apologize for it or give SEQUENCE
less than optional status by not listing it under BEGIN as an
(optional) form.  List CALL/CC as a procedure under
CALL-WITH-CURRENT-CONTINUATION and replace the last sentence with a
statement that CALL/CC is equivalent.  Several of us feel rather
strongly about this.

6.10.1.  I also prefer CALL-WITH-*-PORT and OPEN-*-PORT.

Replace the last sentence of the WITH-*-*-FILE paragraph with
"Furthermore, when these procedures return, they close the
default port and restore the previous default.  If an escape procedure
is used to escape from the continuation of these procedures, their
behavior is implementation dependent."
[[Rational: the existing "in constrast" statement is incorrect.
Where is the contrast?  And more important, some systems will
automatically change the default port if the continuation is escaped,
but we probably don't want to even mention, let alone require, such
behavior.]]

6.10.4. Delete the LOAD rational.  The LOAD description expressly
says that expressions and definitions are read, so any uses of LOAD to
load such things as compiled files are implementation extensions anyway.

Delete the TRANSCRIPT-* Note.  We haven't provided elementary tips
to implementers anywhere else.

BIBLIOGRAPHY: add the following

Daniel P. Friedman, Christopher T. Haynes, and Eugene Kohlbecker,
Programming with continuations. {\it In Programming Transformation and
Programming Environments,\/} P. Pepper (Ed.), pages 263--274,
Springer-Verlag, 1984.


The Report reads quite well now, and has come a long way in the last
few months.  Thanks for all your efforts, Jonathan.

Chris Haynes


∂28-Jul-86  0810	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Fault logic in eq? comment   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86  08:10:43 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 28 Jul 86 11:10:39 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from jymme.sun.uucp by linus.MENET (1.1/4.7)
	id AA27194; Mon, 28 Jul 86 11:08:54 EDT
Posted-Date: Mon, 28 Jul 86 11:06:06 edt
Received: by jymme.sun.uucp (2.0/SMI-3.0DEV3)
	id AA02270; Mon, 28 Jul 86 11:06:06 edt
Date: Mon, 28 Jul 86 11:06:06 edt
From: ramsdell%linus@mitre-bedford.ARPA
Message-Id: <8607281506.AA02270@jymme.sun.uucp>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Fault logic in eq? comment

Opps! I used faulty logic in:

  7) [Page 14, col 1, line 22] The previous page states that there is
  only one empty string.  Therefore, (eqv? "" "") => #t, which implies
  that (eq? "" "") => #t.  If I am wrong, what does the statement about
  the existence of one empty string mean?

Please ignore it!

[Page 27, col 2] I think there is support for changing
call-with-xxput-file to call-with-xxput-port.  I am not convinced that
open-xxput-port is any better than open-xxput-file, the latter
expresses what the function does just as well as the former does.

[Page 2] While the introduction implies Scheme has no dynamic
variables and no separate name spaces for global values and functions,
maybe that difference with existing Lisps should be made more
explicit.  Thus, after "... in the same way as an operand position."
one might add "In contrast, many other dialects of Lisp associate two
values with some variables, and the bindings in effect at run time may
depend on the run time history of a program --- not simply the static
program structure."

John



∂28-Jul-86  1616	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: corrections and suggestions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86  16:05:28 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Jul 86 18:47:41 EDT
Received: from tektronix by csnet-relay.csnet id ai01735; 28 Jul 86 18:43 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA07871; Mon, 28 Jul 86 09:51:20 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA02924; Mon, 28 Jul 86 09:54:03 PDT
Message-Id: <8607281654.AA02924@tekchips.TEK>
To: cth%indiana.csnet@CSNET-RELAY.ARPA
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: corrections and suggestions
In-Reply-To: Your message of Thu, 24 Jul 86 17:21:19 est.
	     <8607270553.AA19279@tekchips.TEK>
Date: 28 Jul 86 09:54:02 PDT (Mon)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA


    3.1. may name --> names
    Question: Why say "A variable that does so is said to be bound to the
    location."  Is it possible to have variables that aren't bound to
    locations?  If so, how?  The reader should not be kept in the dark.

There exist identifiers that are not syntactic keywords.  According to the
first sentence of 3.1, any such identifier may be used as a variable.  The
catch comes in an implementation with unbound variables, such as PC Scheme,
where just using an identifier as a variable does not make it name a
location; that must be done with a binding construct.  I see your point,
but I suspect that many readers would prefer to remain in the dark about
this sort of thing until the next paragraph.

A related issue is that (top level) DEFINE is missing from the list of
binding constructs in the next paragraph.

    I don't like the last sentence of 6.9.  Opinions also differ on the
    merits of SEQUENCE, but we didn't apologize for it or give SEQUENCE
    less than optional status by not listing it under BEGIN as an
    (optional) form.  List CALL/CC as a procedure under
    CALL-WITH-CURRENT-CONTINUATION and replace the last sentence with a
    statement that CALL/CC is equivalent.  Several of us feel rather
    strongly about this.

Whoa!  Two wrongs don't make a right.  Let's try to get rid of SEQUENCE
instead.  Several of us feel rather strongly that CALL/CC ought to call
the C compiler.  Seriously, to add alternative names for procedures now
would be inconsistent with our success in getting rid of =? et cetera.

    Replace the last sentence of the WITH-*-*-FILE paragraph with
    "Furthermore, when these procedures return, they close the
    default port and restore the previous default.  If an escape procedure
    is used to escape from the continuation of these procedures, their
    behavior is implementation dependent."
    [[Rational: the existing "in constrast" statement is incorrect.
    Where is the contrast?  And more important, some systems will
    automatically change the default port if the continuation is escaped,
    but we probably don't want to even mention, let alone require, such
    behavior.]]

The contrast is that WITH-*-*-FILE will close the default port whenever
you throw out of it without having done a CALL-WITH-CURRENT-CONTINUATION,
even if you stored the value of (CURRENT-*-PORT) in a global variable
before you did the throw.  CALL-WITH-*-FILE would never do a thing like
that.  To me, this is a striking contrast.

Peace, Will

∂29-Jul-86  1331	@MC.LCS.MIT.EDU:dyb@iuvax.indiana.edu 	critical problems with call---file, with---file    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86  13:01:13 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 Jul 86 15:58:06 EDT
Received: from indiana by csnet-relay.csnet id ab02982; 29 Jul 86 9:57 EDT
Date: Tue, 29 Jul 86 02:10:41 est
From: "R. Kent Dybvig" <dyb@iuvax.indiana.edu>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: critical problems with call---file, with---file
Cc: bartley%ti-csl.CSNET@CSNET-RELAY.ARPA, jar%mit-mc.CSNET@CSNET-RELAY.ARPA, 
    willc%tekchips@iuvax.indiana.edu

Regarding these quotes from the latest revision:

 (under call-with-input-file, call-with-output-file)
    If the procedure returns, then the port is closed
    automatically and the value yielded by the procedure is
    returned.  If the procedure does not return, then Scheme
    will not close the port unless it can prove that the
    port will never again be used for a read or write operation.

 (under with-input-from-file, with-output-to-file)
    Furthermore, in contrast to call-with-input-file and
    call-with-output-file, these procedures will arrange to
    close the default port and restore the previous default
    whenever the system can prove that the call to the
    thunk will never return.


I have two problems with the wording of these two quotes.  One of
these probems can be ignored, and we'll only have an ill-specified
and confusing set of procedures.  The other cannot be ignored.


First, the one that cannot be ignored:  From the wording of the
second quote, it is technically possible (and perhaps required!)
for a Scheme system to close a port out from under a procedure in
a way we do not intend.  For example, if I write:
  (with-input-from-file "foo.in"
     (letrec ((loop (lambda ()
                       (write-char (read-char))
                       (loop))))
        loop)),
it is clear that a clever Scheme system can prove that the thunk
will never return; however, it would be entirely inappropriate to
close the new default port and restore the old.


The second problem takes a little more explaining:  I think that
most users will be very confused and rather upset that
call-with-input-file does not close the port automatically in the
case of a non-local exit, either programmed or through some sort
of error.  Also, in the case of with---file, it is not clear
whether an implementation is required to close the port as soon as
it can prove that the call will never return, or sometime thereafter.
Furthermore, it is not clear how sophisticated the system must be
in proving this fact.

In the most recent version of Chez Scheme, ports are closed by the
storage manager once it determines there is no possibility of
reference.  This will not necessarily occur as soon as the port
becomes inaccessible, but it is guaranteed that the system will not
run out of ports if there are any open, inaccessible ports around.
In addition, all ports are closed on exit from the system.  This
is a much more general and reasonable solution to the problem of
closing ports than forcing the programmer to use confusing,
ill-defined procedures that don't necessarily help in the case
of non-local exits or errors.

It is fine to say that the port is closed when the procedure or thunk
returns, but we should flush the descriptions of what happens when
the procedure or thunk does not return, perhaps mentioning that, in
order to avoid running out of file-system resources, implementations
usually close ports it can prove are inaccessible.  This would be
in the spirit of the earlier statement about not (usually!) running
out of storage (section 1.1, paragraph 4), and would also reinforce
the first-class status of ports.

Kent

p.s. We don't have much time, so please respond quickly.


∂29-Jul-86  1423	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	schedule  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86  13:52:36 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 JUL 86  16:52:21 EDT
Date: Tue, 29 Jul 86 16:35:08 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  schedule
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].77171.860729.JAR>

A version of the report is now at the printer.  There will be a copy
in every Lisp conference registration packet.

As for SIGPLAN, I seem to have screwed up pretty badly; I thought that
having it done by early August would be good, since it would then get
into the October issue.  However, I just found out from Wexelblat that
the October issue is proceedings for some conference.  (This decision
was made rather late; the previous time I spoke with him, the October
issue was still open.)  Therefore the earliest it can be out is the
November issue, and our new deadline is September 12.

For the Lisp conference version, I didn't do anything about number
syntax, since there seemed to be a bit of controversy remaining; also I
did nothing about the question of number input exactness, and didn't
rename the call-with-transput-pile procedures.  What got printed was
rather close to the July 15 draft, incorporating, of course, most of the
corrections people sent me.  Maybe we can fix these and other problems
by September, though.

Thanks to everyone who read the July 15 and other drafts so carefully.
If you won't be at the Lisp conference, let me know and I'll mail you a
copy of the latest thing.

Jonathan

∂29-Jul-86  1814	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Re: critical problems with call---file, with---file
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86  18:13:50 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 29 Jul 86 20:14:24 EDT
Received: from tektronix by csnet-relay.csnet id am07403; 29 Jul 86 18:48 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA06974; Tue, 29 Jul 86 15:23:57 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA22297; Tue, 29 Jul 86 15:26:48 PDT
Message-Id: <8607292226.AA22297@tekchips.TEK>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: critical problems with call---file, with---file
Date: 29 Jul 86 15:26:46 PDT (Tue)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

                               ...For example, if I write:
      (with-input-from-file "foo.in"
         (letrec ((loop (lambda ()
                           (write-char (read-char))
                           (loop))))
            loop)),
    it is clear that a clever Scheme system can prove that the thunk
    will never return; however, it would be entirely inappropriate to
    close the new default port and restore the old.

Nice example.  Should we say instead that "If the procedure does not
return, Scheme will not close the port unless it can prove that the
continuation with which the procedure was called has become
inaccessible"?

I can't get very excited if ports aren't closed the instant they become
inaccessible, because I suspect that pairs aren't added to the free list
the instant they become inaccessible either.  I can't see how it affects
my life.

As I read the report, implementations are not required to try to close
ports in the exceptional cases.  Likewise, though implementations are
"permitted to reclaim the storage occupied by an object if they can
prove that the object cannot possibly matter to any future computation",
I don't see where implementations are actually required to reclaim
storage.  I think it's clear that implementations are encouraged to do
both, and it's great that Chez Scheme is setting such a good example for
us to follow.

It would be reasonable to say that "in order to avoid running out of
file-system resources, implementations usually close ports it can
prove are inaccessible" if it were true.  Is it?

Implementation note:  In a very large multiprocessing implementation of
Scheme it might be more practical to remove limits on file-system
resources than to determine whether ports are accessible.

----------------------------------------------------------------
The section that describes differences between RRRS and R3RS should
note that (DEFINE (FOO ...) ...) is now equivalent to
(DEFINE FOO (LAMBDA (...) ...)) instead of to
(DEFINE FOO (REC FOO (LAMBDA (...) ...))).

Peace, Will

∂31-Jul-86  0732	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	rrrs authors meeting, lunch Tuesday
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86  07:32:27 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 JUL 86  09:54:34 EDT
Date: Thu, 31 Jul 86 09:52:31 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  rrrs authors meeting, lunch Tuesday
To: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 30 Jul 86 17:01:20 PDT from Norman Adams <adams%tekchips.tek.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].77967.860731.JAR>

    Date: Wed, 30 Jul 86 17:01:20 PDT
    From: Norman Adams <adams%tekchips.tek.csnet at CSNET-RELAY.ARPA>
    To:   jar at AI.AI.MIT.EDU

    It occurred to me that the bulk of the RRRS authoripods will be at
    the lisp conference and that a meeting might bring quick resolution
    to issues outstanding for the SIGPLAN edition of the R3RS.  A
    meeting might be fun even if there is nothing to resolve...  What
    say you?  Perhaps there is not enough time to get a note out on
    RRRS; maybe we could post something at the registration desk.

Good idea.  What with Monday night being the banquet, and Tuesday night
being various Eulisp and Common Lisp meetings, I think lunchtime would
be best.  Therefore I propose lunch on Tuesday, promptly following
cessation of the morning sessions.

If there's a major problem with this time then we can change it to lunch
Wednesday or some other time.  I'll post something near the registration
desk in any case.  See y'all there.

Jonathan

∂31-Jul-86  1111	@MC.LCS.MIT.EDU:fateman@DALI.BERKELEY.EDU 	Re:  Performance and Evaluation of Scheme Systems...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86  11:11:19 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 31 Jul 86 14:04:02 EDT
Received: from dali.berkeley.edu by CSNET-RELAY.ARPA id aa27481;
          31 Jul 86 12:45 EDT
Received: by dali.Berkeley.EDU (5.53/1.14)
	id AA17087; Thu, 31 Jul 86 08:49:56 PDT
Date: Thu, 31 Jul 86 08:49:56 PDT
From: Richard Fateman <fateman@DALI.BERKELEY.EDU>
Message-Id: <8607311549.AA17087@dali.Berkeley.EDU>
To: Mike←Wilson%CARLETON.BITNET@WISCVM.WISC.EDU, 
    scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Subject: Re:  Performance and Evaluation of Scheme Systems...

since the programs used for timing were allowed to be different from
the ones in RPG's book, (e.g.  declarations)  and at least some of the
programs are unrunnnable as given, the benchmark timings are somewhat
less useful than you might think.  If YOU run them benchmarks on various
machines/lisps, you may get much different numbers.  

∂04-Aug-86  0107	@MC.LCS.MIT.EDU:facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Aug 86  01:07:30 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  4 Aug 86 03:41:37 EDT
Received: from waterloo by csnet-relay.csnet id ac03100; 4 Aug 86 3:32 EDT
Received: from cantuar.uucp by watmath; Mon, 4 Aug 86 03:02:42 edt
Date: Mon, 4 Aug 86 18:50:44+1200
From: Facilities Committee <facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA>
To: SCHEME <@CSNET-RELAY.ARPA,@watmath.waterloo.edu:SCHEME@MC.LCS.MIT.EDU>

Date: Thu, 31 Jul 86 10:44:24+1200
From: wolfgang@cantuar.Waterloo.edu (W. Kreutzer)
To: SCHEME@MIT-MC.csnet@watmath.Waterloo.edu
Subject: Chez Scheme

We would be interested in more info on Chez Scheme. Who can we contact ?
Since we are using an experimental connection from New Zealand, please 
reply through either: wolfgang%cantuar@waterloo.csnet  OR 
 ...watmath!cantuar!wolfgang. Thanks.  w.kreutzer Univ. of Canterbury, NZ



∂04-Aug-86  0158	@MC.LCS.MIT.EDU:facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Aug 86  01:58:15 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  4 Aug 86 03:41:30 EDT
Received: from waterloo by csnet-relay.csnet id ab03100; 4 Aug 86 3:31 EDT
Received: from cantuar.uucp by watmath; Mon, 4 Aug 86 03:02:07 edt
Date: Mon, 4 Aug 86 18:50:44+1200
From: Facilities Committee <facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA>
To: SCHEME <@CSNET-RELAY.ARPA,@watmath.waterloo.edu:SCHEME@MC.LCS.MIT.EDU>

Date: Thu, 31 Jul 86 10:44:24+1200
From: wolfgang@cantuar.Waterloo.edu (W. Kreutzer)
To: SCHEME@MIT-MC.csnet@watmath.Waterloo.edu
Subject: Chez Scheme

We would be interested in more info on Chez Scheme. Who can we contact ?
Since we are using an experimental connection from New Zealand, please 
reply through either: wolfgang%cantuar@waterloo.csnet  OR 
 ...watmath!cantuar!wolfgang. Thanks.  w.kreutzer Univ. of Canterbury, NZ



∂06-Aug-86  0150	@MC.LCS.MIT.EDU:facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 86  01:50:07 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  6 Aug 86 04:49:37 EDT
Received: from waterloo by csnet-relay.csnet id aa13776; 6 Aug 86 4:32 EDT
Received: from cantuar.uucp by watmath; Wed, 6 Aug 86 03:54:00 edt
Date: Wed, 6 Aug 86 19:30:29 nzt
From: Facilities Committee <facility%cantuar.waterloo.edu@CSNET-RELAY.ARPA>
To: scheme <@CSNET-RELAY.ARPA,@watmath.waterloo.edu:scheme@MC.LCS.MIT.EDU>

Date: Thu, 31 Jul 86 10:44:24+1200
From: wolfgang@cantuar.Waterloo.edu (W. Kreutzer)
To: SCHEME@MIT-MC.csnet@watmath.Waterloo.edu
Subject: Chez Scheme

We would be interested in more info on Chez Scheme. Who can we contact ?
Since we are using an experimental connection from New Zealand, please 
reply through either: wolfgang%cantuar@waterloo.csnet  OR 
 ...watmath!cantuar!wolfgang. Thanks.  w.kreutzer Univ. of Canterbury, NZ



∂07-Aug-86  0136	@MC.LCS.MIT.EDU:JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU 	non-list arguments 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Aug 86  01:35:52 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 AUG 86  04:34:17 EDT
Date: Thu,  7 Aug 86 04:30:58 EDT
From: Jonathan A Rees <JAR%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject:  non-list arguments
To: rhh@MC.LCS.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU, t-discussion@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 1 Apr 86 15:26 EST from Robert Halstead <rhh at MIT-VAX.ARPA>
Message-ID: <[MX.LCS.MIT.EDU].939050.860807.JAR>

    Date: Tue, 1 Apr 86 15:26 EST
    From: Robert Halstead <rhh at MIT-VAX.ARPA>

    To summarize, I think it should be permissible for

    	(eq? ((lambda x x) l) l)

    to return true, but it should not be a requirement.  Furthermore, it
    should be permissible for an implementation to report an error if l in
    the above expression is not a true list, but an implementation should
    not be required to do so.  Of course, it would still be true that

    	((lambda x x) 3 4 5)

    would return a freshly consed list, just like (list 3 4 5).  An
    interesting question:  do people expect (apply list l) to return a
    top-level copy of l?					-b.

Permitting sharing between the argument passed to apply and the
rest-argument leads to all kinds of obscure bugs - especially if sharing
isn't guaranteed.  In fact I have written and used interpreters which
shared the list, and I regretted it every time.  Efficiency shouldn't
guide the design on this issue.  A compiler could easily detect the
situation you described (a rest-variable referenced only as the last
argument to APPLY) and generate code which doesn't cons.

Jonathan

∂07-Aug-86  0301	@MC.LCS.MIT.EDU:Pase@DOCKMASTER.ARPA 	Scheme for the Atari ST    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Aug 86  03:01:42 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 AUG 86  06:00:12 EDT
Received: from DOCKMASTER.ARPA by MC.LCS.MIT.EDU  4 Apr 86 16:23:17 EST
Date:  Fri, 4 Apr 86 00:59 EST
From:  Bill Pase <Pase@DOCKMASTER.ARPA>
Subject:  Scheme for the Atari ST
To:  scheme@MIT-MC.ARPA
Message-ID:  <860404055925.041933@DOCKMASTER.ARPA>

Does anyone know if Scheme is available for the Atari ST?  I know there
are versions for the IBMPC and the Macintosh.  It wouIt would seem
especially with the later that an Atari version should be easy.  Does
anyone have any plans to develop it?  /bill

∂07-Aug-86  0730	@MC.LCS.MIT.EDU:jcm@ORNL-MSR.ARPA 	Re: Scheme for the Atari ST   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Aug 86  07:30:35 PDT
Received: from ORNL-MSR.ARPA by MC.LCS.MIT.EDU  7 Aug 86 10:29:37 EDT
Received: by ORNL-MSR.ARPA (4.12/4.9)
	id AA05596; Thu, 7 Aug 86 10:24:46 edt
Date: Thu, 7 Aug 86 10:24:46 edt
From: jcm@ORNL-MSR.ARPA (James A. Mullens)
Message-Id: <8608071424.AA05596@ORNL-MSR.ARPA>
To: scheme@mit-mc
Subject: Re: Scheme for the Atari ST



from Bill Pase (Pase@DOCKMASTER.ARPA)
>Does anyone know if Scheme is available for the Atari ST?

I recently asked similar questions here, which lead me to some
history which may be helpful.  I'll summarize what I've learned from
people on this list and the archives.

The archives for this group contain some references to "Scheme 312".
This is the ancestor of MacScheme.  MacScheme is actually being
developed on the Stride (Sage) computer under the CP/M-68K operating
system, so the author has an decent version working in that
environment.  (The author is not interested in distributing or
supporting that version, however).

I have heard that the Atari ST runs GEM on top of CP/M-68K (or a
minor mutation of CP/M).  If this is true, it might be easy to port
to the Atari -- maybe easier than porting to the Mac.  Perhaps the
author is not aware of this possibility and would be interested in
doing the port?

The author's name is Will Clinger, and he used to be at
    willc%indiana.csnet@csnet-relay.arpa which is Indiana U on CSnet

from my ARPAnet BSD Unix machine.  I'm not sure if he monitors this
list...  The MacScheme distributor address:
   Semantic Microsystems
   4470 SW Hall Street, Suite 340
   Beaverton OR  97005
   (503) 643-4539

Dave Alcocer (alco@mit-vax) was working with CScheme.  He says this
public domain version is portable.  Dave said he was interested
having it on his Amiga, but it might need to be trimmed down from
approximately 2 megabytes by removing some trimmings.

Wouldn't it be amazing to see a group of Mac, Amiga, and ST owners
cooperating on a public domain Scheme!

The GNU project has started distributing CScheme.  I'm not sure why
they have decided to do so.

Good Luck -
- jim mullens / oak ridge national lab

∂08-Aug-86  0819	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 86  08:19:18 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 AUG 86  11:18:43 EDT
Date: Fri,  8 Aug 86 11:16:47 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
To: wolfgang%cantuar%waterloo.csnet@CSNET-RELAY.ARPA
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 6 Aug 86 19:30:29 nzt from Facilities Committee <facility%cantuar.waterloo.edu at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].80950.860808.JAR>

    Date: Wed, 6 Aug 86 19:30:29 nzt
    From: Facilities Committee <facility%cantuar.waterloo.edu at CSNET-RELAY.ARPA>
    To:   scheme < at CSNET-RELAY.ARPA, at watmath.waterloo.edu:scheme@MC.LCS.MIT.EDU>

    Date: Thu, 31 Jul 86 10:44:24+1200
    From: wolfgang@cantuar.Waterloo.edu (W. Kreutzer)
    To: SCHEME@MIT-MC.csnet@watmath.Waterloo.edu
    Subject: Chez Scheme

    We would be interested in more info on Chez Scheme. Who can we contact ?
    Since we are using an experimental connection from New Zealand, please 
    reply through either: wolfgang%cantuar@waterloo.csnet  OR 
     ...watmath!cantuar!wolfgang. Thanks.  w.kreutzer Univ. of Canterbury, NZ

Implementation:     Chez Scheme
Authored by:        Kent Dybvig
Supported by:       limited support by the author
Hardware:           VAX
Operating Systems:  4.2 BSD UNIX (or ULTRIX)
Implementation:     incrementally compiled to native code
Intended Use:       education and research
Price:		    Per site: $400 for US colleges and universities,
		    and $1000 for companies who will use the
		    system for research and education only.

Chez Scheme was first released earlier this year and is now being used
at about 10 universities for classes and research.  Chez Scheme supports
almost all of the required and optional features of the RRRS.  The next
major release (in spring or summer 1986) will support 100% of the
required features of the standard.

In addition to the features of the RRRS, Chez Scheme provides error and
exception handling, engines, programmable cafes and waiters (fancy
read-eval-print loops), tracing and statistics- gathering facilities,
and fast-loading compiled files.  Chez Scheme provides floating point
numbers, arbitrary-precision ratios, and arbitrary-precision integers,
but no imaginary numbers at this time.

Chez Scheme's biggest claim to fame is the speed and size of its
implementation.  It outperforms Franz Lisp and DEC Common Lisp on most
programs, but the initial core image is less than 500K bytes, about half
of which is read-only and sharable.

For the license forms and ordering information, contact:

   Kent Dybvig
   Cadence Research Systems
   620 Park Ridge Road
   Bloomington, IN  47401
   812/333-9269

You can also reach me during the day at 812/335-8653, or by electronic
mail to dyb.indiana@csnet-relay.

∂08-Aug-86  1230	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[Masinter.pa: synonym streams..]   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 86  12:29:48 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 AUG 86  11:20:48 EDT
Date: Fri,  8 Aug 86 11:19:12 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  [Masinter.pa: synonym streams..]
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].80953.860808.JAR>

How about a similar rule for Scheme?  With the obvious extension to ports created by
with-input-file, etc.
	- Jonathan.

Date: 5 Aug 86 11:09 PDT
From: Masinter.pa at Xerox.COM
To:   common-lisp at su-ai.ARPA
Re:   synonym streams..
In-reply-to: David Bein <pyramid!bein@hplabs.HP.COM>'s message of 5 Aug
 86 09:05 PDT
Message-ID: <860805-111034-2460@Xerox>

I propose the following rule: "It is an error to attempt to close a
stream that wasn't created with open."

With this rule, it would follow that, since synonym, broadcast and
two-way streams are not created with open,  it is an error to perform
"close" on them.

∂08-Aug-86  1712	@MC.LCS.MIT.EDU:Bartley%ti-csl.csnet@CSNET-RELAY.ARPA 	"Final" comments on RRRRS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 86  17:12:33 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  8 Aug 86 20:16:20 EDT
Received: from ti-csl by csnet-relay.csnet id ai03255; 8 Aug 86 18:15 EDT
Received: by tilde id AA15700; Fri, 8 Aug 86 15:48:46 cdt
Date: Fri 8 Aug 86 15:20:50-CDT
From: David Bartley <Bartley%ti-csl.csnet@CSNET-RELAY.ARPA>
Subject: "Final" comments on RRRRS
To: RRRS-Authors%mit-mc@CSNET-RELAY.ARPA
Cc: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
Message-Id: <12229239846.30.BARTLEY@CSC60>

Before I go on vacation, I'd like to submit a (very) few comments on the
current draft report for consideration for the SIGPLAN revision.

-- I'm very pleased with its appearance and happy that it was distributed
to all of the attendees at the LISP conference.  Thanks again to Jonathon.

-- Kent Dybvig has asked that the colon (:) be removed from the set of
extended alphabetic characters (section 2.3).  I agree completely.  My
joint implementations of Scheme and Common LISP need a reasonable syntax
for Scheme procedures to refer to symbols in various Common LISP packages.
Using Common LISP's syntax seems best.

-- Reference [2] to our conference paper on PC Scheme may now be updated
to refer to pages 86-93 of the proceedings.  The same goes for reference
[6] by Dybvig, Friedman, and Haynes.  Reference [51] to the TI Scheme
manual should be changed from ``preliminary version 1.0, November 1985''
to ``Original issue: December 1985''.

-- I hope that Jonathon will be able to incorporate our proposed number
syntax.

Regards,
David Bartley
-------


∂11-Aug-86  0855	@MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:SRAUCH@UNBMVS1.BITNET 	Instructor's manual for S&ICP by Julie Sussman  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Aug 86  08:55:45 PDT
Received: from MIT-MULTICS.ARPA by MC.LCS.MIT.EDU 11 Aug 86 11:50:28 EDT
Received: from UNBMVS1(MAILER) by MITVMA (Mailer X1.23) id 8365;
          Mon, 11 Aug 86 11:48:58 EDT
Date:        11 Aug 86 10:34:28 ADT
From:         <SRAUCH@UNBMVS1>
To:          scheme@mc.lcs.mit.edu
Subject:     Instructor's manual for S&ICP by Julie Sussman
Message-ID:  <ID45752.D860811.T103428.SRAUCH@UNBMVS1>

- Can anyone tell me whether the "Instructors Manual" for
Structure and Interpretation of Computer Programs by Abelson and
Sussman, written by Julie Sussman is available? If so, how can it be
obtained? McGraw-Hill Canada doesn't seem to have heard of it. Any help
with this would be greatly appreciated.

                 Steve R.
SRAUCH@UNBMVS1.BITNET


∂13-Aug-86  0238	NET-ORIGIN@MC.LCS.MIT.EDU 	Re: define   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Aug 86  02:38:35 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 13 AUG 86  05:32:10 EDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 17 Apr 86 00:50:16 EST
Received: from tektronix by csnet-relay.csnet id ak29970; 17 Apr 86 0:43 EST
Received: by tektronix (5.31/5.14)
	id AA20915; Wed, 16 Apr 86 13:06:21 PST
Received: by tekchips (5.31/5.14)
	id AA02612; Wed, 16 Apr 86 13:06:41 PST
Date: Wed, 16 Apr 86 13:06:41 PST
From: Will Clinger <willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
Message-Id: <8604162106.AA02612@tekchips>
To: SCHEME%MIT-MC%tektronix.csnet@CSNET-RELAY.ARPA
Subject: Re: define
Cc:   

Roger Kirchner writes:

>Kent M Pitman said that there are other possible interpretations of
>(DEFINE (((...) ...) ...) ...)
>besides as an extended template for procedure definition.
>What would be the objections to making this interpretation standard?

Your interpretation is already standard, though not essential; see
page 18 of MIT AI Memo 848.  Though other interpretations are possible,
they would be in conflict with the Revised Revised Report.

The extended syntax began in MIT Scheme and was picked up by MacScheme
and PC Scheme.  T2 doesn't support it.  I don't know about Chez Scheme
et cetera.

Peace, Will

∂14-Aug-86  1728	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Minutes from lunch 5 August 1986    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86  17:28:20 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Aug 86 20:27:24 EDT
Received: from tektronix by csnet-relay.csnet id aa00212; 14 Aug 86 18:43 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA09292; Thu, 14 Aug 86 12:57:59 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA24878; Thu, 14 Aug 86 13:00:49 PDT
Message-Id: <8608142000.AA24878@tekchips.TEK>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Minutes from lunch 5 August 1986
In-Reply-To: Your message of Tue, 29 Jul 86 16:35:08 EDT.
	     <[AI.AI.MIT.EDU].77171.860729.JAR>
Date: 14 Aug 86 13:00:46 PDT (Thu)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

Minutes from lunch on Tuesday, 5 August 1986

Attendance was not taken.

Jonathan Rees was congratulated on getting a draft of the R↑3RS done in
time for the conference.

After lunch we drew up a list of language areas that need work.  In a few
of these areas we have proposals on the table, while a few others are
difficult research areas:

ERRORS & INTERRUPTS.  What are the errors?  How are they signalled?
How are the handlers found, what do they do, how are they defined?
What about I/O devices?

OPAQUE TYPES.  Three new procedures have been proposed for creating
and manipulating objects that answer false to all the standard type
predicates and cannot be taken apart by any of the standard deconstructors.
One procedure -- call it INJECT -- takes two objects and returns a new
opaque object consisting of the first object tagged by the second.
The second procedure -- call it IN? -- takes two objects and returns
true if the first object was created by calling INJECT with the second
object as the tag, and returns false otherwise.  The third procedure --
call it PROJECT -- takes an opaque object and a tag object and returns
the object encapsulated by the opaque object provided the tags match.
Axiomatically:

    (IN? (INJECT x y) y)      ==> #t
    (IN? (INJECT x y) z)      ==> #f    provided (NOT (EQV? y z))
    (PROJECT (INJECT x y) y)  ==> x

MACROS.  Difficult research area.  We're awaiting Eugene Kohlbecker's
thesis.

DYNAMIC-WIND.  DYNAMIC-WIND seems like a good generalization of
UNWIND-PROTECT, but what about multiprocessing?  Should an UNWIND/WIND
occur on every process switch?  What about I/O?  The formal semantics
of DYNAMIC-WIND is very operational, which I take to be a danger signal.

INPUT/OUTPUT.  What should happen to the current ports on a process
switch?  What should happen if the debugger gains control?  What should
happen if a transcript is desired?

SYNCHRONIZATION.  Ought to have some means of synchronization before we
have multiple processes.

MODULE SYSTEM.  First class environments do most things right, but they
render inter-module constant folding (e.g. procedure integration)
impractical.  I think we're finally agreed that the issue of first class
environments can usefully be separated from the question of incremental
definitions as used in S&ICP, and I don't think anyone is enthusiastic
about Common Lisp style packages as a mechanism for modularity.

SEMANTICS OF QUASIQUOTE, QUOTE.  In question are things like (EQ? '(A) '(A))
and (SET-CAR! `(A B ,C) 3) and (SET-CAR! `(A B ,@C) 3).  Does it matter to
the last two examples whether the compiler can determine that C is a
constant?

DECLARATIONS.  It is important to be able to say things like "CAR is a
constant", "N is an exact nonnegative integer less than 2↑20", "This
procedure should be optimized for speed at the expense of space but
not safety".  Which declarations signal an error if violated, and which
are merely hints for better performance?  What is the syntax and scope
of a declaration?

SYNTAX CHECKER & CANONIZER.  How about a program that converts programs
written in full Scheme into a canonical form that uses only the primitive
expressions, checking syntax as it does so?  Tektronix has volunteered to
supply such a program.

VERIFICATION SUITE.  How about a verification suite to locate bugs?
Someone volunteered to coordinate this, but I'm not sure I remember
who it was, so please re-volunteer.

BENCHMARK SUITE.  This wasn't discussed at lunch, but I talked to
several people who would like to have a benchmark suite that generates
more meaningful and more easily interpreted numbers than do the Gabriel
benchmarks.  For example, the Gabriel benchmarks test property lists
and fluid variables but don't do anything with lexical closures.

MULTIPLE RETURN VALUES.  Two new procedures have been proposed for
multiple return values.  One procedure -- call it RETURN -- takes
arbitrarily many values and returns them.  The other procedure --
call it RECEIVE-VALUES -- takes a thunk and a procedure, and calls
the procedure on the (possibly multiple) values returned by the
thunk.  The semantics that appears in R↑3RS was designed to work
with multiple return values, but we might want to change the help
function "single" so that extra return values (e.g. in the test
position of a conditional) are ignored as in Common Lisp.  (With
the current version of "single", extra return values would be an
error.)  Since RETURN doesn't do anything remotely like what RETURN
does in Common Lisp (and is identical to CL's VALUES function),
we might want to discuss the name.  We might also want to discuss
the argument order for RECEIVE-VALUES.

OPTIONALS.  Should there be a special syntax for optional arguments
so we don't have to use a rest argument and destructure it ourselves?
What should the syntax be?

∂14-Aug-86  1855	@MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU 	Re: Minutes from lunch 5 August 1986   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86  18:55:39 PDT
Received: from Sushi.Stanford.EDU by MC.LCS.MIT.EDU 14 Aug 86 21:34:10 EDT
Date: Thu 14 Aug 86 18:30:00-PDT
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: Re: Minutes from lunch 5 August 1986
To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8608142000.AA24878@tekchips.TEK>
Message-ID: <12230868993.15.ANDY@Sushi.Stanford.EDU>

I'd be happier if the Scheme community said nothing about
multitasking, multiprocessing, or anything related to parallelism.
This isn't intended to discourage informal communication, but any hint
of agreement/standardization is premature.

Why is this coming up now anyway?  We don't understand macros, errors,
interrupts, declarations, etc.

I'd rather have (hash) tables than project/inject/in?.

-andy
-------

∂14-Aug-86  2053	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	substring indexes    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86  20:51:53 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 14 Aug 86 23:00:21 EDT
Received: from tektronix by csnet-relay.csnet id ab00212; 14 Aug 86 18:46 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA09635; Thu, 14 Aug 86 13:06:50 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA25920; Thu, 14 Aug 86 13:09:35 PDT
Message-Id: <8608142009.AA25920@tekchips.TEK>
To: kend%tekla.tek.csnet@CSNET-RELAY.ARPA
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: substring indexes
In-Reply-To: Your message of 13 Aug 86 08:37:36 PDT (Wed).
	     <8608131537.AA25142@tekla.TEK>
Date: 14 Aug 86 13:09:33 PDT (Thu)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

The following comes from Ken Dickey (kend@tekla).  I favor changing
the description of substring-fill! to say START *to* END.  Peace, Will.

----------------------------------------------------------------
Will,

I have not yet read the full report, but R-cubed is a significant
improvement over R-squared.  I did find section 6.7 on strings,
however, to be somewhat confusing.  Some functions (eg substring) use
START *to* END, while others (eg substring-fill!) use START *through*
END.

I think it would be better to either maintain 

	0 <= START <= END < (string-length <string>)

XOR use 1 based indexing.  

In both cases, I favor using start through end (both inclusive).  The
latter is probably more in keeping with the spirit of Scheme in that
one based indexing seems more natural to naive programmers**.

Pax,
-Ken

-------------
** (based on my experience teaching Pascal and C).

∂14-Aug-86  2233	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	r-cubed syntax (nits)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86  22:33:27 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Aug 86 00:58:33 EDT
Received: from tektronix by csnet-relay.csnet id ag02938; 15 Aug 86 0:47 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA10107; Thu, 14 Aug 86 13:55:24 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA01706; Thu, 14 Aug 86 13:58:17 PDT
Message-Id: <8608142058.AA01706@tekchips.TEK>
To: JAR@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: r-cubed syntax (nits)
In-Reply-To: Your message of Tue, 29 Jul 86 16:35:08 EDT.
	     <[AI.AI.MIT.EDU].77171.860729.JAR>
Date: 14 Aug 86 13:58:14 PDT (Thu)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

The following comes from Ken Dickey (kend%tekla@tek.csnet; my previous
note said kend@tekla, but I don't think that works unless you're at
Tektronix.).

----------------------------------------------------------------
Will,


parsimony: 7.1.1: <suffix>: 
		<digit> <digit>*
can be written 	<digit>+


ambiguity?: 7.1.3: <case clause> and <cond clause> both allow
	(else <sequence>)  
to be any clause, rather than the last clause.  Is this intentional?


Again, let me say that this is the best language spec that I have read
in some time (I still have 7.2 to slog through).

-Ken


∂15-Aug-86  0902	@MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA 	Re:  Minutes from lunch 5 August 1986  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Aug 86  09:02:09 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Aug 86 11:50:44 EDT
Received: from indiana by csnet-relay.csnet id aa07414; 15 Aug 86 11:12 EDT
Date: Fri, 15 Aug 86 00:51:46 est
From: "R. Kent Dybvig" <dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: Re:  Minutes from lunch 5 August 1986

It was I who volunteered to coordinate the verification suite.

Kent


∂15-Aug-86  1106	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	r-cubed syntax (nits)    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Aug 86  11:06:33 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 AUG 86  13:46:41 EDT
Date: Fri, 15 Aug 86 13:47:03 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  r-cubed syntax (nits)
To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 14 Aug 86 13:58:14 PDT (Thu) from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA
Message-ID: <[AI.AI.MIT.EDU].84074.860815.JAR>

    Date: 14 Aug 86 13:58:14 PDT (Thu)
    From: willc%tekchips.tek.csnet at CSNET-RELAY.ARPA

    parsimony: 7.1.1: <suffix>: 
    		<digit> <digit>*
    can be written 	<digit>+

OK, will fix.

    ambiguity?: 7.1.3: <case clause> and <cond clause> both allow
    	(else <sequence>)  
    to be any clause, rather than the last clause.  Is this intentional?

I had it this way for a while, and decided that it was unnecessary
clutter in the syntax.  You need to give two rules instead of one for
the syntax of cond (and case), and it looks really bad.  But the fact
that someone noticed & cared is probably enough to indicate that I
should change it back to the more verbose, pedantic form.


∂15-Aug-86  1112	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	scheme report tar file   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Aug 86  11:10:55 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 AUG 86  13:57:24 EDT
Date: Fri, 15 Aug 86 13:57:51 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  scheme report tar file
To: goodhart@NOSC-COD.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 6 Aug 86 10:26:55 PDT from Curtis L. Goodhart <goodhart%cod at nosc.ARPA>
Message-ID: <[AI.AI.MIT.EDU].84083.860815.JAR>


OK, there's now a tar file for the draft of the scheme report on host
MIT-PREP in the file "/u/jar/r3rs.tar".  Use user scheme password scheme
if user & password are required.  The tar file is about .25 Mbytes.
Sorry this took so long.

Jonathan

∂15-Aug-86  1223	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	"Final" comments on RRRRS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Aug 86  12:23:14 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 AUG 86  15:22:24 EDT
Date: Fri, 15 Aug 86 15:22:44 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  "Final" comments on RRRRS
To: Bartley%ti-csl.csnet@CSNET-RELAY.ARPA
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 8 Aug 86 15:20:50-CDT from David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].84135.860815.JAR>

    Date: Fri 8 Aug 86 15:20:50-CDT
    From: David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>

    -- Kent Dybvig has asked that the colon (:) be removed from the set of
    extended alphabetic characters (section 2.3).  I agree completely.  My
    joint implementations of Scheme and Common LISP need a reasonable syntax
    for Scheme procedures to refer to symbols in various Common LISP packages.
    Using Common LISP's syntax seems best.

I have no strong objection to this.  It's conceivable that it could be
construed by the uninitiated as an endorsement of read-time packaging,
but I think we should be able to guard against that.

I would like to hear from people who object to the this (Hanson?)
before making the change.  If the screams aren't too loud I'll do it.

    -- I hope that Jonathan will be able to incorporate our proposed number
    syntax.

Sorry, I just won't have time to work on it, and I don't think there's
time for proper review.  If you could prepare the changes in fine detail
(maybe edit the TeX sources yourself), this might be feasible, but a
last-minute change of this magnitude is bound to have problems with it.
Probably it would be best to just include a statement to the effect that
this change is being considered for a future revision of the report.

Jonathan

∂15-Aug-86  2150	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	"Final" comments on RRRRS
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Aug 86  21:50:17 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 16 AUG 86  00:49:37 EDT
Date: Sat, 16 Aug 86 00:50:15 EDT
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject:  "Final" comments on RRRRS
To: JAR@AI.AI.MIT.EDU
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 15 Aug 86 15:22:44 EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].84332.860816.CPH>

    Date: Fri, 15 Aug 86 15:22:44 EDT
    From: Jonathan A Rees <JAR at AI.AI.MIT.EDU>
    To:   Bartley%ti-csl.csnet at CSNET-RELAY.ARPA

        Date: Fri 8 Aug 86 15:20:50-CDT
        From: David Bartley <Bartley%ti-csl.csnet at CSNET-RELAY.ARPA>

        -- Kent Dybvig has asked that the colon (:) be removed from
        the set of extended alphabetic characters (section 2.3).  I
        agree completely.  My joint implementations of Scheme and
        Common LISP need a reasonable syntax for Scheme procedures to
        refer to symbols in various Common LISP packages.  Using
        Common LISP's syntax seems best.

    I have no strong objection to this.  It's conceivable that it could be
    construed by the uninitiated as an endorsement of read-time packaging,
    but I think we should be able to guard against that.

    I would like to hear from people who object to the this (Hanson?)
    before making the change.  If the screams aren't too loud I'll do it.

I guess that I should respond to this.  I really, truly abhor the
read-time package system and would strenuously object to any such
thing being introduced into Scheme.  I have gone out of my way (a
little) to use colons in my code just to parody the package system
and, unfortunately, that would make my code non-portable given this
decision.

Understand, I have no really serious objections to this suggestion,
except that if anyone tries to define what `:' means when it appears
in an identifier, I promise to raise heck.  But I don't mind agreeing
to disagree about it.

And, of course, anyone who implements this change will not be able to
port my code without significant rewriting.  Sigh.  I guess that would
be your loss, not mine.

(Seriously, though, what would the symbol
`rtl:interpreter-call:lookup' mean in a system with such a syntax?)

∂18-Aug-86  0051	@MC.LCS.MIT.EDU:ram@YALE.ARPA 	Re:  The generality of define
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 86  00:51:37 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 AUG 86  03:41:46 EDT
Received: from yale-bulldog by MC.LCS.MIT.EDU 23 Apr 86 21:58:42 EST
Received: by Yale-Bulldog.YALE.ARPA; 23 Apr 86 21:46:26 EST (Wed)
Date: 23 Apr 86 21:46:26 EST (Wed)
From: Ashwin Ram <ram@YALE.ARPA>
Message-Id: <8604240246.AA12180@Yale-Bulldog.YALE.ARPA>
Subject: Re:  The generality of define
To: andy@aids-unix.ARPA (Andy Cromarty)
Cc: SCHEME@MC.LCS.MIT.EDU
In-Reply-To: andy@aids-unix.ARPA (Andy Cromarty), Wed, 23 Apr 86 19:09:53 EST

     Date: 21 Apr 1986 09:43-PST
     From: andy@aids-unix (Andy Cromarty)
     Subject: Re:  The generality of define
    
    Actually, a properly implemented
      (define (square x) (* x x))
    is not equivalent to
      (define square (lambda (x) (* x x)))
    at all, but rather to
      (define square (rec square (lambda (x) (* x x))))
    
    (define (fact1 n)
    	(if (<? n 2)
    	    1
    	    (* n (fact1 (-1+ n)))))
    
    (define fact2
    	 (lambda (n)
    		 (if (<? n 2)
    		     1
    		     (* n (fact2 (-1+ n))))))
    
    					asc
    -------


In T there is *no* difference between these two forms (except that you
get a named-lambda in the first case rather than a lambda).

    > (pp copy1)
    (LAMBDA (N) (IF (<? N 2) 1 (* N (FACT1 (-1+ N)))))     <<<<| Both closed
                                                               | in the same
    > (pp copy2)                                               | environment.
    (LAMBDA (N) (IF (<? N 2) 1 (* N (FACT2 (-1+ N)))))     <<<<|

    > (copy1 5)
    20

    > (copy2 5)
    20

This makes sense to me since (DEFINE (FOO ...) ...) is specified to
be equivalent to (DEFINE FOO (LAMBDA (...) ...)).  In both cases, FOO is
defined to be a closure whose environment is the environment of definition,
i.e., the REPL-ENV.

To get the definition analogous to your REC case, you need to use LABELS
explicitly:   

    > (define fact3
        (labels (((fact3 n) (if (< n 2) 1 (* n (fact3 (-1+ n))))))
           fact3))

    > (define copy3 fact3)

    > (define fact3 (lambda (x) x))

    > (copy3 5)
    120

It might make more sense to make this the default expansion since you
would usually expect the recursive call to refer to the definition-time
procedure (as opposed to its "name"), though now the variables FACT3 and
N have different reference semantics within the same form.  In the case of
two or more mutually recursive functions, you still have to rely on the
run-time values of the cells that the variables in the closure refer to
in the environment that the closure was defined in.  It's debatable,
therefore, whether special reference semantics for the name of the lambda
form is the "proper implementation", though it does seem more natural
albeit hairier.

-- Ashwin.


-------

∂18-Aug-86  1650	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	define syntax (an apology)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 86  16:50:08 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 18 Aug 86 19:44:47 EDT
Received: from tektronix by csnet-relay.csnet id ac01742; 18 Aug 86 18:44 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA07543; Mon, 18 Aug 86 10:42:41 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA03638; Mon, 18 Aug 86 10:45:31 PDT
Message-Id: <8608181745.AA03638@tekchips.TEK>
To: scheme@MC.LCS.MIT.EDU
Cc: willc%tekchips.tek.com@CSNET-RELAY.ARPA
Subject: define syntax (an apology)
In-Reply-To: Your message of Fri, 15 Aug 86 13:47:03 EDT.
	     <[AI.AI.MIT.EDU].84074.860815.JAR>
Date: 18 Aug 86 10:45:30 PDT (Mon)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

A message I sent several months ago recently made it to this mailing list.
By now, my message is incorrect.  I wish to apologize for the confusion I
have caused.

There is an important difference between the 1985 Scheme standard (MIT AI
Memo 848) and the draft of the new 1986 Scheme standard (distributed at
the ACM Conference on Lisp and Functional Programming and expected to
appear in November SIGPLAN Notices).  In the 1985 standard

    (define (foo ...) ...)

was equivalent to

    (define foo (rec foo (lambda (...) ...))).

In the 1986 standard (define (foo ...) ...) is equivalent to

    (define foo (lambda (...) ...)).

As I understand it, the motivation for this change is that in the 1985
semantics, mutual recursion goes through the obvious binding of foo,
but self-recursion goes through the invisible (and therefore mysterious)
binding of foo created by the implicit rec.  It's hard to explain why
self-recursion should behave differently from mutual recursion, so the
1986 semantics gets rid of the implicit rec and the mystery.

This change was inadvertently omitted from the list of changes that
appears in the draft distributed at the Lisp conference, so you have
to read the draft very carefully to spot it.  By the way, the
(define ((foo ...) ...) ...) syntax was also dropped from the draft
as a simplifying measure.

Peace, Will

∂20-Aug-86  2002	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	numbers    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Aug 86  20:02:07 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 20 Aug 86 23:02:06 EDT
Received: from tektronix by csnet-relay.csnet id ag24407; 20 Aug 86 22:44 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA21860; Wed, 20 Aug 86 17:10:36 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA03947; Wed, 20 Aug 86 17:13:22 PDT
Message-Id: <8608210013.AA03947@tekchips.TEK>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: willc%tekchips.tek.com@CSNET-RELAY.ARPA, 
    adams%tekchips.tek.com@CSNET-RELAY.ARPA
Subject: numbers
In-Reply-To: Your message of Wed 16 Jul 86 10:53:32-CDT.
	     <12223161873.35.BARTLEY@CSC60>
Date: 20 Aug 86 17:13:20 PDT (Wed)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

Abstract:  Scheme numbers are still inadequately specified in several
respects.  I propose several improvements.  Some are minor enough to
deserve incorporation in the SIGPLAN Notices publication of the Revised↑3
Report, but the others probably deserve more debate.

Some problems that I perceive with Scheme numbers are:

1.  The quotient procedure is not adequately specified.
2.  The floor etc procedures are not adequately specified.
3.  The syntax for numbers has a redundancy.
4.  The integer? procedure may not be adequately specified.
5.  Valid indexes may not be adequately specified.
6.  The read and string->number procedures are not adequately specified.

(David Bartley has also suggested that the syntax should be made more
compatible with Common Lisp and has proposed that the report be clearer
on which parts of the number syntax are essential and which are not
essential.)

1.  Norman Adams pointed out to me that it is unclear from the description
of quotient in 6.5.4 whether (quotient -13 4) should be -3 or -4; likewise
(quotient 13 -4).  I propose that the sentence beginning "For positive
integers n1 and n2" be followed by the sentence

    For all integers n1 and n2 with n2 not equal to 0,

      (= n1 (+ (* n2 (quotient n1 n2)) (remainder n1 n2)))   ==> #t

2.  In the description of floor, ceiling, truncate, round, and rationalize,
the sentence "Their results are not exact---in fact, their results are
clearly inexact, though they can be made exact with an explicit exactness
coercion" is incorrect.  I propose that the sentence be replaced by "Their
results are exact if and only if their arguments are exact."

3.  The third production for <ureal R> is redundant.

4.  In MacScheme and a few other implementations, (integer? 4.0) evaluates
to #f.  Even assuming that 4.0 is inexact, this seems wrong.  I would like
to see an example in the report to show that it's wrong.

5.  I believe the index or size arguments to list-tail, list-ref,
make-string, string-ref, string-set!, substring-fill!, make-vector,
vector-ref, and vector-set! should be required to be exact integers
instead of just integers.

6.  It isn't clear from the report whether 3.0 reads as an exact or inexact
number.  Indeed the same can be said of 3, or 3/1, or 3###-4###i.  I propose
that this sort of thing be specified more formally, as in the following
example---which does not match up very well with the syntax and is not my
favorite proposal anyway.

    exactness [ <real> + <ureal> i ] = exactness [ <real> - <ureal> i ]
        = minexact (exactness [ <real> ], exactness [ ureal ])
    exactness [ <real←1> @ <real←2> ]
        = minexact (exactness [ <real←1> ], exactness [ <real←2> ]
    exactness [ <sign> <ureal> ] = exactness [ <ureal> ]
    exactness [ <prefix> <x> <suffix> ]
        = if explicit [ <prefix> ]
            then prexact [ <prefix> ]
            else if empty [ <suffix> ]
                    then exactness [ <x> ]
                    else #f                     ; this is what I don't like
    exactness [ <uinteger> <suffix> ]
        = if empty [ <suffix> ] then exactness [ <uinteger> ] else #f
    exactness [ <digit>+ #+ ] = #f
    exactness [ <digit>+ ] = #t
    exactness [ <uinteger←1> / <uinteger←2> ]
        = minexact (exactness [ <uinteger←1> ], exactness [ <uinteger←2> ])
    exactness [ <digit>+ #+ ] = #f
    exactness [ <digit>+ ] = #t
    exactness [ <digit>* . <digit>+ #* ] = #f
    exactness [ <digit>* . #+ ] = #f
    exactness [ <digit>+ . ] = #t
    exactness [ <digit>+ #+ . ] = #f

    minexact (b1, b2) = if b1 then b2 else #f

    explicit [ ... #i ... ] = explicit [ ... #e ... ] = #t
    explicit [ ... <empty exactness> ... ] = #f

    prexact [ ... <exactness> ... ] = prexact [ <exactness> ]
    prexact [ #i ] = #f
    prexact [ #e ] = #t


Peace, Will

∂22-Aug-86  0555	@MC.LCS.MIT.EDU:dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA 	a few more comments
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Aug 86  05:38:43 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 22 Aug 86 08:38:51 EDT
Received: from indiana by csnet-relay.csnet id ac02619; 22 Aug 86 8:33 EDT
Date: Fri, 22 Aug 86 03:03:54 est
From: "R. Kent Dybvig" <dyb%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: a few more comments

It may be too late to bother with any of this, but here are a few
comments on the R3RS copy handed out at the conference.

Functionality
-------------
char-ready? looks too much like char-lower-case?, char-alphabetic?,
etc., and not enough like read-char.  I think read-char-ready? would
be much more appropriate.  Besides, some implementation or future
RnRS may want to have a write-char-ready?.  Is there any reason not
to change the name?

In the number formats, the syntax (exactness) is used within two of
the examples of 6.5.6, but this form is not explicitly allowed in
6.5.7.  My feeling is that the modifier s or e should be required,
as implied in 6.5.7.  The formats are pretty complicated as is.

What happens on string<?, string>?, string<=?, string>=?, string-ci<?,
string-ci>?, string-ci<=?, string-ci>=? when one string is longer
than the other?  I would add "If two strings differ in length but
are the same up to the length of the shorter string, the shorter string
is considered to be lexographically less than the longer string".

The procedure substring-fill! is the only procedure left that sticks
out to me as unnecessary and rarely useful.  Perhaps someone can
explain to me why it should be in the standard.

Why is there not a vector-null? function..., or why not delete null?
and string-null? to be consistent?


Presentation
------------
1.3.1 strike the word "will"

2.1 it is not clear what "extended alphabetic characters" are here;
I think that the list should be moved here from 2.3, which is, after
all, titled "other" notations.  At the least, a forward pointer is
needed.

2.1 last sentence, replace "between" with "among"

2.3 mention that ) is used to close a vector constant

6.9 optional if syntax should not be used in example


True Nitpick
------------
7.3 in first case description...
    (let ((key <key> )
                    ↑ extra space


Kent


∂22-Aug-86  1208	@MC.LCS.MIT.EDU,@SEBASTIAN.THINK.COM:gls@AQUINAS.THINK.COM 	1986 Lisp conference bibliography  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Aug 86  12:07:06 PDT
Received: from Godot.Think.COM by MC.LCS.MIT.EDU 22 Aug 86 14:08:11 EDT
Received: from SEBASTIAN.THINK.COM by Godot.Think.COM; Fri, 22 Aug 86 14:05:52 edt
Date: Fri, 22 Aug 86 14:06 EDT
From: Guy Steele <gls@Think.COM>
Subject: 1986 Lisp conference bibliography
To: common-lisp@SU-AI.ARPA, rrrs-authors@MC.LCS.MIT.EDU
Cc: gls@AQUINAS
Message-Id: <860822140628.4.GLS@SEBASTIAN.THINK.COM>

With the help of Bill Scherlis, I have massaged the table of contents
(with some corrections) for the 1986 ACM Conference on Lisp and
Functional Programming into the form of a bibliography database suitable
for use with LaTeX/BibTeX and (almost) SCRIBE.  The database has been
tested with BibTeX, and uses TeX conventions for forcing capitalization
and for accenting characters (there are three accents acute, one umlaut,
and one "i" with a circumflex over it).  The database should require
only slight modification to make it suitable for use with SCRIBE.

I am mailing out the database in the interest of making it easier for
everyone to refer to all these great papers from the conference.  The
database follows at the end of this message, followed by the BibTeX
transcription of it for a bibliography format very similar to that
required by CACM.  (I considered just mailing out a pointer to an
FTP-able file, but I find that in practice this method is rather clumsy
and people don't use it.)

--Guy

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

@InProceedings(LAWS-IN-MIRANDA
	,Key = "Thompson"
	,Author = "Simon Thompson"
	,Title = "Laws in {M}iranda"
	,Pages = "1-12"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(MINI-ML
	,Key = "Clement"
	,Author = "Dominique Cl\'ement and {Jo\"elle} Despeyroux and Thierry Despeyroux and Gilles Kahn"
	,Title = "A Simple Applicative Language: {M}ini-{ML}"
	,Pages = "13-27"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(INTEGRATING-FUNCTIONAL-AND-IMPERATIVE-PROGRAMMING
	,Key = "Gifford"
	,Author = "David K. Gifford and John M. Lucassen"
	,Title = "Integrating Functional and Imperative Programming"
	,Pages = "28-38"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(EXPERIENCE-WITH-AN-UNCOMMON-LISP
	,Key = "Alberga"
	,Author = "Cyril N. Alberga and Chris Bosman-Clark and Martin Mikelsons and Mary S. Van Deusen and Julian Padget"
	,Title = "Experience with an Uncommon {L}isp"
	,Pages = "39-53"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(DESIDERATA-FOR-THE-STANDARDISATION-OF-LISP
	,Key = "Padget"
	,Author = "Julian Padget and others"
	,Title = "Desiderata for the Standardisation of {L}isp"
	,Pages = "54-66"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(OPTIMIZING-DYNAMICALLY-RETARGETABLE-COMPILER-FOR-COMMON-LISP
	,Key = "Brooks"
	,Author = "Rodney A. Brooks and David B. Posner and James L. McDonald and Jon L. White and Eric Benson and Richard P. Gabriel"
	,Title = "Design of an Optimizing, Dynamically Retargetable Compiler for {C}ommon {L}isp"
	,Pages = "67-85"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(IMPLEMENTATION-OF-PC-SCHEME
	,Key = "Bartley"
	,Author = "David H. Bartley and John C. Jensen"
	,Title = "The Implementation of {PC} {S}cheme"
	,Pages = "86-93"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(CODE-GENERATION-TECHNIQUES-FOR-FUNCTIONAL-LANGUAGES
	,Key = "Fairbairn"
	,Author = "Jon Fairbairn and Stuart C. Wray"
	,Title = "Code Generation Techniques for Functional Languages"
	,Pages = "94-104"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(ARCHITECTURE-FOR-MOSTLY-FUNCTIONAL-LANGUAGES
	,Key = "Knight"
	,Author = "Tom Knight"
	,Title = "An Architecture for Mostly Functional Languages"
	,Pages = "105-112"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(EFFICIENT-MULTIPROCESSOR-COMBINATOR-REDUCTION
	,Key = "Lemaitre"
	,Author = "M. Lema\↑\itre and M. Castan and M.-H. Durand and G. Durrieu and B. Lecussan"
	,Title = "Mechanisms for Efficient Multiprocessor Combinator Reduction"
	,Pages = "113-121"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(CURRY-CHIP
	,Key = "Ramsdell"
	,Author = "John D. Ramsdell"
	,Title = "The {CURRY} Chip"
	,Pages = "122-131"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(VARIATIONS-ON-STRICTNESS-ANALYSIS
	,Key = "Bloss"
	,Author = "Adrienne Bloss and Paul Hudak"
	,Title = "Variations on Strictness Analysis"
	,Pages = "132-142"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(EXPANSION-PASSING-STYLE
	,Key = "Dybvig"
	,Author = "R. Kent Dybvig and Daniel P. Friedman and Christopher T. Haynes"
	,Title = "Expansion-Passing Style:  Beyond Conventional Macros"
	,Pages = "143-150"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(HYGIENIC-MACRO-EXPANSION
	,Key = "Kohlbecker"
	,Author = "Eugene Kohlbecker and Daniel P. Friedman and Matthias Felleisen and Bruce Duba"
	,Title = "Hygienic Macro Expansion"
	,Pages = "151-161"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(EXACT-REAL-ARITHMETIC
	,Key = "Boehm"
	,Author = "Hans-J. Boehm and Robert Cartwright and Mark Riggle and Michael J. O'Donnell"
	,Title = "Exact Real Arithmetic:  A Case Study in Higher Order Programming"
	,Pages = "162-173"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(RECONFIGURABLE-RETARGETABLE-BIGNUMS
	,Key = "White"
	,Author = "Jon L. White"
	,Title = "Reconfigurable, Retargetable Bignums: A Case Study in Efficient, Portable {L}isp System Building"
	,Pages = "174-191"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(LISP-ON-A-REDUCED-INSTRUCTION-SET-PROCESSOR
	,Key = "Steenkiste"
	,Author = "Peter Steenkiste and John Hennessy"
	,Title = "{L}isp on a Reduced-Instruction-Set-Processor"
	,Pages = "192-201"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(PARTITIONING-PARALLEL-PROGRAMS-FOR-MACRO-DATAFLOW
	,Key = "Sarkar"
	,Author = "Vivek Sarkar and John Hennessy"
	,Title = "Partitioning Parallel Programs for Macro-Dataflow"
	,Pages = "202-211"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(NORMA-GRAPH-REDUCTION-PROCESSOR
	,Key = "Scheevel"
	,Author = "Mark Scheevel"
	,Title = "{NORMA}:  A Graph Reduction Processor"
	,Pages = "212-219"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(FOUR-STROKE-REDUCTION-ENGINE
	,Key = "Clack"
	,Author = "Chris Clack and Simon L. Peyton Jones"
	,Title = "The Four-Stroke Reduction Engine"
	,Pages = "220-232"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(USE-OF-LISP-IN-IMPLEMENTING-DENOTATIONAL-SEMANTICS
	,Key = "Lee"
	,Author = "Peter Lee and Uwe Pleban"
	,Title = "On the Use of {L}isp in Implementing Denotational Semantics"
	,Pages = "233-248"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(SEMANTICS-DIRECTED-COMPILING-FOR-FUNCTIONAL-LANGUAGES
	,Key = "Nielson"
	,Author = "Hanne R. Nielson and Flemming Nielson"
	,Title = "Semantics Directed Compiling for Functional Languages"
	,Pages = "249-257"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(CONNECTION-GRAPHS
	,Key = "Bawden"
	,Author = "Alan Bawden"
	,Title = "Connection Graphs"
	,Pages = "258-265"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(IMPLEMENTING-FUNCTIONAL-LANGUAGES-IN-THE-CATEGORICAL-ABSTRACT-MACHINE
	,Key = "Mauny"
	,Author = "Michel Mauny and Asc\'ander Su\'arez"
	,Title = "Implementing Functional Languages in the Categorical Abstract Machine"
	,Pages = "266-278"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(CONNECTION-MACHINE-LISP
	,Key = "Steele"
	,Author = "Steele, Guy L., Jr. and W. Daniel Hillis"
	,Title = "Connection Machine LISP:  Fine-Grained Parallel Symbolic Processing"
	,Pages = "279-297"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(MYSTERY-OF-THE-TOWER-REVEALED
	,Key = "Wand"
	,Author = "Mitchell Wand and Daniel P. Friedman"
	,Title = "The Mystery of the Tower Revealed:  A Non-Reflective Description of the Reflective Tower"
	,Pages = "298-307"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(TYPE-INFERENCE-APPROACH-TO-POLYMORPHIC-EXPRESSIONS
	,Key = "Mitchell"
	,Author = "John C. Mitchell"
	,Title = "A Type-Inference Approach to Reduction Properties and Semantics of Polymorphic Expressions (summary)"
	,Pages = "308-319"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(EQUATIONS-SETS-AND-REDUCTION-SEMANTICS
	,Key = "Jayaraman"
	,Author = "Bharat Jayaraman and Frank S. K. Silbermann"
	,Title = "Equations, Sets, and Reduction Semantics for Functional and Logic Programming"
	,Pages = "320-331"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(SEMANTIC-THEORY-FOR-EQUATIONAL-PROGRAMMING-LANGUAGES
	,Key = "Thatte"
	,Author = "Satish R. Thatte"
	,Title = "Towards a Semantic Theory for Equational Programming Languages"
	,Pages = "332-342"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(PROTOCOL-FOR-DISTRIBUTED-REFERENCE-COUNTING
	,Key = "Lermen"
	,Author = "Claus-Werner Lermen and Dieter Maurer"
	,Title = "A Protocol for Distributed Reference Counting"
	,Pages = "343-350"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(SEMANTIC-MODEL-OF-REFERENCE-COUNTING-AND-ITS-ABSTRACTION
	,Key = "Hudak"
	,Author = "Paul Hudak"
	,Title = "A Semantic Model of Reference Counting and its Abstraction (detailed summary)"
	,Pages = "351-363"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

@InProceedings(DISTRIBUTED-COPYING-GARBAGE-COLLECTION
	,Key = "Rudalics"
	,Author = "Martin Rudalics"
	,Title = "Distributed Copying Garbage Collection"
	,Pages = "364-372"
	,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
	,Organization = "ACM SIGPLAN/SIGACT/SIGART"
	,Year = "1986"
	,Month = Aug
	,Address = "Cambridge, Massachusetts")

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

\bibitem{EXPERIENCE-WITH-AN-UNCOMMON-LISP}
Alberga, Cyril N., Bosman-Clark, Chris, Mikelsons, Martin, Deusen, Mary S. Van, and Padget, Julian.
Experience with an uncommon {L}isp.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 39--53.

\bibitem{IMPLEMENTATION-OF-PC-SCHEME}
Bartley, David H., and Jensen, John C.
The implementation of {PC} {S}cheme.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 86--93.

\bibitem{CONNECTION-GRAPHS}
Bawden, Alan.
Connection graphs.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 258--265.

\bibitem{VARIATIONS-ON-STRICTNESS-ANALYSIS}
Bloss, Adrienne, and Hudak, Paul.
Variations on strictness analysis.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 132--142.

\bibitem{EXACT-REAL-ARITHMETIC}
Boehm, Hans-J., Cartwright, Robert, Riggle, Mark, and O'Donnell, Michael J.
Exact real arithmetic: a case study in higher order programming.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 162--173.

\bibitem{OPTIMIZING-DYNAMICALLY-RETARGETABLE-COMPILER-FOR-COMMON-LISP}
Brooks, Rodney A., Posner, David B., McDonald, James L., White, Jon L., Benson, Eric, and Gabriel, Richard P.
Design of an optimizing, dynamically retargetable compiler for {C}ommon {L}isp.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 67--85.

\bibitem{FOUR-STROKE-REDUCTION-ENGINE}
Clack, Chris, and Jones, Simon L. Peyton.
The four-stroke reduction engine.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 220--232.

\bibitem{MINI-ML}
Cl\'ement, Dominique, Despeyroux, {Jo\"elle}, Despeyroux, Thierry, and Kahn, Gilles.
A simple applicative language: {M}ini-{ML}.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 13--27.

\bibitem{EXPANSION-PASSING-STYLE}
Dybvig, R. Kent, Friedman, Daniel P., and Haynes, Christopher T.
Expansion-passing style: beyond conventional macros.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 143--150.

\bibitem{CODE-GENERATION-TECHNIQUES-FOR-FUNCTIONAL-LANGUAGES}
Fairbairn, Jon, and Wray, Stuart C.
Code generation techniques for functional languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 94--104.

\bibitem{INTEGRATING-FUNCTIONAL-AND-IMPERATIVE-PROGRAMMING}
Gifford, David K., and Lucassen, John M.
Integrating functional and imperative programming.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 28--38.

\bibitem{SEMANTIC-MODEL-OF-REFERENCE-COUNTING-AND-ITS-ABSTRACTION}
Hudak, Paul.
A semantic model of reference counting and its abstraction (detailed summary).
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 351--363.

\bibitem{EQUATIONS-SETS-AND-REDUCTION-SEMANTICS}
Jayaraman, Bharat, and Silbermann, Frank S. K.
Equations, sets, and reduction semantics for functional and logic programming.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 320--331.

\bibitem{ARCHITECTURE-FOR-MOSTLY-FUNCTIONAL-LANGUAGES}
Knight, Tom.
An architecture for mostly functional languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 105--112.

\bibitem{HYGIENIC-MACRO-EXPANSION}
Kohlbecker, Eugene, Friedman, Daniel P., Felleisen, Matthias, and Duba, Bruce.
Hygienic macro expansion.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 151--161.

\bibitem{USE-OF-LISP-IN-IMPLEMENTING-DENOTATIONAL-SEMANTICS}
Lee, Peter, and Pleban, Uwe.
On the use of {L}isp in implementing denotational semantics.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 233--248.

\bibitem{EFFICIENT-MULTIPROCESSOR-COMBINATOR-REDUCTION}
Lema\↑\itre, M., Castan, M., Durand, M.-H., Durrieu, G., and Lecussan, B.
Mechanisms for efficient multiprocessor combinator reduction.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 113--121.

\bibitem{PROTOCOL-FOR-DISTRIBUTED-REFERENCE-COUNTING}
Lermen, Claus-Werner, and Maurer, Dieter.
A protocol for distributed reference counting.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 343--350.

\bibitem{IMPLEMENTING-FUNCTIONAL-LANGUAGES-IN-THE-CATEGORICAL-ABSTRACT-MACHINE}
 
Mauny, Michel, and Su\'arez, Asc\'ander.
Implementing functional languages in the categorical abstract machine.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 266--278.

\bibitem{TYPE-INFERENCE-APPROACH-TO-POLYMORPHIC-EXPRESSIONS}
Mitchell, John C.
A type-inference approach to reduction properties and semantics of polymorphic expressions (summary).
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 308--319.

\bibitem{SEMANTICS-DIRECTED-COMPILING-FOR-FUNCTIONAL-LANGUAGES}
Nielson, Hanne R., and Nielson, Flemming.
Semantics directed compiling for functional languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 249--257.

\bibitem{DESIDERATA-FOR-THE-STANDARDISATION-OF-LISP}
Padget, Julian, et al.
Desiderata for the standardisation of {L}isp.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 54--66.

\bibitem{CURRY-CHIP}
Ramsdell, John D.
The {CURRY} chip.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 122--131.

\bibitem{DISTRIBUTED-COPYING-GARBAGE-COLLECTION}
Rudalics, Martin.
Distributed copying garbage collection.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 364--372.

\bibitem{PARTITIONING-PARALLEL-PROGRAMS-FOR-MACRO-DATAFLOW}
Sarkar, Vivek, and Hennessy, John.
Partitioning parallel programs for macro-dataflow.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 202--211.

\bibitem{NORMA-GRAPH-REDUCTION-PROCESSOR}
Scheevel, Mark.
{NORMA}: a graph reduction processor.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 212--219.

\bibitem{CONNECTION-MACHINE-LISP}
Steele, Jr., Guy L., and Hillis, W. Daniel.
Connection machine lisp: fine-grained parallel symbolic processing.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 279--297.

\bibitem{LISP-ON-A-REDUCED-INSTRUCTION-SET-PROCESSOR}
Steenkiste, Peter, and Hennessy, John.
{L}isp on a reduced-instruction-set-processor.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 192--201.

\bibitem{SEMANTIC-THEORY-FOR-EQUATIONAL-PROGRAMMING-LANGUAGES}
Thatte, Satish R.
Towards a semantic theory for equational programming languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 332--342.

\bibitem{LAWS-IN-MIRANDA}
Thompson, Simon.
Laws in {M}iranda.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 1--12.

\bibitem{MYSTERY-OF-THE-TOWER-REVEALED}
Wand, Mitchell, and Friedman, Daniel P.
The mystery of the tower revealed: a non-reflective description of the reflective tower.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 298--307.

\bibitem{RECONFIGURABLE-RETARGETABLE-BIGNUMS}
White, Jon L.
Reconfigurable, retargetable bignums: a case study in efficient, portable {L}isp system building.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART  (Cambridge, Massachusetts, August 1986), 174--191.


∂23-Aug-86  1738	@MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	Re: numbers    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Aug 86  17:37:49 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 AUG 86  20:38:18 EDT
Date: Sat 23 Aug 86 20:37:17-EDT
From: "Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Re: numbers
To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8608210013.AA03947@tekchips.TEK>
Message-ID: <12233218691.23.GJS@OZ.AI.MIT.EDU>

The real numbers committee met today (all C of us, but we are not sure
if C=2↑Aleph0) in closed session!.  We commend you, David Bartley and
Norm Adams for noticing our grievous errors and we thank you for the
nice suggestions.  We move that suggestions 1-5 be immediately
adopted.  Suggestion 6, concerning the syntax of exact/inexact
numerical constants is still not clear.  What is your favorite
proposal anyway?
-------

∂25-Aug-86  2008	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 	Another nit; my favorite numbers    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 86  20:03:12 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 25 Aug 86 21:26:35 EDT
Received: from tektronix by csnet-relay.csnet id ae02269; 25 Aug 86 18:44 EDT
Received: by tektronix.TEK (5.31/6.16)
	id AA12524; Mon, 25 Aug 86 14:26:48 PDT
Received: by tekchips.TEK (5.31/6.16)
	id AA07580; Mon, 25 Aug 86 14:29:50 PDT
Message-Id: <8608252129.AA07580@tekchips.TEK>
To: rrrs-authors@MC.LCS.MIT.EDU, jar@MC.LCS.MIT.EDU
Subject: Another nit; my favorite numbers
In-Reply-To: Your message of Sat 23 Aug 86 20:37:17-EDT.
	     <12233218691.23.GJS@OZ.AI.MIT.EDU>
Date: 25 Aug 86 14:29:47 PDT (Mon)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA

The description of map in section 6.9 says that its first argument must
be a procedure of one argument.  The description should say instead
that "The {\it list}s must be lists, and {\it proc} must be a procedure
taking as many arguments as there are {\it list}s."

----------------------------------------------------------------
Gerry asked what my favorite proposal was for the implicit exactness
of numeric constants.  It is:

    1.  Constants of the form x+yi, x-yi, and x@y are exact iff both x
        and y are exact as real constants.
    2.  Constants of the form x/y are exact iff both x and y are exact
        as integer constants and there is no explicit prefix that says
        otherwise.
    3.  Constants that contain sharp signs to indicate imprecise digits
        are inexact unless there is an explicit prefix that says
        otherwise.
    4.  Constants that contain a nonempty exponent suffix are exact iff
        they are exact after shifting the decimal point and/or adding
        zeroes to eliminate the exponent.  (For example, 1.1e6 would
        be treated as 1100000, 40e-3 would be treated as .040, 2/3e2
        would be treated as 200/3, and 2/3e-2 would be treated as 2/300.)
    5.  Constants that contain a decimal point but no exponent or sharp
        signs indicating imprecise digits are exact iff there are no
        digits to the right of the decimal point and there is no explicit
        prefix that says otherwise.
    6.  Constants that contain no decimal point, exponent, or sharp
        signs indicating imprecise digits are exact iff there is no
        explicit prefix that says otherwise.

Whew!  Rule 4 is probably the most controversial, followed by rule 5.

peace, Will

∂28-Aug-86  0849	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	Minutes from lunch 5 August 1986  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 86  08:49:31 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 AUG 86  11:48:45 EDT
Date: 28 Aug 1986  11:11 EDT (Thu)
Message-ID: <JINX.12234426370.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   willc%tekchips.tek.csnet@RELAY.CS.NET
Cc:   rrrs-authors@MC.LCS.MIT.EDU
Subject: Minutes from lunch 5 August 1986
In-reply-to: Msg of 14 Aug 1986  16:00-EDT from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA

Wow! we have a full schedule ahead.  Given the amount of flame which
just agreeing on the language has generated, I can imagine what trying
to agree on these issues will cause.  I definitely look forward to it.

Something we might also think about standarizing is graphics
primitives.  I realize this is hardware/system dependent, but it is
probably no harder than agreeing on interrupts and similar things.

It would be nice if simple graphics programs were also portable.

∂28-Aug-86  0908	@MC.LCS.MIT.EDU:mhwu%hplmhw@hplabs.HP.COM 	Minutes/Standardize Graphics    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 86  09:08:20 PDT
Received: from hplabs.HP.COM by MC.LCS.MIT.EDU 28 Aug 86 12:07:54 EDT
Received: from hplmhw by hplabs.HP.COM ; Thu, 28 Aug 86 09:01:43 pdt
Received: by hplmhw ; Thu, 28 Aug 86 09:02:41 pdt
Date: Thu, 28 Aug 86 09:02:41 pdt
From: Henry M. Wu <mhwu%hplmhw@hplabs.HP.COM>
Message-Id: <8608281602.AA00425@hplmhw>
To: JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Cc: willc%tekchips.tek.csnet@RELAY.CS.NET, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Bill Rozas's message of 28 Aug 1986  11:11 EDT (Thu)
Subject: Minutes/Standardize Graphics


One comment I have heard from talking to people around here is that
they are surprised Scheme is trying put everything into the language
specs rather than define libraries (like C, I guess). 

I'm not claiming this is the right thing, but it does seem like
something worth pondering.

Henry


∂28-Aug-86  2012	@MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	Re: Minutes from lunch 5 August 1986    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 86  20:12:07 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 28 AUG 86  14:23:45 EDT
Date: Thu 28 Aug 86 14:21:58-EDT
From: "Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Re: Minutes from lunch 5 August 1986
To: JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <JINX.12234426370.BABYL@MIT-OZ>
Message-ID: <12234461088.59.GJS@OZ.AI.MIT.EDU>

I disagree that it is good to mix graphics in with other things.

I think that graphics is pretty poorly understood and rather idiosyncratic -- 
it will just cause lots of wasted flamage to work on that.
-------

∂29-Aug-86  1503	@MC.LCS.MIT.EDU:andy@ads.ARPA 	graphics for Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Aug 86  15:02:48 PDT
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 29 Aug 86 18:01:17 EDT
Date: Fri, 29 Aug 86 06:41:16 pdt
From: andy@ads.ARPA (Andy Cromarty)
To: rrrs-authors@mit-mc.ARPA
Subject: graphics for Scheme

A good alternative to providing graphics capability is to solve the
more general problem of designing a clean foreign function interface
standard.  This would permit a variety of useful existing software
packages to be integrated into Scheme environments without requiring
that we deflect our attention from substantive language design issues
(and our plate is rather full already) to address ancillary and difficult
problems such as design of packages for graphics, window systems, etc.
This would also make Scheme much more attractive to people who actually
want to use Scheme as a programming language rather than as an object
of study.

Designing a good foreign function interface is nontrivial if we
wish to maintain a principled design approach.  I suspect that 
it would require us to revisit some of the thorny problems we've
brushed up against but not really solved in the past few months,
such as whether Scheme should be thought of as having a dynamic
binding environment vs. an essentially static one defined purely
by the lexical structure of our programs.  In the former case,
a relatively conventional dynamic loading scheme might work best;
for the latter case, a declaration-based system might be more
appropriate.  In either case, we would need a spec for translating
Scheme data structures into those of other languages.  (Perhaps
the SUN xdr might be a good spec to work from for this part of
the problem.)

A foreign function interface might also make Scheme a better
base language environment for studying some difficult contemporary
programming paradigm problems, such as techniques for distributed
and parallel processing.  Currently we achieve this locally at ADS by
extending our Scheme with functions written in C and linked in
statically by the linkage editor.  This has the disadvantage of 
requiring that the researcher know not only how to code the new
parallelism/distributed processing primitives, but also what the 
internal structure of the Scheme environment is in some detail.  
A foreign function interface would provide a sort of firewall that 
would prevent the designer of new constructs from having to know 
what the Scheme implementation's internals look like.

					asc

∂02-Sep-86  1519	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	substring-vector-null-fill!, colitis, etc.   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Sep 86  15:18:30 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 SEP 86  18:18:38 EDT
Date: Tue,  2 Sep 86 18:19:59 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  substring-vector-null-fill!, colitis, etc.
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].90180.860902.JAR>


Here are changes I've made at the requests of people too numerous to
mention (I wish I could acknowledge everyone individually, but time
presses):

I've flushed SUBSTRING-FILL! and STRING-NULL?.  If STRING-NULL? is
retained then VECTOR-NULL?  should be added.  These are both in a
somewhat different class than NULL? since NULL? is often used to
terminate recusrions but STRING- and VECTOR-NULL? aren't.

It's now clearly an error to alter an object returned as the value of a
constant expression, e.g. (string-set! "foo" 1 #\x) and (set-car! '(a b) 'c)
are errors.

The list of extended alphabetics has been moved from "other notations"
to "identifiers".

I'll try to flush the garbage about immutability from the eqv? section,
and leave the question of (eq? '(a) '(a)) unbreached.

Small organizational error fixed: the nonterminal <sequence expression>
is gone, and (begin <sequence>) is now an alternative right-hand side
for <derived expression>.

The equation defining exponentiation has been repaired.

-----
Questions:

- Advice sought on what to do about the grammar for COND and CASE.  In
question is the treatment of non-final ELSE clauses.  Two people have
mentioned that as it stands the grammar is too liberal.  Should I change
it so that there are two rules for each, viz.

  <derived expression>  -->  ...
     | (cond <cond clause>+)
     | (cond <cond clause>* (else <sequence>))
     | ...
     | (case <key> <case clause>+)
     | (case <key> <case clause>* (else <sequence>))
     | ...

?  Seems to me it's not grave if it's left as is, since the text
explains that actually the else clause should come at the end.

- I can sort of see why VECTOR-FILL! exists (it has to exist internally in
any case, in order to support the optional argument), but symmetry
considerations would suggest either flushing it or adding STRING-FILL!.
Opinions?  No change here so far.

- I don't think I have time to change number syntax, although I think
specifying default exactness on input is easier, since I can just copy
text from Will's messages.  I have two small arguments with Will's rule
which says that 1e3 is exact.  One is that this makes exactness somewhat
tricky to determine -- you have to be able to count in order to
determine whether a string represents an exact number or not.  I prefer
the simpler rurule which says that the presence of an exponent marker
makes the number inexact by default.  The second argument stems from CL
compatibility concerns: if Scheme's exact integers are identical to CL's
integers, and Scheme's inexact (rational) flonums are identical to CL's
flonums, then making 1e3 represent an exact number would be an
incompatibility between Scheme and CL.  This correspondence seems
natural to me.  I'd like to hear arguments in favor of Will's rule.

- I'm inclined to demote colon from alphabetic to unspecified (like \ and
|), although I'd like the case to be made more clearly.  I would really
hate to see someone add Common-Lisp-like read-time packaging to any
Scheme, so I don't admit that as a good reason for this change, although
if foo:bar read in the same as (access bar foo) that wouldn't be so bad.
However, I'm primarily a Scheme-in-Common-Lisp user myself these days,
and the implementation and its integration into the host CL would indeed
be cleaner if colon weren't extended alphabetic, so I DO see CL
compatibility as a good reason for the change.

On the side of an alphabetic colon, I should mention that the
moderate-sized community of pro-Scheme people raised on Riesbeck,
Charniak, and/or McDermott's book(s), or otherwise immersed in Yale AI
Lisp culture, use colon pretty heavily as an alphabetic character.

Also, there are some other alternatives for CL <--> Scheme communication:

    - A way to coerce packages to environments, so e.g. if you want
    Lisp's ELT function you can say (access elt lisp-package).  This is
    what CLSCH does now.

    - A procedure which makes Lisp symbols, e.g. (make-lisp-symbol 'lisp
    'elt).

    - A reader syntax such as #[Lisp-symbol lisp elt] or #>Lisp>elt.

None of these is quite as attractive as just saying lisp:elt.

I'll wait for more comments, then flip a coin.

- Jonathan

∂03-Sep-86  0424	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	call-with-xxput-port    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86  04:23:54 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU  3 Sep 86 07:24:24 EDT
Organization: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
	id AA03165; Wed, 3 Sep 86 07:17:30 edt
Date: Wed, 3 Sep 86 07:17:30 edt
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Wed, 3 Sep 86 07:17:30 edt
Message-Id: <8609031117.AA03165@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: call-with-xxput-port

Please do not forget the change associated with
call-with-input-port and call-with-output-port.
I suggest changing the names of no other I/O routines.
John

∂03-Sep-86  0625	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	substring-vector-null-fill!, colitis, etc.  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86  06:25:11 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 SEP 86  09:05:17 EDT
Date: 3 Sep 1986  09:02 EDT (Wed)
Message-ID: <JINX.12235975868.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc:   rrrs-authors@MC.LCS.MIT.EDU
Subject: substring-vector-null-fill!, colitis, etc.
In-reply-to: Msg of 2 Sep 1986  18:19-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>

1) I vote to change the grammar to only allow the final ELSE case.
It does not seem like a very large change.

2) VECTOR-FILL! and STRING-FILL! are completely symmetric.  They both
must exist internally for the MAKE-STRING and MAKE-VECTOR procedures.
FLush both or keep both, but I vote to flush both since they can be
written using VECTOR-SET! and STRING-SET!

3) I think that except in a few cases, it is not necessary to agree on
default exactness in the number syntax.  Anybody who is going to use
advantage of it (whenever somebody implements it), will certainly want
to force the exactness/inexactness of his/her explicit numerals by
using prefixes, and nobody else will care, probably.

The only case that must be decided, in my opinion, is making things
like 3, 123, -456 ("obvious" integers) exact, so they can be used as
indeces to VECTOR-MUMBLE and STRING-MUMBLE.

Thus some implementations could agree to be compatible with CL, and
some to take a completely different approach, but the most common case
(and needed by non-numeric code) would be compatible.

4) I like alphabetic colon, and dislike the CL package system too, but
giving up colon seems like a very minor issue.  There are too many
people trying to make a dual CL/Scheme environment, and we should not
make this job harder than it has to be.  Thus I vote moving colon to
unspecified.

∂04-Sep-86  0858	@MC.LCS.MIT.EDU:F95THOMP%CARLETON.BITNET@WISCVM.WISC.EDU 	Scheme Books?    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86  08:58:39 PDT
Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU  4 Sep 86 11:54:48 EDT
Received: from (F95THOMP)CARLETON.BITNET by WISCVM.WISC.EDU on 09/04/86
  at 10:52:41 CDT
Received: from F95THOMP by CARLETON.BITNET on 03 Sep 86 17:37:10 EDT
Date:     03 Sep 86 17:11:00 EDT
From:       DAVE THOMAS  <F95THOMP%CARLETON.BITNET@WISCVM.WISC.EDU>
To:  <scheme@MC.LCS.MIT.EDU>
Subject:  Scheme Books?


What books are available for Scheme(other than S&ICP)?
Are there solution manuals available for any of these?
Thanks

∂04-Sep-86  1828	@MC.LCS.MIT.EDU:wecker%cookie.DEC@decwrl.DEC.COM 	Please delete me from this distribution list, thanks - dave 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86  18:28:05 PDT
Received: from decwrl.dec.com by MC.LCS.MIT.EDU  4 Sep 86 20:41:23 EDT
Received: by decwrl.dec.com (5.54.2/4.7.34)
	id AA00703; Thu, 4 Sep 86 17:39:12 PDT
Message-Id: <8609050039.AA00703@decwrl.dec.com>
Date: 04-Sep-1986 1022
From: wecker%cookie.DEC@decwrl.DEC.COM  (DAVE  TANSTAAFL  WECKER)
To: scheme@MC.LCS.MIT.EDU
Subject: Please delete me from this distribution list, thanks - dave


∂05-Sep-86  1947	@MC.LCS.MIT.EDU:mh@BU-CS.BU.EDU 	list   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Sep 86  19:46:59 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  5 Sep 86 22:44:06 EDT
Received: from bu-cs.bu.edu by CSNET-RELAY.ARPA id aa00483; 5 Sep 86 16:15 EDT
Return-Path: <mh>
Received: by bu-cs.bu.edu (5.31/4.7)
	id AA04666; Fri, 5 Sep 86 11:11:29 EDT
Date: Fri, 5 Sep 86 11:11:29 EDT
From: Marek Holynski <mh@BU-CS.BU.EDU>
Message-Id: <8609051511.AA04666@bu-cs.bu.edu>
To: scheme@MC.LCS.MIT.EDU
Subject: list

Could you please delete me from the distribution list. Thank you.

∂08-Sep-86  0330	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA 	Beginners question: Advising methods in TI scheme 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86  03:30:35 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  8 Sep 86 06:27:39 EDT
Received: from ubc by csnet-relay.csnet id aa08170; 8 Sep 86 6:19 EDT
Date: Mon, 8 Sep 86 02:28:14 pdt
Received: by ubc.csnet id AA11319; Mon, 8 Sep 86 02:28:14 pdt
From: "Daniel K. Schneider" <shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA>
To: scheme@MC.LCS.MIT.EDU
MMDF-Warning:  Parse error in original version of preceding line at CSNET-RELAY.ARPA
Message-Id: <121:shneider@cui.unige.chunet>
Subject: Beginners question: Advising methods in TI scheme

1) I started writing a program with lots of methods. Now it start loosing
   "track".
-> How can I trace methods in Ti scheme?
   i.e. is there an elegant way of doing it ?

2) Is there any person to whom I should send this kind of request ?

Thanks for any help 
(and reply by e-mail)

-------------------------------------------------------------------------------
Daniel K.Schneider
Departement de science politique, Universite de Geneve
1211 GENEVE 4 (Switzerland), Tel. (..41) 22 20 93 33 ext. 2357

          to VMS/BITNET:                    to UNIX/EAN (preferable):
BITNET:   SCHNEIDER@CGEUGE51                shneider%cui.unige.chunet@CERNVAX
ARPA:     SCHNEIDER%CGEUGE51.BITNET@WISCVM  shneider%cui.unige.chunet@ubc.csnet
uucp:                                       mcvax!cernvax!cui!shneider   
X.400/ean:                                  shneider@cui.unige.chunet


∂08-Sep-86  0826	@MC.LCS.MIT.EDU:philbin-jim@YALE.ARPA 	Re: [THOMAS: Scheme Books?]    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86  08:25:59 PDT
Received: from yale-bulldog by MC.LCS.MIT.EDU  8 Sep 86 11:21:04 EDT
Received: by Yale-Bulldog.YALE.ARPA; 8 Sep 86 11:01:05 EDT (Mon)
Date: 8 Sep 86 11:01:05 EDT (Mon)
From: James F Philbin <philbin-jim@YALE.ARPA>
Message-Id: <8609081501.AA17146@Yale-Bulldog.YALE.ARPA>
Subject: Re: [THOMAS: Scheme Books?]
To: <Scheme@MC.LCS.MIT.EDU>

    What books are available for Scheme ? Are there solution manuals
    available for any of these?
        
Steven Slade had written and introductory programming book which
might be of interest.  Contact SLADE@YALE for details.

    - Jim

    The T Programming Language: A Dialect of LISP
    Stephen Slade
    Prentice-Hall, Englewood Cliffs, N.J.
    To appear: November, 1986
    

∂08-Sep-86  0848	@MC.LCS.MIT.EDU:carr%utah-orion@utah-cs.arpa 	scoops   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86  08:48:32 PDT
Received: from utah-cs.ARPA by MC.LCS.MIT.EDU  8 Sep 86 11:34:07 EDT
Received: by utah-cs.ARPA (5.31/4.40.2)
	id AA22771; Mon, 8 Sep 86 09:32:07 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA03156; Mon, 8 Sep 86 09:32:04 MDT
Date: Mon, 8 Sep 86 09:32:04 MDT
From: carr%utah-orion@utah-cs.arpa (Harold Carr)
Message-Id: <8609081532.AA03156@utah-orion.ARPA>
To: scheme@mc.lcs.mit.edu
Subject: scoops

Could someone tell me how to obtain SCOOPS?

Thanks, Harold

∂08-Sep-86  1334	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA 	Beginners question: Advising methods in TI scheme 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86  13:33:32 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  8 Sep 86 16:25:41 EDT
Received: from ubc by csnet-relay.csnet id aa00411; 8 Sep 86 15:19 EDT
Date: Mon, 8 Sep 86 11:24:54 pdt
Received: by ubc.csnet id AA13463; Mon, 8 Sep 86 11:24:54 pdt
From: "Daniel K. Schneider" <shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA>
Sender: "Daniel K. Schneider" <shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA>
To: scheme@MC.LCS.MIT.EDU
MMDF-Warning:  Parse error in original version of preceding line at CSNET-RELAY.ARPA
Message-Id: <122:shneider@cui.unige.chunet>
Subject: Beginners question: Advising methods in TI scheme

1) I started writing a program with lots of methods. Now it start loosing
   "track".
-> How can I trace methods in Ti scheme?
   i.e. is there an elegant way of doing it ?

2) Is there any person to whom I should send this kind of request ?

Thanks for any help 
(and reply by e-mail)

-------------------------------------------------------------------------------
Daniel K.Schneider
Departement de science politique, Universite de Geneve
1211 GENEVE 4 (Switzerland), Tel. (..41) 22 20 93 33 ext. 2357

          to VMS/BITNET:                    to UNIX/EAN (preferable):
BITNET:   SCHNEIDER@CGEUGE51                shneider%cui.unige.chunet@CERNVAX
ARPA:     SCHNEIDER%CGEUGE51.BITNET@WISCVM  shneider%cui.unige.chunet@ubc.csnet
uucp:                                       mcvax!cernvax!cui!shneider   
X.400/ean:                                  shneider@cui.unige.chunet






∂08-Sep-86  1509	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Good & bad news
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86  15:09:43 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 SEP 86  18:10:23 EDT
Date: Mon,  8 Sep 86 18:11:24 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Good & bad news
To: rrrs-authors@MC.LCS.MIT.EDU
cc: slade@YALE.ARPA, meehan@YALE.ARPA
Message-ID: <[AI.AI.MIT.EDU].92170.860908.JAR>


The good news is that the scheme report is in the mail, and the editor
of SIGPLAN Notices will have it within a couple of days.

The bad news is that the November issue of SIGPLAN, like the October
issue, is devoted to conference proceedings for some conference or
other.  So there is no room for the Scheme report.

Barring other unforeseen catastrophes, it will be in the December issue.
A few people have asked me whether page numbers are known, and I expect
they won't be until known until mid-December.  I suggest calling Dick
Wexelblat on the phone around that time if you really want to know.

We plan to print this version as an MIT AI memo.  I'll make the LaTeX
sources available on MIT-PREP sometime this week.

I'll also US mail hardcopy to the authors.  If the Indiana CS department
is interested in issuing it as a new tech report, I'd be happy to mail a
magnetic tape with the sources & DVI file.

Jonathan

∂08-Sep-86  1614	@MC.LCS.MIT.EDU:wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA 	substring-vector-null-fill!, coliti  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86  16:14:21 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  8 Sep 86 19:14:47 EDT
Received: from indiana by csnet-relay.csnet id ak01084; 8 Sep 86 16:19 EDT
Date: Mon, 8 Sep 86 13:10:49 est
From: Perry Wagle <wagle%iuvax.indiana.edu@CSNET-RELAY.ARPA>
To: rrrs-authors%mit-mc.CSNET@CSNET-RELAY.ARPA
Subject: substring-vector-null-fill!, coliti

  If |(set-car! '(a b) 'c)| is an error, how about |(set-car! '(d e) 'f)|?
That is, when do backquoted expressions denote constants?  (I vote never).
[A related question is whether |`(d e)| returns the same list each time it
is executed.  I suspect you may want to table the above paragraph.]

  Vectors have constant length.  Strings have variable length.  With this
view it would make sense to "fill" a vector, but not a string.

Perry Wagle, Indiana University, Bloomington Indiana.
...!ihnp4!inuxc!iuvax!wagle	(USENET)
wagle@indiana			(CSNET)
wagle%indiana@csnet-relay	(ARPA)


∂08-Sep-86  2212	@MC.LCS.MIT.EDU:asrivast%tilde%ti-csl.csnet@CSNET-RELAY.ARPA 	Advising methods in TI Scheme    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Sep 86  22:12:23 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  8 Sep 86 23:03:17 EDT
Received: from ti-csl by csnet-relay.csnet id aa02126; 8 Sep 86 18:03 EDT
Received: by tilde id AA26422; Mon, 8 Sep 86 15:25:20 cdt
Date: Mon, 8 Sep 86 15:25:20 cdt
From: Amitabh Srivastava <asrivast%tilde%ti-csl.csnet@CSNET-RELAY.ARPA>
To: schneider%cui.unige.chunet%ubc@CSNET-RELAY.ARPA
Subject: Advising methods in TI Scheme
Cc: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA



>>  1) I started writing a program with lots of methods. Now it start loosing
>>     "track".
>>    -> How can I trace methods in Ti scheme?
>>      i.e. is there an elegant way of doing it ?


The procedure %sc-method-env returns the environment containing
the methods of a class. By using this and advise-entry and advise-exit
different tracing macros can be written.

For example, we can write a special form trace-method-entry to trace 
the entry of method m1 of class class1.

(trace-method-entry m1 class1)

=>

(macro trace-method-entry 
  (lambda (e)
    (let ((method (cadr e))
	  (class  (caddr e)))
      `(ADVISE-ENTRY 
         (ACCESS ,method (%sc-method-env ,class))
         (lambda (p a e)
           (writeln " The method " ',method " of class " ',class 
                    " is called with " a))))))

Similarly one can write a macro to trace exits.



- amitabh


∂09-Sep-86  0429	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Slade's book in bib?    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Sep 86  04:29:08 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU  9 Sep 86 07:28:53 EDT
Organization: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
	id AA17988; Tue, 9 Sep 86 07:21:18 edt
Date: Tue, 9 Sep 86 07:21:18 edt
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Tue, 9 Sep 86 07:21:18 edt
Message-Id: <8609091121.AA17988@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Slade's book in bib?

Maybe Stephen Slade's book on T should be added to
the r↑3rs bibliography.  Would some one with access
to it, make a recommendation?
John

∂13-Sep-86  2054	@MC.LCS.MIT.EDU:fowler@rochester.arpa 	Re:  Prolog in Scheme?    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Sep 86  20:53:51 PDT
Received: from ur-cayuga.arpa by MC.LCS.MIT.EDU 13 Sep 86 23:35:30 EDT
Received: from ur-seneca.arpa (ur-seneca) by ur-cayuga.arpa id AA08101 (4.12x); Sat, 13 Sep 86 23:09:58 edt
Received: by ur-seneca.arpa id AA05145 (4.12x); Sat, 13 Sep 86 23:11:43 edt
Message-Id: <8609140311.5145@ur-seneca.arpa>
Date: Sat, 13 Sep 86 23:11:43 edt
From: Rob Fowler  <fowler@rochester.arpa>
To: scheme@MC.LCS.MIT.EDU, MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU
Cc: Rob Fowler  <fowler@rochester.arpa>
Subject: Re:  Prolog in Scheme?

If you get any responses I'd appreciate it if you could pass them along to
me.  I'm currently teaching an "AI Programming" course entirely in Scheme
using MacScheme and I'd really like to get hld of a Prolog or even a subset
that I could turn the students loose on for a couple of weeks.

-- Rob Fowler (fowler@rochester.edu)

∂14-Sep-86  0204	@MC.LCS.MIT.EDU:MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU 	Prolog in Scheme? 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Sep 86  02:04:32 PDT
Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU 13 Sep 86 22:41:47 EDT
Received: from (MWILSON)CARLETON.BITNET by WISCVM.WISC.EDU on 09/11/86
  at 09:16:21 CDT
Received: from MWILSON by CARLETON.BITNET on 09 Sep 86 16:08:31 EDT
Date:     08 Sep 86 15:49:00 EDT
From:       Mike Wilson  <MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU>
To:  <scheme@MC.LCS.MIT.EDU>
Subject:  Prolog in Scheme?


Hello,
    Are there any implementations of Prolog written in Scheme? I'm
interested in any and all versions from minimal to full-featured.

                                                    .Mike

∂15-Sep-86  0450	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Prolog in Scheme?   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86  04:50:44 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 SEP 86  07:37:08 EDT
Date: Sun, 14 Sep 86 12:34:06 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Prolog in Scheme?
To: fowler@ROCHESTER.ARPA
cc: MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU, scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Sat 13 Sep 86 23:11:43 edt from Rob Fowler <fowler at rochester.arpa>
Message-ID: <[AI.AI.MIT.EDU].93903.860914.JAR>

    Date: Sat, 13 Sep 86 23:11:43 edt
    From: Rob Fowler <fowler at rochester.arpa>

    If you get any responses I'd appreciate it if you could pass them along to
    me.  I'm currently teaching an "AI Programming" course entirely in Scheme
    using MacScheme and I'd really like to get hld of a Prolog or even a subset
    that I could turn the students loose on for a couple of weeks.

Why not just use the query system in Structure & Interpretation?

- Jonathan

∂15-Sep-86  1223	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Begin in the Formal Semantics
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86  12:23:38 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 15 Sep 86 15:22:59 EDT
Organization: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
	id AA16806; Mon, 15 Sep 86 15:15:40 edt
Date: Mon, 15 Sep 86 15:15:40 edt
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Mon, 15 Sep 86 15:15:40 edt
Message-Id: <8609151915.AA16806@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Begin in the Formal Semantics

Begin is described in the abstract syntax, but there is
no semantic function for it.  Later, on page 35, the
semantics of begin is given under the derived expression
types heading.  Should begin be described in the abstract
syntax section?
John

∂15-Sep-86  1237	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Begin in the Formal Semantics 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86  12:36:19 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 SEP 86  15:35:43 EDT
Date: Mon, 15 Sep 86 15:38:17 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Begin in the Formal Semantics
To: ramsdell%faron@MITRE-BEDFORD.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 15 Sep 86 15:15:40 edt from John D. Ramsdell <ramsdell%faron at mitre-bedford.ARPA>
Message-ID: <[AI.AI.MIT.EDU].94273.860915.JAR>

    Date: Mon, 15 Sep 86 15:15:40 edt
    From: John D. Ramsdell <ramsdell%faron at mitre-bedford.ARPA>
    To:   rrrs-authors%mc.lcs.mit.edu at mitre-bedford.ARPA
    Re:   Begin in the Formal Semantics
    Organization: The MITRE Corp., Bedford, MA
    Posted-Date: Mon, 15 Sep 86 15:15:40 edt
    Message-Id: <8609151915.AA16806@faron.MENET>

    Begin is described in the abstract syntax, but there is
    no semantic function for it.  Later, on page 35, the
    semantics of begin is given under the derived expression
    types heading.  Should begin be described in the abstract
    syntax section?

It should be flushed from the abstract syntax.  I intended to do this
but only partially succeeded.

Jonathan

∂15-Sep-86  1243	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Begin in the Formal Semantics 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86  12:42:52 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 SEP 86  15:36:31 EDT
Date: Mon, 15 Sep 86 15:39:29 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Begin in the Formal Semantics
To: ramsdell%faron@MITRE-BEDFORD.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].94274.860915.JAR>

    Date: Mon, 15 Sep 86 15:15:40 edt
    From: John D. Ramsdell <ramsdell%faron at mitre-bedford.ARPA>
    To:   rrrs-authors%mc.lcs.mit.edu at mitre-bedford.ARPA
    Re:   Begin in the Formal Semantics
    Organization: The MITRE Corp., Bedford, MA
    Posted-Date: Mon, 15 Sep 86 15:15:40 edt
    Message-Id: <8609151915.AA16806@faron.MENET>

    Begin is described in the abstract syntax, but there is
    no semantic function for it.  Later, on page 35, the
    semantics of begin is given under the derived expression
    types heading.  Should begin be described in the abstract
    syntax section?

It should be flushed from the abstract syntax.  I intended to do this
but only partially succeeded.

Jonathan

∂15-Sep-86  1910	@MC.LCS.MIT.EDU:asrivast%tilde%ti-csl.csnet@CSNET-RELAY.ARPA 	Advising methods in TI Scheme    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86  19:10:25 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 15 Sep 86 22:06:12 EDT
Received: from ti-csl by csnet-relay.csnet id ag02059; 15 Sep 86 13:20 EDT
Received: by tilde id AA13084; Mon, 15 Sep 86 10:11:25 cdt
Date: Mon, 15 Sep 86 10:11:25 cdt
From: Amitabh Srivastava <asrivast%tilde%ti-csl.csnet@CSNET-RELAY.ARPA>
To: scheme%mc.lcs.mit.edu@CSNET-RELAY.ARPA
Subject: Advising methods in TI Scheme
Cc: shneider%cui.unige.chunet%ubc.csnet@CSNET-RELAY.ARPA



>>  1) I started writing a program with lots of methods. Now it start loosing
>>     "track".
>>    -> How can I trace methods in Ti scheme?
>>      i.e. is there an elegant way of doing it ?


The procedure %sc-method-env returns the environment containing
the methods of a class. By using this and advise-entry and advise-exit
different tracing macros can be written.

For example, we can write a special form trace-method-entry to trace 
the entry of method m1 of class class1.

(trace-method-entry m1 class1)

=>

(macro trace-method-entry 
  (lambda (e)
    (let ((method (cadr e))
	  (class  (caddr e)))
      `(ADVISE-ENTRY 
         (ACCESS ,method (%sc-method-env ,class))
         (lambda (p a e)
           (writeln " The method " ',method " of class " ',class 
                    " is called with " a))))))

Similarly one can write a macro to trace exits.



- amitabh




∂17-Sep-86  1224	@MC.LCS.MIT.EDU:prlb2!vauclair@seismo.CSS.GOV 	Request for information on new releases.   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 86  12:19:53 PDT
Received: from seismo.CSS.GOV by MC.LCS.MIT.EDU 17 Sep 86 15:15:29 EDT
Return-Path: <prlb2!vauclair>
Received: from prlb2.UUCP by seismo.CSS.GOV with UUCP; Wed, 17 Sep 86 11:27:06 EDT
Received: by prlb2.UUCP (4.12/4.7)
	id AA04826; Wed, 17 Sep 86 17:24:59 -0100
Received: by prlb2.UUCP (4.12/4.7)
	id AA04820; Wed, 17 Sep 86 17:24:41 -0100
Message-Id: <8609171624.AA04820@prlb2.UUCP>
To: scheme@mc.lcs.mit.edu
Cc: prlb2!louis@seismo.CSS.GOV
Subject: Request for information on new releases.
Organisation: Philips Research Laboratory Brussels, Belgium
Uucp-From: mvauclair@prlb2.UUCP
Date: 17 Sep 86 17:24:35 N (Wed)
From: Marc Vauclair <prlb2!vauclair@seismo.CSS.GOV>

First, sorry for  sending this request to scheme@mit-mc instead of
scheme-team@mit-mc but when trying the last address I got the message
reproduced at the end of this one.

For more than a year by now, we are using the MIT Scheme implementation
(Microcode version 6.1, Runtime version 11.2) on our Vax with Unix 4.2. In few
words, we greatly appreciate both the language and its implementation. There
are only two dark spots : 

	- the lack of documentation of the implementation (the only
documentation I have at my disposition are the "Structure and
Interpretation..." book and the revised revised report

	- the slowness of the terminal i/o and in some circumstances of the
	  interpreter itself.

Is a newer version for VAX Unix available ? Does it include a compiler ? Is a
version for SUN 3 available ? How can we get these new versions ? Is it
possible to get some documentation on the implementation ?


	Regards,
		Marc.


[*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*][*]
From: Communications Satellite <seismo!MC.LCS.MIT.EDU!COMSAT>
Subject: Msg of Wednesday, 17 September 1986 06:35-EDT
To: "prlb2!vauclair@seismo.CSS.GOV"
Message-Id: <[MC.LCS.MIT.EDU].88830.860917>

============ A copy of your message is being returned, because: ============
"SCHEME-TEAM" at MC.LCS.MIT.EDU is an unknown recipient.
============ Failed message follows: ============
Received: from seismo.CSS.GOV by MC.LCS.MIT.EDU 17 Sep 86 06:35:14 EDT
Return-Path: <prlb2!vauclair>
Received: from prlb2.UUCP by seismo.CSS.GOV with UUCP; Wed, 17 Sep 86 06:15:00 EDT
Received: by prlb2.UUCP (4.12/4.7)
	id AA26873; Wed, 17 Sep 86 11:28:57 -0100
Received: by prlb2.UUCP (4.12/4.7)
	id AA26863; Wed, 17 Sep 86 11:28:23 -0100
Message-Id: <8609171028.AA26863@prlb2.UUCP>
To: scheme-team@mit-mc.arpa
Cc: prlb2!louis@seismo.CSS.GOV
Subject: Request for information on new releases.
Organisation: Philips Research Laboratory Brussels, Belgium
Uucp-From: mvauclair@prlb2.UUCP
Date: 17 Sep 86 11:27:54 N (Wed)
From: Marc Vauclair <prlb2!vauclair@seismo.CSS.GOV>



∂22-Sep-86  1441	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Revised↑3 Report on Scheme    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 86  14:41:18 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 SEP 86  17:37:29 EDT
Date: Mon, 22 Sep 86 17:39:42 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Revised↑3 Report on Scheme
To: scheme@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].97185.860922.JAR>

Announcement:

The "Revised↑3 Report on the Algorithmic Language Scheme" has been
completed.  It is an updated version of the "Revised Revised Report on
Scheme" which appeared in summer 1985.  A draft of this report was
circulated at the Lisp and Functional Programming Conference last month;
the final version is practically the same as that draft.

The "Revised↑3 Report" will appear in SIGPLAN notices in December of
this year.  It will also be printed as MIT AI Memo 848a and as an
Indiana University CSD technical report.  I'll send a separate message
as soon as I receive ordering information from MIT's publications
office, so everyone who wants one can get one.

- Jonathan Rees

∂24-Sep-86  0739	@MC.LCS.MIT.EDU:DLW@ALDERAAN.SCRC.Symbolics.COM 	[MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU: Prolog in Scheme?] 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86  07:39:12 PDT
Received: from ALDERAAN.SCRC.Symbolics.COM by MC.LCS.MIT.EDU 24 Sep 86 10:34:13 EDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6731; Wed 24-Sep-86 10:32:24 EDT
Date: Wed, 24 Sep 86 10:36 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: [MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU: Prolog in Scheme?]
To: Scheme@MIT-MC.ARPA
In-Reply-To: <860915140445.8.SGR@GROUSE.SCRC.Symbolics.COM>
Message-ID: <860924103627.1.DLW@CHICOPEE.SCRC.Symbolics.COM>

    Date: Mon, 15 Sep 86 14:04 EDT
    From: Stephen G. Rowley <SGR@STONY-BROOK.SCRC.Symbolics.COM>

    Answers, if any, to the Scheme mailing list at MIT:

    Date:     08 Sep 86 15:49:00 EDT
    From:       Mike Wilson  <MWILSON%CARLETON.BITNET@WISCVM.WISC.EDU>
    To:  <scheme@MC.LCS.MIT.EDU>
    Subject:  Prolog in Scheme?


    Hello,
	Are there any implementations of Prolog written in Scheme? I'm
    interested in any and all versions from minimal to full-featured.

							.Mike

It would likewise be interesting to know if there are any versions of
Scheme written in Prolog.


∂24-Sep-86  0936	@MC.LCS.MIT.EDU:searfus@lll-icdc.arpa 	please add me ...    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86  09:36:12 PDT
Received: from lll-icdc.arpa by MC.LCS.MIT.EDU 24 Sep 86 12:31:11 EDT
Date: 24 Sep 86 07:50:00 PDT
From: "Searfus, Robert" <searfus@lll-icdc.arpa>
Subject: please add me ...
To: "scheme" <scheme@mc.lcs.mit.edu>
Reply-To: "Searfus, Robert" <searfus@lll-icdc.arpa>

to the scheme mailing list.

<bob> searfus@lll-icdc.arpa
------

∂25-Sep-86  0750	@MC.LCS.MIT.EDU:TIM@cis.upenn.edu 	prolog in scheme    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 86  07:50:23 PDT
Received: from linc.cis.upenn.edu by MC.LCS.MIT.EDU 25 Sep 86 09:53:06 EDT
Posted-Date: Thu, 25 Sep 86 09:42 EDT
Message-Id: <8609251352.AA02609@linc.cis.upenn.edu>
From: Tim Finin <Tim@cis.upenn.edu>
Subject: prolog in scheme
To: scheme@mc.lcs.mit.edu
Date: Thu, 25 Sep 86 09:42 EDT


We tried using the query system in "Structure & Interpretation" in our
freshman class last year and found it wanting in some respects.  (1) It
doesn't handle disjunctions unless the disjuncts contain the same variables.
(2) It is extremely slow. We were using it in TI's PC Scheme on AT's.  We
gave some very simple logic programming problems (e.g. the standard kinship
relations) and found that the students we spending 10 or 15 minutes waiting
for the query system to finish!  They found this very frustrating.

I'd think I would like to cover the query system from S&I in class because
it's clear and simple and have the students use a more suped-up version that
is reasonably efficient.  In addition, facilities like "retract",
"reconsult", etc. would easy it's use in homeworks.

I'd also like to consider using a system which uses a prolog-like
depth-first backtracking search.

Tim

∂25-Sep-86  1309	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	prolog in scheme   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 86  13:08:50 PDT
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 SEP 86  14:48:06 EDT
Date: 25 Sep 1986  13:27 EDT (Thu)
Message-ID: <JINX.12241791234.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   Tim Finin <Tim@CIS.UPENN.EDU>
Cc:   scheme@MC.LCS.MIT.EDU
Subject: prolog in scheme
In-reply-to: Msg of 25 Sep 1986  09:42-EDT from Tim Finin <Tim at cis.upenn.edu>

    We tried using the query system in "Structure & Interpretation" in our
    freshman class last year and found it wanting in some respects.  (1) It
    doesn't handle disjunctions unless the disjuncts contain the same variables.
    (2) It is extremely slow. We were using it in TI's PC Scheme on AT's.  We
    gave some very simple logic programming problems (e.g. the standard kinship
    relations) and found that the students we spending 10 or 15 minutes waiting
    for the query system to finish!  They found this very frustrating.

(1) GJS consistently updates the query language and fixes versions as bugs
appear.  You should get in touch with him, the bug may have been
fixed.

(2) I have observed this also on MacScheme.  I don't know about PC
Scheme, but in the case of MacScheme the reason is probably that
streams have no interpreter support, they are written in scheme.  This
is unlike MIT Scheme, for which the code was originally written.  PC
Scheme may have the same problem.  While it is not blindingly fast on
our machines at MIT, it only becomes slow with relatively complicated
programs, and is adequately fast for the class.  10 or 15 mins. is way
longer than I've ever seen it take while solving the S&ICP problems.

∂28-Sep-86  0818	@MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Prolog in Scheme   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Sep 86  08:18:29 PDT
Received: from Cs.Ucl.AC.UK by MC.LCS.MIT.EDU 28 Sep 86 11:14:15 EDT
Received: from vax1.cs.ucl.ac.uk by mv1.Cs.Ucl.AC.UK   via Ethernet with SMTP
           id ab02098; 28 Sep 86 16:06 WET
Received: from 44d.cs.ucl.ac.uk by vax1.Cs.Ucl.AC.UK   with SMTP  id a001696;
          28 Sep 86 16:12 BST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK   via Janet with NIFTP
           id a009979; 28 Sep 86 16:07 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Sun, 28 Sep 86 16:04:02 -0100
Message-Id: <28548.8609281504@aiva.ed.ac.uk>
To: scheme@mc.lcs.mit.edu
Subject: Prolog in Scheme

Unfortunately, the query system in Structure and Interpretation is
not Prolog.  In particular, it doesn't handle cut.  While this
may not metter much to some (especially those who think cut should
be fluched anyway), it does make the system considerably
less interesting as an implementation of Prolog.

∂30-Sep-86  0507	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Refering to the Revised↑3 Report on Scheme  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Sep 86  05:07:06 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 30 Sep 86 08:03:09 EDT
Organization: The MITRE Corp., Bedford, MA
Received: by linus.MENET (1.1/4.7)
	id AA02723; Tue, 30 Sep 86 08:04:40 EDT
Date: Tue, 30 Sep 86 08:04:40 EDT
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Tue, 30 Sep 86 08:04:40 EDT
Message-Id: <8609301204.AA02723@linus.MENET>
To: scheme%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Refering to the Revised↑3 Report on Scheme

I've seen "The Revised Revised Report on Scheme or
An UnCommon Lisp" referenced as "R3S".  I would like
to discourage this and suggest using "RRRS" or "R2RS".
The "Revised↑3 Report on the Algorithmic Language Scheme"
will be in December SIGPLAN.  The obvious reference is
"R3RS" which is why I would like to discourge the use
of "R3S" for the UnCommon Lisp report.
John

∂01-Oct-86  1416	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	R↑3RS sources  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 86  14:16:32 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 1 OCT 86  15:44:25 EDT
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 11868; Wed 1-Oct-86 15:44:55-EDT
Date: Wed, 1 Oct 86 15:44 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: R↑3RS sources
To: rrrs-authors@MC.LCS.MIT.EDU
cc: carr@UTAH-ORION.ARPA
Message-ID: <"861001154411.1.jar@AI"@ROCKY-GRAZIANO.LCS.MIT.EDU>


Those of you with Internet FTP capabilities should now be able to get
the report sources from MIT-PREP.  Login as user scheme password scheme,
and get the file

	/scheme/r3rs.tar

if you can use a unix tar file, otherwise get all the files in the
directory "/scheme/documentation/r3rs".

∂02-Oct-86  0803	@MC.LCS.MIT.EDU:GOERZ@SUMEX-AIM.ARPA 	Lost mail   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Oct 86  08:03:29 PDT
Received: from SUMEX-AIM.ARPA by MC.LCS.MIT.EDU  2 Oct 86 10:58:19 EDT
Date: Thu 2 Oct 86 07:56:36-PDT
From: Gunther Goerz <GOERZ@SUMEX-AIM.ARPA>
Subject: Lost mail
To: scheme@MC.LCS.MIT.EDU
cc: Goerz@SUMEX-AIM.ARPA
Message-ID: <12243598741.13.GOERZ@SUMEX-AIM.ARPA>

Unformtunately I made the big mistake to erase the SCHEME mail between
Aug. 4 and Sep. 30 before having read it. As  completely.
As there were some very interesting items on the list, let me please
ask you whether there is a simple way to remail the stuff to me.
Sorry for the inconvenience, it was just my fault!
---Guenther
-------

∂02-Oct-86  1013	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Lost mail 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Oct 86  10:13:06 PDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 OCT 86  11:35:37 EDT
Date: Thu,  2 Oct 86 11:36:35 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Lost mail
To: GOERZ@SUMEX-AIM.ARPA
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Thu 2 Oct 86 07:56:36-PDT from Gunther Goerz <GOERZ at SUMEX-AIM.ARPA>
Message-ID: <[AI.AI.MIT.EDU].101186.861002.JAR>

Use FTP.  Connect to MIT-MC, use an arbitrary user name and password,
and get the file LSPMAI; SCHEME MAIL.  (Note that the file name has
spaces in it.)

You can send questions like this to Scheme-Request@MC.

Jonathan

∂02-Oct-86  1114	@MC.LCS.MIT.EDU:mohammad%utah-orion@utah-cs.arpa 	Can anyone hear me? 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Oct 86  11:14:44 PDT
Received: from utah-cs.ARPA by MC.LCS.MIT.EDU  2 Oct 86 11:42:10 EDT
Received: by utah-cs.ARPA (5.31/4.40.2)
	id AA24166; Thu, 2 Oct 86 09:41:35 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
	id AA24813; Thu, 2 Oct 86 09:41:32 MDT
Date: Thu, 2 Oct 86 09:41:32 MDT
From: mohammad%utah-orion@utah-cs.arpa (Mohammad Pourheidari)
Message-Id: <8610021541.AA24813@utah-orion.ARPA>
To: scheme@mc.lcs.mit.edu
Subject: Can anyone hear me?



Hello, My name is Mohammad Pourheidari.  I am a member of PASS group down
at the University of Utah.  I have made a couple of attempts to get a hold of
Dr. Henry Lieberman; unfortunately both times unsuccessful.  The net address
I have been using is : henry@mit-mc.  Can anyone tell me whether this is the 
best place to send him mail, or even better can anyone tell me what is the
best way to get a hold of him.

Thank you,
Mohammad

∂02-Oct-86  1714	@MC.LCS.MIT.EDU:zorn@kim.Berkeley.EDU 	I am interested in gathering `significant' Scheme programs...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Oct 86  17:14:00 PDT
Received: from kim.Berkeley.EDU by MC.LCS.MIT.EDU  2 Oct 86 20:08:30 EDT
Received: by kim.Berkeley.EDU (5.53/1.17)
	id AA01376; Thu, 2 Oct 86 17:08:00 PDT
Message-Id: <8610030008.AA01376@kim.Berkeley.EDU>
To: scheme@mc.lcs.mit.edu
Subject: I am interested in gathering `significant' Scheme programs...
Date: Thu, 02 Oct 86 17:07:57 PDT
From: Benjamin Zorn <zorn@kim.Berkeley.EDU>


My name is Ben Zorn, and I'm working on the SPUR Multiprocessor Lisp
system at UC Berkeley.  My particular interest is multiprocessor
garbage collection.  My current plans include taking `significant'
Scheme programs and studying the object manipulation behavior that
they have.  By significant, I mean programs that are large enough to
generate reasonable amounts of garbage, and are also considered to be
important programs that are frequently used.  Multiprocessor programs
would be of even more interest to me.  If you have publically
available programs that would be of interest to me, I would greatly
appreciate hearing from you.  I will make a list of the replies
available to this mailing list in a few weeks.

-Ben Zorn (zorn@kim.berkeley.edu)


∂06-Oct-86  2336	@MC.LCS.MIT.EDU:dan%umass-boston.csnet@CSNET-RELAY.ARPA 	SCHEME implementations 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Oct 86  23:36:36 PDT
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU  7 Oct 86 02:25:36 EDT
Received: from umass-boston by csnet-relay.csnet id ab00520; 6 Oct 86 17:08 EDT
Received: by umb.csnet (4.12/4.7)
	id AA11551; Mon, 6 Oct 86 17:01:38 edt
Date: Mon, 6 Oct 86 17:01:38 edt
From: Dan Stefanescu <dan%umass-boston.csnet@CSNET-RELAY.ARPA>
To: scheme%MC.LCS.MIT.EDU@RELAY.CS.NET
Subject: SCHEME implementations
Cc: dan@UMASS-BOSTON.CSNET

Are there any for AT&T hardware, in particular for UNIX PC's and
AT&T 3B2-400 machines ? Any pointers will be greatly appreciated.
Dan


∂15-Oct-86  0606	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Object-Oriented Schemes 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 86  06:06:22 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 15 Oct 86 08:57:28 EDT
Organization: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
	id AA01933; Wed, 15 Oct 86 08:51:14 edt
Date: Wed, 15 Oct 86 08:51:14 edt
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Wed, 15 Oct 86 08:51:14 edt
Message-Id: <8610151251.AA01933@faron.MENET>
To: scheme%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Object-Oriented Schemes
Cc: ramsdell@mitre-bedford.ARPA

I am wondering if people on this list would
like to discuss Object-Oriented Schemes.
Three implementations come to mind at this time.
The oldest I know about is T[1].  TI has put its
Object-Oriented system called SCOOPS in the public
domain, as is T.  I have had no experience with 
SCOOPS.  Oaklisp[2] adds to the T idea of first
class objects and operations, the idea of first
class types.  I'm not sure what this contributes.

Are there any other implementations you would 
like to discuss?
John

[1] Rees, J. & N. Adams IV, "T: a dialect of Lisp or,
Lambda: the ultimate software tool", 1982 Lisp and
Functional Programming, August 1982.

[2] Lang, K. & B. Pearlmutter, "Oaklisp: an
Object-Oriented Scheme with First Class Types",
OOPSLA '86, Sep-Oct 1986.

∂16-Oct-86  1410	@MC.LCS.MIT.EDU:jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK 	Public Domain 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 86  14:10:04 PDT
Received: from Cs.Ucl.AC.UK by MC.LCS.MIT.EDU 16 Oct 86 16:05:42 EDT
Received: from vax1.cs.ucl.ac.uk by mv1.Cs.Ucl.AC.UK   via Ethernet with SMTP
           id aa03935; 16 Oct 86 19:28 WET
Received: from 44d.cs.ucl.ac.uk by vax1.Cs.Ucl.AC.UK   with SMTP  id a006787;
          16 Oct 86 19:43 BST
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK   via Janet with NIFTP
           id a006756; 16 Oct 86 19:43 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Thu, 16 Oct 86 19:43:23 -0100
Message-Id: <5570.8610161843@aiva.ed.ac.uk>
To: scheme@mc.lcs.mit.edu
Subject: Public Domain

   Date: Wed, 15 Oct 86 08:51:14 edt
   From: "John D. Ramsdell" <ramsdell%faron@arpa.mitre-bedford>
   To: scheme <scheme%edu.mit.lcs.mc@arpa.mitre-bedford>
   Subject: Object-Oriented Schemes
   
   I am wondering if people on this list would
   like to discuss Object-Oriented Schemes.
   Three implementations come to mind at this time.
   The oldest I know about is T[1].  TI has put its
   Object-Oriented system called SCOOPS in the public
   domain, as is T.

Well, I would like to discuss such things, but what I'd like to know
at the moment is this: is T now in the public domain?  How might I
obtain a copy of it or of SCOOPS.

I'm sorry if this isn't the proper forum for such questions, but
my options seem somewhat limited from here.

-- Jeff

P.S.  I do have a t2.8, with licence.  Am I now free to copy it
to other machines?

   
   

∂20-Oct-86  0417	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Re:  Public Domain 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 86  04:17:37 PDT
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 20 Oct 86 07:12:26 EDT
Organization: The MITRE Corp., Bedford, MA
Received: from faron.MENET by linus.MENET (1.1/4.7)
	id AA26459; Mon, 20 Oct 86 07:14:57 EDT
Received: by faron.MENET (4.12/4.7)
	id AA07286; Mon, 20 Oct 86 07:06:48 edt
Date: Mon, 20 Oct 86 07:06:48 edt
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Mon, 20 Oct 86 07:06:48 edt
Message-Id: <8610201106.AA07286@faron.MENET>
To: jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK, scheme@mc.lcs.mit.edu
Subject: Re:  Public Domain

The best way to find out the status of the
T project is to write to one of the following address:
t-project@yale.ARPA
decvax!yale!t-poject.UUCP
tproj@YALECS.BITNET

John

∂20-Oct-86  1205	@MC.LCS.MIT.EDU:mhwu%hplmhw@hplabs.HP.COM 	[harris@hplwhh: Re: [ramsdell%faron@mitre-bedford.ARPA: Object-Oriented Schemes]] 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 86  12:05:45 PDT
Received: from hplabs.HP.COM by MC.LCS.MIT.EDU 20 Oct 86 14:18:03 EDT
Received: from hplmhw by hplabs.HP.COM ; Mon, 20 Oct 86 11:16:01 pdt
Received: by hplmhw ; Mon, 20 Oct 86 10:55:43 pdt
Date: Mon, 20 Oct 86 10:55:43 pdt
From: Henry M. Wu <mhwu%hplmhw@hplabs.HP.COM>
Message-Id: <8610201755.AA00122@hplmhw>
To: scheme@mit-mc
Subject: [harris@hplwhh: Re: [ramsdell%faron@mitre-bedford.ARPA: Object-Oriented Schemes]]

From: Warren Harris <harris@hplabs>
Date: Wed, 15 Oct 86  16:56:50 PDT
Subject: Re: [ramsdell%faron@mitre-bedford.ARPA: Object-Oriented Schemes]
To: mhwu@hplabs
In-Reply-To: Your message of 15-Oct-86  13:34:39
X-Mailer: NMail [$Revision: 2.6 $]

Henry:

Please forward my interest in object-oriented extensions to scheme.
I am familiar with scoops and have a paper describing the system's many
shortcommings.

Warren Harris
-------


∂27-Oct-86  1824	@MC.LCS.MIT.EDU:brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA 	Multiple Values: A Survey 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 86  18:24:23 PST
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 Oct 86 21:21:24 EST
Received: from ti-csl by csnet-relay.csnet id ag12153; 27 Oct 86 18:08 EST
Received: from  (home.ARPA) by tilde id AA25293; Mon, 27 Oct 86 16:12:30 cst
Received: by  id AA29154; Mon, 27 Oct 86 16:08:57 cst
Date: Mon, 27 Oct 86 16:08:57 cst
From: Gary Brooks <brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA>
Message-Id: <8610272208.AA29154@>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Multiple Values: A Survey





		       Multiple Values:  A Survey
		       --------------------------


The current proposal (from Will's lunch minutes) for multiple return
values consists of the two functions:

  (receive-values <fcn> <mv-thunk>)
 
which applies <fcn> to the multiple values returned by <mv-thunk>.  And:

  (return <v1> ... <vN>) or
  (values <v1> ... <vN>)

which returns the values <v1> ... <vN>.

Also, in the semantics there is an auxiliary function single, which
currently raises an error if multiple values are returned.  Question (3)
deals with issue of making the auxiliary function available in the
language and questions (7) and (10) indirectly deal with the semantics
for single.


1) Syntactic questions:

   1a) What argument order do we want for receive-values?

   1b) Do we want to use a different name for receive-values? Eg.
       Multiple-value-call, multiple-value-apply, or something else?

   1c) What name do we want for the multiple value return construct?
       Return, values, something else?


2) Do we want receive-values and return to be essential or
non-essential? 

3) Do we want to incorporate the auxiliary semantic function single
into the language (see also (6b)) as:

	(single <mv-thunk>)

such that

	(single (lambda () (return <v1> ... <vN>))) => <v1>.

Should it be essential or non-essential?

4) Should receive-values allow multiple multiple-value-thunks in a manner
similar to Common Lisp's multiple-value-call?  That is all the values
from the various multiple-value-thunks would be "concatenated" before
being passed to the function. 



5) Interaction with call-with-current-continuation.  How are multiple
values returned from a continuation?  Presumably, 

      (call/cc
	  (lambda (cont)
	      ...
	        (cont (return <v1> ... <vN>))))

does not work since the (return <v1> ...  <vn>) is in argument position.
Furthermore, I presume that 


       (call/cc
	   (lambda (k)
	       (receive-values 
                   k
	           (lambda () (return <v1> ... <vN>)))))

won't work, since the escape procedure generated by call/cc is a
"function" of one argument, which would make the above application of
receive-values analogous to:

       (receive-values (lambda (x) ...)
		       (lambda () (return <v1> ... <vN>)))

which (presumably) is an error. 

    5a)  Modify continuations to take a variable number of arguments that
are returned as the multiple values of the continuation.  Eg. 

	(k <v1> ... <vN>)

    5b)  Add a new procedure called 
call-with-multiple-values-current-continuation (or call/mv/cc for short)
that takes a function of one argument, a multiple value escape
procedure.  The escape procedure takes a thunk as an argument and
transmits the values returned by the thunk.  Eg. 

       (call/mv/cc
	   (lambda (k)
	       (k (lambda () (return <v1> ... <vN>)))))


    5c)  Somehow modify the existing version of call/cc so that when the
escape procedure k is invoked, (k v) returns v and

	(receive-values k (lambda () (return <v1> .. <vN>)
	
returns <v1> ... <vn>.  

    5d) Somehow modify multiple values so that they can be cohesively
returned in argument position.  I.e. so (cont (return <v1> ... <vN>)
would work.  (See Opinion message.)

    5e) Something else?


6) What forms pass multiple values through?

More likely than not the following (relatively) tail recursive forms
pass back multiple values. 

    6a) Do LAMBDA, LET and LETREC pass back multiple values from their
        bodies?

    6b) Do IF, COND and CASE pass back multiple values from the arms of
        the conditional?

    6c) Does explicit and implicit BEGIN blocks pass back multiple values 
        from the last form in the block?

But what about other forms?			

    6d) Does DO pass back multiple values from the last form in the exit
        clauses?

    6e) Do AND and OR pass back multiple values from the last form? Or
        in OR's case from any form?

    6f) Can FORCE return multiple values?  (If so how is DELAY
        implemented (i.e. how is make-promise written))

    6g) What other forms pass back multiple values?

    6h) Are there any forms that never pass back multiple values?


7) What happens when multiple values are returned to a context which
doesn't expect them as in predicate position within a conditional or
argument position within an application.  For example:

	(if (return v1 ... VN)
	    <then>
	    <else>)

        or

        (f (return v1 ... VN) ...)

  7a) Coerce the multiple values to a single value as in Common Lisp.  
   
  7b) Instantiate a (first class) multiple values object (see Opinion
      message)

  7c) It would be an error.

  7d) An error would be signaled.

  7e) Other?


8) Do we want to augment existing binding forms (let, let* letrec) to
destructure multiple values or introduce a multiple value version for
each binding form, or not include such a capability?  In each of the
following examples, b1 would be bound to <v1> ... and bN to VN.  Which
is preferred? 

    8a)	(let (((b1 ... bN)              ;; i.e. ((ids*) <exp>)
	       (return <v1> ... <vN>))
	      <other-bindings>)
	     <body>)

    or (perhaps)

    8b)	(multiple-value-let    or (8c) (multiple-value-let
	   (b1 ... bN)                    (((b1 ... bN) 
	   (return <v1> ... <vN>)           (return <v1> ... <vN>))
	   <body>)			    <other-bindings>)
                                           <body>)
    or

    8d)  other

Should (a)-(d) (if any) be essential or non-essential?

9) Similarly, do we want to augment set!  and define to accept multiple
values, define new versions of these constructs or not include these
constructs?  (In the case of define, augmentation would be incompatible
with the non essential forms of define.)  Do we want to make this
essential or non-essential syntax?  In the case of set!, which of the
following is preferred?

   9a)	(set! (id1 ... idN) (return <v1> ... <vN>))
        And (b) or (c) for define.
   or

   9b)	(multiple-value-set! (id1 ... idN) (return <v1> ... <vN>))
        (multiple-value-define (id1 ... idN) (return <v1> ... <vN>))

   or 

   9c)	(multiple-value-set! id1 ... idN (return <v1> ... <vN>))
        (multiple-value-define id1 ... idN (return <v1> ... <vN>))

   or

   9d)   other



10) For those constructs that expect multiple values (presumably,
receive-values, multiple-value-let, multiple-value-let*,
multiple-value-letrec, and multiple-value-set!)  what happens when too
few or too many values are returned.  For example in:

	(multiple-value-let
	   (((Id1 ... IdM) (return <v1> ... <vN>)))
	   <body>)

M arguments are expected and N arguments are returned.

   10a)  N > M  More values returned than expected.

	1) Ignore extra values.
	
	2) It is an error.

	3) An error is signaled.

	4) other.

   10b) M > N  More values expected than returned.

	1) Return as many as needed additional default values. 
	
	2) It is an error.

	3) An error is signaled.

	4) other.

11) What (if any) other constructs do we want for returning multiple
values?  What should their names be?  Do we want a thunk or an
expression for the multiple values form (see (6c)).  Should these
constructs be essential or non-essential?

   11a) the equivalent of (receive-values (lambda x x) <mv-form>)

       1) (multiple-value-list <mv-thunk>)   or 
       2) (values->list <mv-thunk>) or
       3) none
       4) other

   11b)  The equivalent of (apply values <list>)

       1) (values-list <list>)
       2) (list->values <list>)
       3) none
       4) other
       
   11c)  The equivalent of
       (receive-values (lambda x (list->vector x)) <mv-form>)

       1) (multiple-value-vector <mv-thunk>)   or 
       2) (values->vector <mv-thunk>) or
       3) none
       4) other

   11d)  The equivalent of (apply values (vector->list <vector>))

       1) (values-vector <vector>)
       2) (vector->values <vector>)
       3) none
       4) other

   11e)  Any others?




∂27-Oct-86  1859	@MC.LCS.MIT.EDU:brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA 	Multiple Values 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 86  18:58:50 PST
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 27 Oct 86 21:15:18 EST
Received: from ti-csl by csnet-relay.csnet id af12153; 27 Oct 86 18:08 EST
Received: from  (home.ARPA) by tilde id AA25245; Mon, 27 Oct 86 16:11:46 cst
Received: by  id AA29149; Mon, 27 Oct 86 16:08:22 cst
Date: Mon, 27 Oct 86 16:08:22 cst
From: Gary Brooks <brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA>
Message-Id: <8610272208.AA29149@>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Multiple Values



I'd like to see a consensus emerge on multiple values.  To that end I
have summarized the existing proposal and questions from Will's lunch
minutes and added a number of other questions and issues.  As the text
of these questions and issues is somewhat long (280 lines) I have
submitted it in a separate message entitled "Multiple Values: A Survey".
Also, since my own responses to the survey depend on a particular view
of multiple values, I have submitted yet another message explaining my
views on these issues and my response to the survey.  The latter message
is entitled "Multiple values: An Opinion".  Enjoy!

				-- brooks


∂27-Oct-86  2205	@MC.LCS.MIT.EDU:brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA 	Multiple Values: An Opinion    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 86  22:04:37 PST
Received: from CSNET-RELAY.ARPA by MC.LCS.MIT.EDU 28 Oct 86 01:03:52 EST
Received: from ti-csl by csnet-relay.csnet id ah12153; 27 Oct 86 18:09 EST
Received: from  (home.ARPA) by tilde id AA25301; Mon, 27 Oct 86 16:13:04 cst
Received: by  id AA29167; Mon, 27 Oct 86 16:09:35 cst
Date: Mon, 27 Oct 86 16:09:35 cst
From: Gary Brooks <brooks%home%ti-csl.csnet@CSNET-RELAY.ARPA>
Message-Id: <8610272209.AA29167@>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Multiple Values: An Opinion





		      Multiple Values:  An Opinion
		      ----------------------------


Values Objects
--------------

My view on multiple values is based on the principle that everything in
the language should be first class.  For multiple values I postulate an
*IMMUTABLE* values object type.  Values objects are created by the
values function.  So,

	  (values <v0> ... <vN>)

creates a values object with values <v0> ...  <vN>.  Since values
objects are first class objects it would makes sense to bind a values
object to a (single) variable or cons up multiple value objects in a
list.

Components of a values object can be explicitly extracted with the
values-ref function.  Like vectors, values object indexing is 0-based:
So,

	  (values-ref (values <v0> ... <vI> ... <vN>) I) ==> <vI>

Note that the function single can be simply defined as:

	  (lambda (vals) (values-ref vals 0))

The number of values in a values object can be computed with the
function values-length.  Eg.

	  (values-length (values <v0> ... <vN>)) ==> N+1

Lastly, values objects can be identified by the predicate values?.


Values Objects and Identity
---------------------------

Since values objects are immutable they are intentionally
(operationally) identical (eqv?) if they have the same number of values
and if all the values are intentionally identical.  Thus, 

      (eqv? (values <x1> <x2>) (values <y1> <y2>)) ==> #T

iff   (eqv? <x1> <y1>) ==> #T and
      (eqv? <x2> <y2>) ==> #T 

Because of their immutability, The extensional identity (eq?-ness) of
multiple values is left unspecified.  The contention here is that asking
the eq?-ness of values objects is uninteresting (maybe even
meaningless).  It would be analogous to asking whether two bignums are
eq?.

Returning Values Objects
------------------------

A Values object is returned (directly or indirectly through a
continuation) just like any other type of object is returned.


Applying Functions to Values Objects
------------------------------------

Multiple-value-call takes a function and an expression which evaluates
to a values object and applies the function to the values in the values
object.

     (multiple-value-call (lambda (x y) (+ x y)) (values 1 2)) => 3

Also, LAMBDA is augmented so that a lambda expression with a single
(unparenthesized) formal parameter (eg.  (lambda x x)) is applied via
multiple-value-call, the formal parameter is bound to a values object of
all the actual parameters (Note BVL).  Thus,

    (multiple-value-call (lambda x x) (values 1 2)) <=> (values 1 2)

(Note: In (apply (lambda x x) ...), x would get bound to a list,
while in (multiple-value-call (lambda x x) ...), x would get bound to a
values object.  I'm not enthused about the overloading of the single
unparenthesized bvl variable, but could not think of better syntax.)


Summary
-------

First class multiple values, values objects, are desirable for several
reasons:

  1) It simplifies specifying which forms pass multiple values
through.  Simply put, multiple values are passed through any form just
like any other values.
	
  2) It simplifies from where multiple values can be returned.  They can
be returned from anywhere.   In contrast, in Common Lisp multiple values
can only be returned from the last form in an OR expression.  In this
scheme multiple values can be returned from any form in an OR
expression.  

  3) In contrast to the original, thunkified proposal, the forms that
expect multiple values (multiple-value-call, single, etc.)  could be
redefined such that the cumbersome multiple value thunks are replaced
with a simpler multiple value expression.

     Eg. (single (lambda () (mvs ...))) => (single (mvs ...))

  4) It simplifies the interaction with call/cc.  To return multiple
values from a continuation just incant (cont (values <v0> ... <vN>)).

  5) It allows programmers to manipulate multiple values without having
to inefficiently and unaesthetically coerce them to and from list structures.   
Consider:
     
    Expression oriented  as opposed  to thunk oriented.
                                                                   
    (set! l                          (set! l                           
        (cons (mvs ...) ...))           (cons
                                           (multiple-value-call
	                                       list
                                               (lambda () (mvs ...))
                                              ...)))
                                                                     
    (multiple-value-call f (car l))  (apply f (car l))



Efficiency considerations
-------------------------

The immutability of values objects allows the compiler in cohoots with
the runtime system much latitude in representing multiple values.  A
compiler/runtime strategy could be to return multiple values spread out
on the stack or in registers.  When multiple values are returned to a
context which expects them the corresponding values object would never
have to be reified.  For example, in

        (define mvs (lambda (a b c) (values a b c)))

	(multiple-value-let
	   (((x y z) (mvs 1 2 3)))
	   ...)

a values object would not be allocated.  Value objects would only have
to be allocated in the heap when multiple values are returned to a
context which is not expecting multiple values.  For example,

	(cons (values <v0> ... <vN> ) ...)

would require a values object to be allocated.  However, a smart
compiler could avoid allocating a values object in many situations where
multiple values are indirectly expected.  For instance, if the
equivalent of Common Lisp's (multiple-value-prog1 <exp1>...  <expN>) was
implemented as:

          (let ((x <exp1>))
	      <exp2>
              ...
	      <expN>
              (multiple-value-call values x))

a smart compiler could avoid the allocation of the multiple values bound
to x by:

    1) Leaving the multiple values returned by <exp1> spread out on the
       stack. 
    2) Evaluating <exp2> through <expN>.
    3) returning the spread out values of <exp1>.

Similar optimizations could be applied to multiple values returned by
know continuations, like cont, in:

	(call/cc
	   (lambda (cont)
	      ...
	        (cont (values <v0> ... <vN>))
	      ...))

where the presence of the return in argument position would normally
require a values object to be allocated.

In even more esoteric situations, the compiler could represent (a
single group of) multiple values in a values object as well as spread out
on the stack.  For example, in 

   (let [[[x (mvs ...)]]]
                                      ; spread x out on the stack for
                                      ;  fast access
      (multiple-value-call frob x)    ; use the spread out values
      (foo x)                         ; use the values object bound to x
      (multiple-value-call frob x)    ; use the spread out values, since
				      ;  we don't have to worry about
				      ;  foo side-effecting the values
				      ;  in x.
	     ...)


My Answers to the Survey
------------------------

1) (a & b) (multiple-value-call <f> <mv-expression>)
   (c)     (values <v0> ... <vN)

2) Make multiple-value-call and values essential.

3) Include single as (single <mv-expression>) and make it non-essential.

4) Don't allow multiple multiple-value expressions in
   multiple-value-call.

5) call/cc is not a problem with first class values objects.

6) Multiple values (i.e. values objects) are passed through forms just
   like any other value is.

7) Just return a (first class) values object.

8, 9 & 10) Include:
    (multiple-value-let (((ids*) form)*) <body>),
    (multiple-value-let* (((ids*) form)*) <body>), 
    (multiple-value-letrec (((ids*) form)*) <body>)    (maybe),
    (multiple-value-set! (ids*) <form>), and
    (multiple-value-define  (ids*) <form>)

(maybe with mv-* nicknames) as non-essential.  In any of the constructs
signal an error if too many or too few values are returned.


11) a) Include (values->list <mv-expression>) as non-essential.
    b) Include (list->values <list>) as non-essential.
    c) Include (values->vector <mv-expression>) as non-essential.
    d) Include (vector->values <vector>) as non-essential.

    e) other
       include (values-ref <values-object> <index>) as essential
               (values? <object>) as essential	


∂28-Oct-86  0556	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Multiple values    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86  05:56:14 PST
Received: from mitre-bedford.ARPA by MC.LCS.MIT.EDU 28 Oct 86 08:55:41 EST
Organization: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
	id AA21551; Tue, 28 Oct 86 08:49:57 est
Date: Tue, 28 Oct 86 08:49:57 est
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Tue, 28 Oct 86 08:49:57 est
Message-Id: <8610281349.AA21551@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Multiple values
Cc: ramsdell@mitre-bedford.ARPA

I do not see any need for anything other than
some thing like the T version of multiple values.
That is RECEIVE-VALUES, RETURN (possibly called
VALUES), and the macro RECEIVE.  

It would be nice if escape procedures can be applied
to a variable number of arguments, so that the following
would work:

(receive-values 
  (lambda (x y) (list x y))
  (call-with-current-continuation
     (lambda (k) (k 1 2))))		=> (1 2).

but given how often call-with-current-continuation is
used, I think we should be content to pass back list
structure in those rare cases.

I strongly object to Gary Brook's proposal for multiple
values.  The idea of adding a new data structure
smacks of a case of reading the semantic specification
of Scheme too literally.  Using sequences as arguments
to expression continuations is a trick to get around
the fact that functions only take one argument in the
lambda calculus.  The T experience shows that trick
is not needed in real implementations.  

The most serious objection I have to Gary Brook's
proposal was the design philosophy that is implicit
in the proposal.  There seemed to be no attempt to
explain why his proposal had any merit over the much
simpler version as proposed by Will Clinger.  Any proposal
to solve one single language problem with a large addition of 
functions and macros must be accompanied by an explanation.
While such proposals may be the norm in the Common Lisp
community, we must all remember that the Scheme report
starts its introduction with the words "Programming languages
should be designed not by piling feature on top of feature,
but by removing the weaknesses and restrictions that make
additional features appear necessary."
John


∂28-Oct-86  0615	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	Multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86  06:15:42 PST
Received: from geneva by MC.LCS.MIT.EDU 28 Oct 86 09:14:34 EST
Received: by GENEVA.AI.MIT.EDU; Tue, 28 Oct 86 09:13:52 est
Date: Tue, 28 Oct 86 09:13:52 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8610281413.AA14222@geneva>
To: ramsdell%faron%mitre-bedford.ARPA@mc
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: John D. Ramsdell's message of Tue, 28 Oct 86 08:49:57 est
Subject: Multiple values

I agree completely!  All the extra mechanism proposed seems
unnecessary.

A single comments though,

What is the problem with having continuations expect multiple
arguments when they in fact are capable of returning them?

It seems to me that, it is not only the case that it would be nice if

(receive-values 
  (lambda (x y) (list x y))
  (call-with-current-continuation
     (lambda (k) (k 1 2))))		=> (1 2).

worked, but instead it SHOULD work.  Certainly the simplest
implementation of the whole mechanism that I can think of would take
care of this.

∂28-Oct-86  1358	@MC.LCS.MIT.EDU:andy@hobbes.ARPA 	Re:  Multiple values 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86  13:58:20 PST
Received: from grape.ads.ARPA by MC.LCS.MIT.EDU 28 Oct 86 16:46:55 EST
Date: Tue, 28 Oct 86 13:48:40 PST
From: andy@hobbes.ARPA (Andy Cromarty)
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re:  Multiple values

If multiple values are to be defined for Scheme, I personally
would prefer that

(a) They be assigned inessential status, and
(b) Some comment be made in the R?RS admonishing implementors to
    attempt to make lists be of roughly equivalent efficiency, or
    suggesting some stylistic conventions for MV use.

The latter suggestion is motivated by frequent observation of
what seem to me to be excessive or abusive instances of MV use in 
practical code written in other LISPs.   

Returning both the number-theoretic quotient and the remainder 
from a division routine seems like a use of MV's about which
few people would complain; but using MV's instead of creating
and passing composite data structures for related values that are
meant to be treated as an abstract object seems an unnecessary and
obfuscatory use of MV's.  Often it seems people use MV's in such
cases either out of lack of aesthetic sense or because consing up
a data structure is too costly.  An admonition to programmers could
address the former problem; and admonition to implementors, the latter.

					asc

∂30-Oct-86  0139	@MC.LCS.MIT.EDU:harris%hplwhh@HPLABS.HP.COM 	Re: Multiple Values: An Opinion    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 86  01:37:19 PST
Received: from CSNET-RELAY.ARPA (TCP 1201000005) by MC.LCS.MIT.EDU 29 Oct 86 05:34:37 EST
Received: from hplabs.hp.com by CSNET-RELAY.ARPA id aa01350; 28 Oct 86 14:42 EST
Received: from hplms1. by hplabs.HP.COM ; Tue, 28 Oct 86 11:34:15 pst
Received: from hplwhh (hplwhh) by hplms1; Tue, 28 Oct 86 11:33:33 pst
Return-Path: <harris@hplwhh>
Received: by hplwhh ; Tue, 28 Oct 86 11:33:38 pst
From: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
Message-Id: <8610281933.AA05914@hplwhh>
Date: Tue, 28 Oct 86  11:33:30 PDT
Subject: Re: Multiple Values: An Opinion
To: brooks%home%ti-csl.csnet%csnet-relay.arpa@CSNET-RELAY.ARPA, 
    rrrs-authors%MC.LCS.MIT.EDU%csnet-relay.arpa@CSNET-RELAY.ARPA
In-Reply-To: Your message of 27-Oct-86  16:09:35
X-Mailer: NMail [$Revision: 2.6 $]

I'm sorry, I know I'm not supposed to be on this line, but I just had
to state my opinion of multiple values. I think this is one (!) of the
most poorly thought out (and most haphazardly integrated) concepts in 
common lisp. I'd hate to see scheme suffer from the same disease.

First of all, I see no need for the construct whatsoever. Each of
the functions to deal with multiple values can be replaced by existing 
scheme functions:

(values <v1> ... <vn>) => (list <v1> ... <vn>)

(receive-values <fn> <mv-thunk-or-1st-class-mv-obj>) => (apply <fn> <list>)

(single <mv-thunk-or-1st-class-mv-obj>) => (car <list>)

(multiple-value-set! (<id1> ... <idn>) <mvs>) =>
	(map set! '(<id1> ... <idn>) <list>)

Therefore, the multiple value constructs add no new functionality to the
language (shame). They are simply included to increase lisp's efficiency
(a job which is best left up to the compiler). In light of todays cdr-coded
lists I would think consing can be accomplished as efficiently as vector
allocation for multiple-value objects. I would assume the same tricks could
be employed for register or stack allocation of some lists, as they are 
returned to functions which immediately destructure them.

All of your efficiency considerations still hold:

Efficiency considerations 
-------------------------

A compiler/runtime strategy could be to return lists spread out on the
stack or in registers.  When lists are returned to a context which
expects them the corresponding list object would never have to be
reified.  For example, in

     (define mvs (lambda (a b c) (list a b c)))

     (let* ((m (mvs 1 2 3))
	    (x (first m))
	    (y (second m))
	    (z (third m)))
       ...)

a list object would not be allocated.  List objects would only
have to be allocated in the heap when lists are returned to a context
which is not expecting a list.  For example,

     (cons (list <v0> ... <vN> ) ...)

would require a list object to be allocated.  However, a smart
compiler could avoid allocating a list object in many situations where
lists are indirectly expected.  For instance, if the equivalent of
Common Lisp's (multiple-value-prog1 <exp1>... <expN>) was implemented
as:

     (let ((x <exp1>))
       <exp2> 
       ... 
       <expN> 
       x)

a smart compiler could avoid the allocation of the list bound
to x by:

    1) Leaving the list returned by <exp1> spread out on the
       stack. 
    2) Evaluating <exp2> through <expN>.
    3) returning the spread out list of <exp1>.

Similar optimizations could be applied to lists returned by
know continuations, like cont, in:

	(call/cc
	   (lambda (cont)
	      ...
	        (cont (list <v0> ... <vN>))
	      ...))

where the presence of the list in argument position would normally
require a list object to be allocated.

-----

     Lets work at optimizing the compiler, not giving the programmer
his own hooks to optimize. I think most people avoid multiple values
anyway.

Warren Harris
HP Labs, bld 3U
1501 Page Mill Rd.
Palo Alto, CA 94040
harris%hplwhh@hplabs.HP.COM

P.S. How about a nice destructuring facility similar to multiple-value-bind
except for lists (like zetalisp's destructuring-bind). For example, what 
could be implemented with multiple values as:

	(defun foo (x y z) (values x y z))

	(multiple-value-bind (x y z) (foo 1 2 3))

or regular lists as:

	(defun foo (x y z) (list x y z))

	(let* ((all (foo 1 2 3))
	       (x (first all))
	       (y (second all))
	       (z (third all)))
	  ...)
	
could be more concisely stated as:	

	(destructure (x y z) (foo 1 2 3)
	  ...)

Also, arbitrary trees could be destructured:

	(destructure ((x . y) z) '((a b c d) e)
	  (print y))

	=> (b c d)

This would help the compiler in its optimization, as well as give the 
programmer a succinct syntax for a routine procedure.
-------

∂30-Oct-86  1228	@MC.LCS.MIT.EDU:adams%tekchips.tek.csnet@CSNET-RELAY.ARPA 	multiple values 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 86  12:28:10 PST
Received: from CSNET-RELAY.ARPA (TCP 1201000005) by MC.LCS.MIT.EDU 30 Oct 86 11:32:29 EST
Received: from tektronix by csnet-relay.csnet id ab14659; 29 Oct 86 15:49 EST
Received: by tektronix.TEK (5.31/6.16)
	id AA02978; Wed, 29 Oct 86 12:26:44 PST
Received: by tekchips.TEK (5.31/6.16)
	id AA08573; Wed, 29 Oct 86 12:28:59 PST
Date: Wed, 29 Oct 86 12:28:59 PST
From: Norman Adams <adams%tekchips.tek.csnet@CSNET-RELAY.ARPA>
Message-Id: <8610292028.AA08573@tekchips.TEK>
Subject: multiple values
To: rrrs-authors@MC.LCS.MIT.EDU

The language syntax and procedure library both favor calling with multiple
arguments over returning multiple values (no surprise considering that we
haven't have multiple return values in the language).  

I seems to me easier to fix the procedure library than the syntax.  
(Anyone want to adopt the "{...}n" notation that Steele mentions
in "The Ultimate Declarative"?)

Gary's survey identifies some rough edges that adding multiple values
causes.  I favor:

 a) changing call-with-current-continuation as described in 5a
    (call/cc creates n-ary procedures that invoke the continuation with as
    many arguments)

 b) using RECEIVE (or the equivalent), instead of the alternatives of
    either hacking up all the  binding forms, or adding a bunch of 
    new binding forms.

 c) living with it until we have more experience.

I'm for no coersions, no multiple-value-call.

-Norman
-------

∂30-Oct-86  1339	@MC.LCS.MIT.EDU:jinx%geneva.ai.mit.edu@CSNET-RELAY.ARPA 	Multiple Values: An Opinion 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 86  13:39:33 PST
Received: from CSNET-RELAY.ARPA (TCP 1201000005) by MC.LCS.MIT.EDU 30 Oct 86 16:38:01 EST
Received: from geneva.ai.mit.edu by CSNET-RELAY.ARPA id aa01525;
          30 Oct 86 10:51 EST
Received: by GENEVA.AI.MIT.EDU; Thu, 30 Oct 86 10:42:41 est
Date: Thu, 30 Oct 86 10:42:41 est
From: "Guillermo J. Rozas" <jinx%geneva.ai.mit.edu@CSNET-RELAY.ARPA>
Message-Id: <8610301542.AA17018@geneva>
To: harris%hplwhh@HPLABS.HP.COM
Cc: brooks%home%ti-csl.csnet%csnet-relay.arpa%csnet-relay.arpa@CSNET-RELAY.ARPA, 
    rrrs-authors%MC.LCS.MIT.EDU%csnet-relay.arpa%csnet-relay.arpa@CSNET-RELAY.ARPA
In-Reply-To: Warren Harris's message of Tue, 28 Oct 86  11:33:30 PDT
Subject: Multiple Values: An Opinion

    I'm sorry, I know I'm not supposed to be on this line, but I just had
    to state my opinion of multiple values. I think this is one (!) of the
    most poorly thought out (and most haphazardly integrated) concepts in 
    common lisp. I'd hate to see scheme suffer from the same disease.

I can understand your objections when you look at the CL book and
examine the rules for when multiple values are passed back and not.
On closer inspection, however, you will notice that the rule is
uniform (although specified in utmost detail): When dealing with a
compound expression, multiple values are passed back from the
subexpression into which the evaluation of the compound expression
reduces.  In other words, tail-recursion is what determines when
multiple values are passed back.  Unfortunately CL does not require
its implementations to be properly tail-recursive, so they could not
explain the semantics of multiple values in terms of tail-recursion.
We don't have this problem, so the behaviour can be described simply,
and the huge case list can be added as examples, not as the definition
of the bahaviour.

Agreed that there is no semantic need for multiple values, and that
the main consideration is efficiency, but there is no reason not to
add them to the language with inessential status, as long as we also
specify that implementations are free to make them be the obvious
procedures which work on lists, or even the suggestion below (which I
prefer).

I don't agree with you on one count however.  Most of the compiler
optimizations that I see proposed very often suffer from a few bad bugs:

- The idea is simple, so it is assumed that the implementation is also
simple.  This is obviously a fallacy.  I'm specially wary of
optimizations that require a great deal of analysis.  I'm not saying
it cannot be done, just that it is often the case that it takes a
great deal more work than anticipated.

- The optimizations break down across module boundaries.  The main
problem with static analysis is that it needs a closed world model.
This is often hard to provide, and even inappropriate in an
interactive development environment.

- Static optimizations to improve performance badly hurt interpreters.
I know the MIT crowd is in the minority here, but we believe in
interpreters as our main development tool.  Although we also want high
performance compilers, we don't want to sacrifice any performance in
the interpreter.

Consider the following proposal instead, which does not require much
(if any) compiler overhead:

(define (receive-values fn th)
  ((th) fn))

(define (values . all)
  (lambda (receiver)
    (apply receiver all)))

Note that a compiler which understands a little about tail arguments
can optimize the above relatively easily, given that the construction
and destructuring of the list is purely local and contained inside
VALUES.  Even further, since the whole mechanism is contained in 2
procedures, they can easily be implemented as primitives, with
whatever efficiency is desired.  Static compiler analysis to reduce
consing can still be used, but this time it is closure analysis of the
sort many Scheme compilers already do.

Note that the above proposal implies that intermediate forms in AND,
OR, and possibly other special forms would have to be treated
specially, since there is a difference between returning a "normal"
value, and explicitely returning 1 value.

PS: There are two other objections to your message, both minor:

- SET! is a the keyword of a special form, thus it cannot be mapped.

- I (and a fair amount of other people) do not believe in cdr-coding.
It is clearly expensive on stock hardware, and it is not clear to me
that it is not expensive on special purpose hardware, besides adding
unnecessary hair to the complete system and in particular the garbage
collector, and we all know where this leads.

∂30-Oct-86  1520	@MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU 	Re: multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 86  15:20:03 PST
Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 30 Oct 86 15:27:28 EST
Date: Thu 30 Oct 86 12:25:22-PST
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: Re: multiple values
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <8610292028.AA08573@tekchips.TEK>
Message-ID: <12250998624.20.ANDY@Sushi.Stanford.EDU>

I'd like to bring up another multiple-value proposal but first I
have a question.  Why is the scheme community attempting to
standardize this now?  Is it really that well understood?

This proposal is a variant on the technique Carolyn Talcott used
in her thesis; Richard Weyrauch was also involved in that work.

Their idea requires one procedure; I'll call it values.  Procedure
invocation spreads multiple values; (cons (values 1 2)) is completely
equivalent to (cons 1 2) and (list (values) 4 (values 1 2) 3) is
equivalent to (list 4 1 2 3).  (It should be obvious that (values 1)
is completely equivalent to (values (values 1)).)  In Talcott's
system, the last variable in a lambda expression's formal argument
list is preceded by an implicit period; I feel that the optional
explicit period of r↑3rs' syntax is superior.

Call/cc is generalized appropriately as well.  If I understand
receive-values correctly, it is the same as apply.

Most of the other proposals strike me an attempt to add yet another
aggregate data type (in addition to lists and vectors) that predefined
procedures will use to return a number of values.  This is not a bad
idea, different implementations can use different representations, yet
the coercion rules and additional procedures (if a form returns
multiple values, all but the first are discarded unless the programmer
has mastered subtle rules involving tokens not unlike funcall and #')
bother me.

Talcott's scheme is succinct and builds on the rest of the language.
(Look how much of this message was used to explain the idea.)  Its
only disadvantage is that you can't tell how many arguments are being
passed by counting s-expressions.

-andy
-------

∂30-Oct-86  2204	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Oct 86  22:03:57 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 OCT 86  22:06:22 EST
Date: Thu, 30 Oct 86 22:08:03 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  multiple values
To: rrrs-authors@MC.LCS.MIT.EDU, klotz@OZ.AI.MIT.EDU
In-reply-to: Msg of Mon 27 Oct 86 16:08:57 cst from Gary Brooks <brooks%home%ti-csl.csnet at CSNET-RELAY.ARPA>
Message-ID: <[AI.AI.MIT.EDU].112644.861030.JAR>


Since I'm the one who added the procedures VALUES (a.k.a. RETURN) and
RECEIVE to T, it seems appropriate that I should say a word or two about
what the heck I had in mind when I did so.

In the T implementation, the low-level protocols for call to unknown
procedure and return to unknown continuation are almost identical.  The
compiler does CPS conversion and doesn't see the difference much, and
the data representation for implicit continuations is the same as that
for procedures.

The implementation symmetry suggested that maybe some surface-language
symmetry was worth experimenting with.  This was corroborated by the
frequent need for some way to return more than one result value to the
caller.  I had been doing the latter with

	(foo arg1 arg2 ... argn (lambda (val1 val2 ... valm) body)),

and this syntax seemed pretty unweildy (it doesn't indent nicely, for
example); using lists and destructuring wasn't much better.  So in T2,
anticipating future compiler support in T3, a procedure VALUES was
defined to be more or less the same as LIST (actually closer to VECTOR
-- the details are irrelevant), and a macro RECEIVE was invented to get
result values:

	(receive (val1 val2 ...  valm)
		 (foo arg1 arg2 ... argn)
	  body)
	==  (apply (lambda (val1 val2 ... valn) body) 
		   (foo arg1 arg2 ... argn))

The beauty of VALUES and RECEIVE is that they're totally noncommittal
about implementation.  The above is a correct implementation of the
abstraction, but so is the T3 implementation, where

	(define (values . vals)
	  (c-w-c-c (lambda (k) (apply k vals))))

and

	(receive (val1 val2 ...  valm)
		 (foo arg1 arg2 ... argn)
	  body)
	==  (receive-values (lambda () (foo arg1 arg2 ... argn))
			    (lambda (val1 val2 ... valm) body))
	[maybe I have the argument order reversed, I alwasy forget]

and RECEIVE-VALUES is a new primitive procedure.  (We'd never expect a
user to invoke RECEIVE-VALUES explicitly, but it has to exist so that
RECEIVE can be a macro rather than a special form.  It would be
necessary in Scheme to exactly the same extent that MAKE-DELAY is
necessary, which is somewhat.)

Thus if T programs have to ported to some other Scheme dialect, or if T
decides at some future point that multiple-value-returns are a horrible
idea and should be retracted, all our code will still work because the
abstraction is noncommittal.  The nice thing is simply the notation, not
the implementation.  The fact that T3 implements it well encourages its
use (and makes GC's less frequent, which, unfortunately, is a concern),
but is incidental.

A small benefit of having this facility be primitive is that you have an
opportunity for some error checking not previously available, namely you
can get wrong-number-of-return-value errors.  This is good for the same
reason that wrong-number-of-argument errors are good.  But note that it
is a necessary condition in order for the facility to permit varying
implementations.

(I don't see strong reasons for adding destructuring to LET or for any
other linguistic support for the multiple return values besides VALUES
and RECEIVE.)

I'm still not sure how I feel about the feature.  Certainly the
abstraction is a good idea.  As for the semantical foundations, I feel
pretty strongly that call and return should be symmetrical.  If you can
have many arguments, you should be able to return many values.  But note
that (P -> Q) does not necessarily imply Q, it might imply not P.  My
opinion now is that it's probably better to achieve symmetry by flushing
multiple-argument procedures rather than by introducing multiple-value
returns, but this is incompatible with the present shape of Scheme, so I
won't recommend it for this audience.

Gary gives good reasons for introducing immutable data structures.
Algol 68 and ML have the right idea; Lisp and Scheme got it wrong.  It
would certainly be worthwhile to experiment with immutable pairs,
strings, and vectors.  Adding immutable objects onto Scheme (especially
one type without the others) might be a mistake, and it could be the
case that adding immutable objects as an afterthought like this,
coexisting with mutable objects, would result in a very inelegant
language.  (Maybe it could result in a very elegant language... anyone
for ((immutably cons) x y)?  I don't know.)  But I think this is a
question independent of the multiple-value question, and Gary's proposal
is both more complicated and has more far-reaching consequences than
RECEIVE and VALUES, which are trivial.

I like the idea of adding RECEIVE and VALUES to Scheme *without
specifying what happens when some VALUES go somewhere other than to a
RECEIVE*.  The mechanism can be added trivially to any Scheme, and those
that want to optimize it (or which already do) may feel free.
Minimalists can implement the mechanism with lists or closures, Gary can
implement it with immutable vectors, Schemes which are embedded in
Common Lisp or cohabit with it may use CL's multiple values, and T can
do what it does.  It is minimal and noncommittal, it's a pleasant
notation, it captures a common pattern of usage, so why not.

- Jonathan

∂31-Oct-86  1840	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 86  18:40:33 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 OCT 86  21:39:55 EST
Date: Fri, 31 Oct 86 21:41:46 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  multiple values
To: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Fri 31 Oct 86 03:23:10 EST from Alan Bawden <ALAN at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].113058.861031.JAR>

    Date: Fri, 31 Oct 86 03:23:10 EST
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>

    I don't use CL multiple values in any situation where LIST will
    suffice.  I use it just in case I want some "by-products" to be
    transparently discarded by all but a few callers.  This is why
    multiple values were added to the Lisp Machine in the first place,
    and its still the only reason I see to use it.
    ...

As Alan has tactfully pointed out to me, none of the multiple-value
features that Gary Brooks and Andy Freeman and I and others have been
talking about bear much resemblance to CL multiple values, and they are
really intended to solve a different problem.  The terminology is a
problem here; we really shouldn't be saying that these constructs do
"multiple value returns" because Lisp Machine Lisp and its derivatives
(CL) have been using that term for quite a while to mean something quite
different.  (I might have called the LM feature "extra value returns"...)
We should no more think that we're "cleaning up something CL
did wrong" than we should think that omitting optional or keyword arguments,
or macros or packages, solves the problems that those features
were introduced to address.

I agree that the RECEIVE/VALUEs feature is of marginal usefulness.  I
don't think this is the most important outstanding issue we have to talk
about; macros, modules, opaque types, tables, and even bitwise logical
operators all loom larger.  Of course, the more agreement we can get on
any feature at all, the better.

A suggestion on how to proceed: we needn't think of every discussion as
aiming towards something to be included in R↑4RS.  If just 2
implementations agree on a way to do something, we have still gained
something.  We should consider creating an auxiliary document, much more
informal and open-ended than a R↑nRS, describing possibilities for
standard libraries and utilities, possibly with multiple different ways
to do things if no agreement can be reached.  Unanimity may be too
stringent a requirement if this group is to make much progress....

Jonathan

∂31-Oct-86  1916	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Journal of Lisp and Symbolic Computation -- call for papers 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 86  19:15:57 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 31 OCT 86  22:09:15 EST
Date: Fri, 31 Oct 86 22:11:09 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Journal of Lisp and Symbolic Computation -- call for papers
To: scheme@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].113067.861031.JAR>

Date: Fri, 31 Oct 86 12:34:05 PST
From: edsel!sunvalleymall!jlz at navajo.stanford.edu (Jan Zubkoff)
To:   navajo!Common-lisp%sail at navajo.stanford.edu
cc:   sunvalleymall!jlz at navajo.stanford.edu
Re:   Call for Papers
Message-Id: <8610312034.AA09846@sunvalleymall.edsel.uucp>

		      LISP AND SYMBOLIC COMPUTATION:
		      An International Journal
				     
				 10/27/86

			      CALL FOR PAPERS



LISP AND SYMBOLIC COMPUTATION: An International Journal (LASC) is
a new journal published by Kluwer Academic Publishers.  Richard
P. Gabriel, Lucid, Inc. and Guy L. Steele Jr., Thinking Machines,
Inc. are Editors-in-Chief.

The aim of this new journal is to present a forum for current and
evolving symbolic computing, focusing on LISP and
object-oriented programming.  The scope includes:



	* Programming language notations for symbolic computing
	  (e.g., data abstraction, parallelism, lazy evaluation,
	  infinite data objects, self-reference, message-passing,
	  generic functions, inheritance, encapsulation,
	  protection, metaobjects).

	* Implementations and techniques (e.g., specialized
	  architectures, compiler design, combinatory models,
	  garbage collection, storage management, performance
	  analysis, smalltalks, flavors, common loops, etc.).

	* Programming logics (e.g., semantics and reasoning about
	  programs, types and type inference).

	* Programming environments and tools (e.g.,
	  Knowledge-based programming tools, program
	  transformations, specifications, debugging tools).

	* Applications and experience with symbolic computing
	  (e.g., real-time programming, artificial intelligence
	  tools, experience with LISP, object-oriented
	  programming, window systems, user interfaces, operating
	  systems, parallel/distributed computing.

!

			REQUIREMENTS FOR SUBMISSION




Timetable.  Authors must submit five (5) complete copies of their papers.
Notice of acceptance or rejection will be sent to the first author.

Appearance.  Each copy of the paper should be clearly legible.
Papers should be printed on 8-1/2 by 11" paper, double spaced
with at least 1 inch margins with no smaller than 12 pt.  type.

Title Page.  Each copy of the paper must have a title page (separate from
the body of the paper) containing the title of the paper, the names and
addresses of all the authors.  The affiliation appearing under the author's
name should be the name of the organization for which the work was carried
out.  When this is no longer the author's current affiliation, the latter
is given in the address footnote on the first page.  The title page must
specify one topic from the scopes listed on the reverse side of this page.

Abstract.  The abstract should be 150 to 200 words and should be short and
direct.  It should be informative enough to serve as a substitute for
reading the paper itself.  Work planned but not done should not be
described in the abstract.  Do not display formulas and do not use citation
reference numbers.

Review Criteria.  Each paper will be reviewed by experts in the area
specified from the scope as the topic of the paper.  Acceptance will be
based on overall merit and significance of the reported research, as well
as the quality of the presentation.

Please send papers to: 

Jan Zubkoff		
Associate Editor, LASC			
Lucid, Inc.		
707 Laurel Street	
Menlo Park, CA  94025	
edsel!jlz@su-navajo	
(415) 329-8400


Suggestions and inquiries to:

Dick Gabriel			Guy L. Steele Jr.
Editor-in-Chief			Editor-in-Chief
Lucid, Inc.			Thinking Machines, Inc.
707 Laurel Street		245 First Street
Menlo Park, CA  94025		Cambridge, MA  02142
rpg@sail			gls@think.COM
(415) 329-8400			(617) 876-1111

∂03-Nov-86  0855	@MC.LCS.MIT.EDU:gls@Think.COM 	Marvel?  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86  08:54:35 PST
Received: from Godot.Think.COM (TCP 30001264307) by MC.LCS.MIT.EDU  3 Nov 86 11:33:56 EST
Received: from polycarp by Godot.Think.COM via CHAOS; Mon, 3 Nov 86 11:22:41 est
Date: Mon, 3 Nov 86 11:24 EST
From: Guy Steele <gls@Think.COM>
Subject: Marvel?
To: ANDY@Sushi.Stanford.EDU, gjs@MC.LCS.MIT.EDU, rrrs-authors@mc.lcs.mit.edu
Cc: rpg@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <12251488191.9.ANDY@Sushi.Stanford.EDU>
Message-Id: <861103112403.4.GLS@POLYCARP.THINK.COM>

    Date: Sat 1 Nov 86 09:14:39-PST
    From: Andy Freeman <ANDY@Sushi.Stanford.EDU>

    Apparently you wrote a language that had a multiple values
    scheme much like the one I attributed to Talcott and Weyrauch.
    Can you comment on it to rrrs-authors?  (T&W like it and have
    stayed with it; you abandoned it.  I'm sure both had their
    reasons.)

Yes.  For a while I worked on a dialect of Scheme called MARVEL
(Multiple-Return-Value--Expression Lisp; if you ask "where does
the `A' come from?" I say "A is for Acronym").

It did pretty much all the obvious things: every function call was
implicitly like the Common Lisp MULTIPLE-VALUE-CALL, and most
side-effecting forms such as SETQ, PRINT, and COMMENT were made to
return zero values.  I believe I also arranged for variables to
be able to hold multiple values.

My experience with the language was that it was perfectly clean
and elegant, but programs that made non-trivial use of multiple
values were very hard to read, precisely because of the loss
of the one-form/one-value correspondence.  Having the extra power
everywhere in the language was not worth the loss of clarity.
I therefore abandoned the experiment without writing it up.
(Maybe I should have, but there were other, more promising variations
of Scheme to explore.)

I am cc'ing this message to Dick Gabriel, who worked with Weyrauch on
the implementation of SEUS, a language with this geneal flavor.  I
recall him having reported to me the same results with their language,
but he should have the chance to speak for himself.

I believe that experience with the POP languages (especially POP-2)
may be relevant to ths discussion, but I am not an expert there.

--Guy

∂03-Nov-86  1221	@MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU 	gls@AQUINAS/cc  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86  12:19:28 PST
Received: from SAIL.STANFORD.EDU (TCP 1200000013) by MC.LCS.MIT.EDU  3 Nov 86 15:16:56 EST
Date: 03 Nov 86  1214 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: gls@AQUINAS/cc
To:   ANDY@SUSHI.STANFORD.EDU, gjs@MC.LCS.MIT.EDU,
      rrrs-authors@MC.LCS.MIT.EDU   

Multiple Values

I wrote the SEUS compiler for the HP300 (?) version of SEUS. SEUS had
what-I-guess-are-now-called CARTs, which are coalescing multiple values.
Whenever 2 CARTs came near each other, they joined into one larger
one. This resulted in this code

(defun foo (x) (values x x x))

(defun bar (x)(values x x x x))

(list (foo 1)(bar 2)(foo 3))

doing this

=> (1 1 1 2 2 2 2 3 3 3)

The code, as Steele mentions, was elegant in a certain sense, but very
hard to read most of the time, because you had to take into account that
some other values than the primary value (the first one) would be passed
to some program.  The places where SEUS code was easy to read were when you
were writing something that, in Common Lisp, would be

(multiple-value-call #'foo (baz)(bar))

The places where it was hard to read were when you were writing something
that, in Common Lisp, would be

(foo (baz) (bar))

That is, there was no easy way to check that the right values from the
right places got passed. I think that the latter is the more commonly
used case, so SEUS was optimized the wrong way.

It was hard to do this:

(defun foo (x)(values x (+ x 1) (+ x 2)))

(defun baz (x y) ...)

such that calling BAZ on (FOO 1) and (FOO 2) passed 1 and 2 to BAZ.
I recall that SEUS had no way to do this until I was half-way through
writing the compiler. I also recall that variables could be bound to
CARTs, somehow, as part of the solution to the problem - that is, 
you could get X to be bound to the CART, [1 2 3], and Y to [2 3 4].

When the Common Lisp multiple value scheme was being devised, I thought
that we (the designers) should look at SEUS for its experience. I'm now
glad we didn't do anything more that invent MULTIPLE-VALUE-CALL as a
result of that experience.

			-rpg-


∂05-Nov-86  0305	@MC.LCS.MIT.EDU:GOERZ@SUMEX-AIM.ARPA 	[Gunther Goerz <GOERZ@SUMEX-AIM.ARPA>: CScheme for 68K]  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 86  03:04:56 PST
Received: from SUMEX-AIM.ARPA (TCP 1200000070) by MC.LCS.MIT.EDU  5 Nov 86 06:00:47 EST
Date: Wed 5 Nov 86 02:48:18-PST
From: Gunther Goerz <GOERZ@SUMEX-AIM.ARPA>
Subject: [Gunther Goerz <GOERZ@SUMEX-AIM.ARPA>: CScheme for 68K]
To: JAR@AI.AI.MIT.EDU, SCHEME@MC.LCS.MIT.EDU
Message-ID: <12252466434.15.GOERZ@SUMEX-AIM.ARPA>

Mail-From: GOERZ created at 24-Oct-86 03:24:44
Date: Fri 24 Oct 86 03:24:44-PDT
From: Gunther Goerz <GOERZ@SUMEX-AIM.ARPA>
Subject: CScheme for 68K
To: scheme%mit-mc.csnet@RELAY.CS.NET
cc: Goerz@SUMEX-AIM.ARPA
Message-ID: <12249316417.13.GOERZ@SUMEX-AIM.ARPA>

Patrick Greussay of the Univ of Paris 8 and LITP has implemented (at least
one version of) SCHEME in C which is running on a variety of machines,
including 68000 systems.
  --Guenther
-------
-------

∂07-Nov-86  0351	@MC.LCS.MIT.EDU:enea!tut!jh@seismo.CSS.GOV 	eval and orbit  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Nov 86  03:51:47 PST
Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU  7 Nov 86 06:46:47 EST
Received: from enea.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA25326; Fri, 7 Nov 86 06:45:33 EST
Received: by enea.UUCP (5.51/UUCP-Project/rel-1.0/1.8)
	id AA01199; Fri, 7 Nov 86 12:26:05 +0100 (MET)
Date: Fri, 7 Nov 86 13:20:28 -0200
From: enea!tut!jh@seismo.CSS.GOV (Juha Hein{nen)
Return-Path: <jh@tut>
Message-Id: <8611071120.AA033441@tut.uucp>
To: scheme@MC.LCS.MIT.EDU
Subject: eval and orbit

I asked to be put on this list a couple of weeks ago and haven't
received any postings.  Here comes mine as a test.

1.  What is the rational in omitting eval from Scheme?

My program is supposed to read values of enumerated types (i.e.
symbols) and then convert the symbols to their values.  In regular
Lisp I would write (eval (read)) to get the value but how am I
supposed to do that in Scheme?  Use a mapping function from names to
values or is there a simpler way?

2.  Where can I get the Orbit Scheme compiler for my Sun-3
workstation?

	Juha Heinanen
	Tampere Univ. of Technology
	Finland

∂07-Nov-86  1716	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Automatic removal from list...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Nov 86  17:16:39 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 NOV 86  20:11:13 EST
Date: Fri,  7 Nov 86 20:13:16 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Automatic removal from list...
To: scheme@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].115915.861107.JAR>


Scheme@MC is a big mailing list.  On average, one or two members become
unreachable each week, due to changes in routing, gateways being down,
etc.  Be warned that I will ruthlessly remove from the list any
recipients to whom mail is undeliverable.  If you change your address,
be sure to send a note to Scheme-Request@MC.  If your machine has been
down or off the net for a while (usually the various mail systems retry
for three to seven days), and mail bounces as a result, you will likely
be removed.  This is the only way I'll be able to keep things under
control and prevent people who send messages to Scheme from being
deluged with enormous quantities of bounced mail.  Just send me a
message when you're back on, or if you think one of your gateways could
have been down and you haven't seen a message for a couple of weeks.

I sure hope that one of these days electronic mail will be able to reach
people as reliably as physical mail does.  The current state of the art
of e-mail is quite inferior in the respect, probably at about the same
point of development that physical mail was in about the 15th century.

Jonathan

∂07-Nov-86  1817	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	MIT AIM 848a   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Nov 86  18:17:33 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 NOV 86  20:49:51 EST
Date: Fri,  7 Nov 86 20:51:52 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  MIT AIM 848a
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].115926.861107.JAR>

I'll mail copies to y'all (unless I don't have your address or you tell
me not to or you already have one).

Jonathan

∂07-Nov-86  1839	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Hot off the press...
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Nov 86  18:39:15 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 7 NOV 86  20:46:45 EST
Date: Fri,  7 Nov 86 20:48:46 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Hot off the press...
To: scheme@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].115925.861107.JAR>


The new report is ready!  Get them while they last!

It's available in a handsome red binding from the MIT AI Lab
publications office; the address is:

  Elizabeth Heepe
  Publications, Room NE43-818
  MIT Artifical Intelligence Laboratory
  545 Technology Square
  Cambridge MA 02139

Ask for MIT Artificial Intelligence Memo 848a, the "Revised↑3 Report on
the Algorithmic Language Scheme".  Enclose a check for $6.00 per copy
(U.S. funds) payable to the MIT Artificial Intelligence Laboratory.
Prepayment is required.

This version (dated September 1986) supersedes last summer's report,
which was AI memo 848 (this one is 848a).  It also supersedes (but is
very similar to) the draft which was passed out at the Lisp and FP
Conference in August.

It is identical (same original) to the version that will be printed in
SIGPLAN this December, except that in the MIT AI memo version it
additionally includes a previously unpublished article by Abelson and
Sussman entitled "Computation: An Introduction to Engineering Design".

If you want to cite it, probably better to cite the SIGPLAN version
since that will be available to a wider audience:
    Jonathan Rees and William Clinger, editors.
    "Revised↑3 Report on the Algorthmic Language Scheme."
    SIGPLAN Notices 21(12), September 1986.

The report will also appear as an Indiana University CSD Technical
Report.

Here is a brief summary of the more important differences between the
1985 and 1986 versions of the language:

	- Added: delay, force, boolean?, procedure?
	- Removed: #!null, rec, named-lambda, append!, object-hash,
	  object-unhash, 1+, -1+, some of the string operators,
	  "curried define"
	- Redundant names removed: sequence, =?, <?, <=?, >?, >=?
	- Renamed:  #!true -> #t, #!false -> #f
	- Changed: (define (foo ...) ...) now means
		   (define foo (lambda (...) ...)), not
		   (define foo (named-lambda (foo ...) ...))

Other, lesser, changes are enumerated in a special section on page 36.

				- Jonathan Rees

∂08-Nov-86  1121	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Nov 86  11:21:13 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 NOV 86  14:21:03 EST
Date: Sat,  8 Nov 86 14:23:05 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  multiple
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].116160.861108.JAR>


I didn't mean for my message to squelch debate.  Surely someone
disagrees with me.  Speak up.

Jonathan

∂08-Nov-86  1303	@MC.LCS.MIT.EDU,@MIT-MULTICS.ARPA:REMARCK@UCLASSCF.BITNET 	This account is scheduled to be deleted soon...    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Nov 86  13:03:50 PST
Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU  8 Nov 86 15:57:21 EST
Received: from UCLASSCF(MAILER) by MITVMA (Mailer X1.23) id 8286;
          Sat, 08 Nov 86 15:51:19 EST
Received: by UCLASSCF (Mailer X1.23) id 3781; Sat, 08 Nov 86 12:41:14 PST
Date: Sat, 08 Nov 86 12:39:12 PST
From: REMARCK@UCLASSCF (Marc Kriguer)
To:   scheme@MC.LCS.MIT.EDU
Subject: This account is scheduled to be deleted soon...

And to avoid the last-minute rush, I have to start dropping myself from
all the mailing lists I am on.  Please remove my name from the
scheme mailing list.

      Thank you very much!
          Marc Kriguer

∂09-Nov-86  0851	@MC.LCS.MIT.EDU:JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	eval and orbit
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Nov 86  08:50:51 PST
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 9 NOV 86  11:47:16 EST
Date: 9 Nov 1986  11:45 EST (Sun)
Message-ID: <JINX.12253580092.BABYL@MIT-OZ>
From: Bill Rozas <JINX%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To:   enea!tut!jh@SEISMO.CSS.GOV (Juha Hein{nen)
Cc:   scheme@MC.LCS.MIT.EDU
Subject: eval and orbit
In-reply-to: Msg of Fri 7 Nov 86 13:20:28 -0200 from enea!tut!jh at seismo.CSS.GOV (Juha Hein{nen)


    My program is supposed to read values of enumerated types (i.e.
    symbols) and then convert the symbols to their values.  In regular
    Lisp I would write (eval (read)) to get the value but how am I
    supposed to do that in Scheme?  Use a mapping function from names to
    values or is there a simpler way?

Besides the fact that EVAL is not really necessary for most
programming, the problem is that we could not agree on what eval would
mean or do (we didn't try very hard because of the other reason):

Some implementations have a single global environment where
expressions could be evaluated.  In these implementations (eval <x>)
would make sense.

Other implementations have multiple environments where code can be
evaluated.  In these implementations (eval <x>) does not make much
sense.  Eval needs to take a second argument specifying what
environment to evaluate in, and it is not clear that a reasonable
default can be provided so that 1 argument EVAL could work.

You should use a mapping function or something like it if you want
your code to be portable.  Most implementations have an EVAL procedure
(with different behavior) which you can use if you don't care about
that.

∂10-Nov-86  1301	@MC.LCS.MIT.EDU:willc%tekchips.tek.csnet@RELAY.CS.NET 	Re: multiple values 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 86  13:01:44 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Nov 86 16:02:09 EST
Received: from tektronix by csnet-relay.csnet id al11458; 10 Nov 86 15:24 EST
Received: by tektronix.TEK (5.31/6.16)
	id AA09527; Mon, 10 Nov 86 10:53:31 PST
Received: by tekchips.TEK (5.31/6.16)
	id AA04254; Mon, 10 Nov 86 10:53:46 PST
Message-Id: <8611101853.AA04254@tekchips.TEK>
To: JAR@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU, willc%tekchips.tek.com@RELAY.CS.NET
Subject: Re: multiple values
In-Reply-To: Your message of Fri, 31 Oct 86 21:41:46 EST.
	     <[AI.AI.MIT.EDU].113058.861031.JAR>
Date: 10 Nov 86 10:53:41 PST (Mon)
From: willc%tekchips.tek.csnet@RELAY.CS.NET

    I didn't mean for my message to squelch debate.  Surely someone
    disagrees with me.  Speak up.

Ok, Jonathan.  I won't say much because I'm very busy right now.  The
message in question:

    As Alan has tactfully pointed out to me, none of the multiple-value
    features that Gary Brooks and Andy Freeman and I and others have been
    talking about bear much resemblance to CL multiple values, and they are
    really intended to solve a different problem.  The terminology is a
    problem here; we really shouldn't be saying that these constructs do
    "multiple value returns" because Lisp Machine Lisp and its derivatives
    (CL) have been using that term for quite a while to mean something quite
    different.  (I might have called the LM feature "extra value returns"...)
    We should no more think that we're "cleaning up something CL did wrong"
    than we should think that omitting optional or keyword arguments,
    or macros or packages, solves the problems that those features
    were introduced to address.

I see more of a resemblance than Jonathan does.  I happen to think that
CL came close to getting multiple values right, failing only in the choice
of primitives, the complexity of the specification (which, as someone has
observed, was due to the fact that CL doesn't do tail recursion right), and
in the over-reliance upon special forms (which is consistent with the rest
of CL).

The main difference between the RECEIVE/VALUES proposals I've seen and
the way CL does it is that people in the Scheme community seem to assume
that most continuations will require exactly one result, while in CL all
continuations accept any number of results (up to 20, anyway).  It seems
to me, however, that if you're going to have an efficient implementation
mechanism that supports continuations that accept an arbitrary number of
results, then it shouldn't be too hard to make all continuations accept
an arbitrary number of results.  Whether we do this or not should be
determined by whether we think CL got this part of it right.

    I like the idea of adding RECEIVE and VALUES to Scheme *without
    specifying what happens when some VALUES go somewhere other than to a
    RECEIVE*.

Me too.  For one thing, it makes it legal for a Scheme to implement
CL-style semantics for multiple values.

Peace, Will

∂10-Nov-86  1904	@MC.LCS.MIT.EDU:ANDY@Sushi.Stanford.EDU 	silly multiple values   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Nov 86  19:03:46 PST
Received: from Sushi.Stanford.EDU (TCP 4402000065) by MC.LCS.MIT.EDU 10 Nov 86 22:04:23 EST
Date: Mon 10 Nov 86 19:00:15-PST
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: silly multiple values
To: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: <[AI.AI.MIT.EDU].116160.861108.JAR>
Message-ID: <12253954092.9.ANDY@Sushi.Stanford.EDU>

I once saw a proposal for passing arguments with the name used by the
callee.  The idea was that the caller could pass them in any order and
the names provide some documentation.  (I think this came up in a
keyword discussion on CommonLisp; KMP, do you remember more?  BTW - I
don't think it is a good idea.)  For example:

    (cons car 'a cdr 'd) = (cons cdr 'd car 'a)

The major problem with using this idea for returning values is
figuring out the inheritance of named values.  One possible definition
is the following.

The names of returned values have dynamic scope.  The special form
"receive" creates a context for receiving named values.  Its first
argument is a list of the names of the values to be received, its
second argument produces them, and following arguments use them.

The special form "establish" has one or more arguments.  The first is
a list of name-value pairs.  The name is the name of a value to
return, the value is its value.  Subsequent arguments are an implicit
begin whose value is the value of the establish form.  Establish
should only appear in tail-recursive positions.

Receive and establish can be implemented by the following T syntax
definitions.

(define-syntax (receive names produce . body)
  `(apply (lambda , names ,@ body)
	  (bind , (map (lambda (name) `(, name (undefined)))
	               names)
	    , produce
	    (list ,@ names))))

(define-syntax (establish name-value-pairs . body)
  `(begin ,@ (map (lambda (pair) `(set! ,@ pair))
		  name-value-pairs)
	  (undefined)
	  ,@ body))

I don't think this is a good proposal but there may be a good way to
use the basic idea.  It does allow forms to ignore "extra" values and
(this variation) can be implemented simply.

-andy
-------

∂11-Nov-86  0853	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Scheme errors? 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 86  08:53:00 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 11 NOV 86  11:53:08 EST
Date: Tue, 11 Nov 86 11:55:13 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Scheme errors?
To: RDZ@AI.AI.MIT.EDU
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 11 Nov 86 01:22 EST from Ramin Zabih <RDZ at AI.AI.MIT.EDU>
Message-ID: <[AI.AI.MIT.EDU].117255.861111.JAR>

    Date: Tue, 11 Nov 86 01:22 EST
    From: Ramin Zabih <RDZ at AI.AI.MIT.EDU>

    Have I missed something in my reading of the Scheme report, or is there
    in fact no defined way for a program to signal an error?

You didn't miss anything.  However, no such mechanism is needed, because
as long as you avoid defining the variable "error", it should simply
work to say (error ...).  The effect will be a reference to an unbound
variable, and if the debugging system is halfway decent you'll be able
to see the arguments.

Seriously though, I think most implementations have an "error" procedure
(or special form) which is compatible with S&ICP (and not with CL).  But
it might be nice if we in fact standardized on this.  Ideally of course
it would be part of a real error (condition) system, though, and it's
possible that that would in turn depend on having fluid variables... I
wouldn't hold my breath...

Jonathan

∂13-Nov-86  0752	@MC.LCS.MIT.EDU:sieber-john@YALE.ARPA 	Add me to the list   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Nov 86  07:52:10 PST
Received: from yale-celray.YALE.ARPA (TCP 20011000031) by MC.LCS.MIT.EDU 13 Nov 86 10:48:14 EST
Received: by yale-celray.YALE.ARPA; Thu, 13 Nov 86 10:04:58 est
Date: Thu, 13 Nov 86 10:04:58 est
From: sieber-john@YALE.ARPA
Message-Id: <8611131504.AA00353@yale-celray.YALE.ARPA>
Subject: Add me to the list
To: scheme@mc.lcs.mit.edu

Would you please add me to the Scheme discussion?  I was an undergraduate
at Oberlin College where I was infected with the Scheme bug (flavored 
heavily by Indiana U. and the Dan Friedman school).

Thanks,

Jack Sieber
sieber@yale.arpa

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


∂15-Nov-86  1839	@MC.LCS.MIT.EDU:reddy@a.cs.uiuc.edu 	make-environment  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 86  18:39:12 PST
Received: from a.cs.uiuc.edu (TCP 1200600045) by MC.LCS.MIT.EDU 15 Nov 86 21:33:07 EST
Received: by a.cs.uiuc.edu (UIUC-5.44/9.7),
	id AA10732; Sat, 15 Nov 86 20:33:52 CST
Date: Sat, 15 Nov 86 20:33:52 CST
From: reddy@a.cs.uiuc.edu (Uday S. Reddy)
Message-Id: <8611160233.AA10732@a.cs.uiuc.edu>
To: scheme@mit-mc.arpa
Subject: make-environment

I don't know if this is the right forum to raise this issue.  But, I wonder
why make-environment works the way it does.  If I define
	(define (complex x y)
            (make-environment
		(define re x)
		(define im y)))
	(define a (complex 1 2))
not only does a have re and im bound in it, but it also has x and y
bound in it.  So,
	(access x a)
yields 1.  From the description of make-environment in Abelson and Sussman,
it appears that only re and im should be bound in a.  Is this a bug, or a
feature, or am I missing something?  If this is the way make-environment
is supposed to work, is there some other primitive that binds re and im
and forgets about x and y?

Uday Reddy

∂15-Nov-86  1913	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@RELAY.CS.NET 	question: S&ICP teacher's manual and query language   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 86  19:13:14 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Nov 86 22:04:10 EST
Received: from ubc by csnet-relay.csnet id aa00818; 15 Nov 86 14:27 EST
Date: Sat, 15 Nov 86 10:36:41 pst
Received: by ubc.csnet id AA24378; Sat, 15 Nov 86 10:36:41 pst
From: "Daniel K. Schneider" <shneider%cui.unige.chunet%ubc.csnet@RELAY.CS.NET>
To: scheme@MC.LCS.MIT.EDU
MMDF-Warning:  Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <153:shneider@cui.unige.chunet>
Subject: question: S&ICP teacher's manual and query language

1) We set up group here, disscussing the "structure and interpretation" book
   and we'd like to use it for teaching eventually.
   
   Where could I get the teacher's manual ?
   (Sorry, if this question has been asked before already)

2) I'd also like to obtain the updated version of the query langauge.
   I heard that I might get it from GJS, but I don't know his name
   and net address. Anybody does ?

BIG thanks for any help !



∂15-Nov-86  1951	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet%ubc.csnet@RELAY.CS.NET 	question: S&ICP teacher's manual and query language   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Nov 86  19:45:29 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 15 Nov 86 22:04:55 EST
Received: from ubc by csnet-relay.csnet id ab00818; 15 Nov 86 14:29 EST
Date: Sat, 15 Nov 86 10:37:10 pst
Received: by ubc.csnet id AA24381; Sat, 15 Nov 86 10:37:10 pst
From: "Daniel K. Schneider" <shneider%cui.unige.chunet%ubc.csnet@RELAY.CS.NET>
To: scheme@MC.LCS.MIT.EDU
MMDF-Warning:  Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <156:shneider@cui.unige.chunet>
Subject: question: S&ICP teacher's manual and query language

1) We set up group here, disscussing the "structure and interpretation" book
   and we'd like to use it for teaching eventually.
   
   Where could I get the teacher's manual ?
   (Sorry, if this question has been asked before already)

2) I'd also like to obtain the updated version of the query langauge.
   I heard that I might get it from GJS, but I don't know his name
   and net address. Anybody does ?

BIG thanks for any help !

-------------------------------------------------------------------------------
Daniel K.Schneider
Departement de science politique, Universite de Geneve
1211 GENEVE 4 (Switzerland), Tel. (..41) (22) 20 93 33 ext. 2357

          to VMS/BITNET:                    to UNIX/EAN (preferable):
BITNET:   SCHNEIDER@CGEUGE51                shneider%cui.unige.chunet@CERNVAX
ARPA:     SCHNEIDER%CGEUGE51.BITNET@WISCVM  shneider%cui.unige.chunet@ubc.CSNET
uucp:                                       mcvax!cernvax!cui!shneider   
X.400/ean:                                  shneider@cui.unige.chunet




∂16-Nov-86  1021	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	make-environment (long)  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Nov 86  10:21:21 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 16 Nov 86 13:16:43 EST
Received: by GENEVA.AI.MIT.EDU; Sun, 16 Nov 86 13:13:36 est
Date: Sun, 16 Nov 86 13:13:36 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8611161813.AA03965@geneva>
To: reddy@a.cs.uiuc.edu
Cc: scheme@mit-mc.arpa
In-Reply-To: Uday S. Reddy's message of Sat, 15 Nov 86 20:33:52 CST
Subject: make-environment (long)

    I don't know if this is the right forum to raise this issue.  But, I wonder
    why make-environment works the way it does.  If I define
	    (define (complex x y)
		(make-environment
		    (define re x)
		    (define im y)))
	    (define a (complex 1 2))
    not only does a have re and im bound in it, but it also has x and y
    bound in it.  So,
	    (access x a)
    yields 1.  From the description of make-environment in Abelson and Sussman,
    it appears that only re and im should be bound in a.  Is this a bug, or a
    feature, or am I missing something?  If this is the way make-environment
    is supposed to work, is there some other primitive that binds re and im
    and forgets about x and y?

You have misunderstood section 4.3.1 of S&ICP.  If you read it
carefully, you will notice

"For use in conjunction with EVAL, Scheme provides an operation called
MAKE-ENVIRONMENT that constructs an environment, evaluates a
designated sequence of expressions within this environment, and
returns the environment as the value of the MAKE-ENVIRONMENT
expression.  The enclosing environment of the new environment is the
environment in which the MAKE-ENVIRONMENT expression was evaluated."

The last sentence in the above quote makes it quite clear that this
environment is built on top of the one in which the MAKE-ENVIRONMENT
expression was evaluated, and therefore all these names are visible to
EVAL.

You ask about ACCESS, which is not in S&ICP, so I assume you are
talking about MIT Scheme instead of the restricted subset used in
S&ICP.

There are two possibilities for ACCESS:

  Make it compatible with EVAL, and therefore make all the names (like X
  and Y in your example) visible.  This is the current implementation.

  Make ACCESS look only at the "topmost" frame of the environment.  This
  means that all the names that can be exported from a package must be
  defined in that package itself, and there is no "export" inheritance
  between packages built on top of packages.  

We tried the latter approach for a while and it was a total mess.  We
quickly changed it to its alternative.


∂18-Nov-86  0915	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Scheme reports information request 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 86  09:15:37 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 NOV 86  12:12:03 EST
Date: Tue, 18 Nov 86 12:14:33 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Scheme reports information request
To: prlb2!vauclair@SEISMO.CSS.GOV
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of 18 Nov 86 10:50:34 N (Tue) from Marc Vauclair <prlb2!vauclair at seismo.CSS.GOV>
Message-ID: <[AI.AI.MIT.EDU].119770.861118.JAR>

    Date: 18 Nov 86 10:50:34 N (Tue)
    From: Marc Vauclair <prlb2!vauclair at seismo.CSS.GOV>

    	In the "Revised Revised Report on Scheme", I found the following
    two little sentences:

    on page 5:

    	"Formal definitions of the lexical and context-free syntaxes of Scheme
    	will be included in a separate report."

    on page 7:

    	"A formal definition of the semantics of Scheme will be included in a
    	separate report."

    Does those reports exist?  Maybe using the same procedure as for the
    Revised↑3 Report ?

The "separate report" alluded to actually IS section 7 of the Revised↑3
Report.  So the answers are yes and yes, identically.

Jonathan

∂22-Nov-86  1845	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	truncate  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86  18:45:14 PST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 22 NOV 86  21:43:38 EST
Date: Sat, 22 Nov 86 21:43:12 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  truncate
To: philbin-jim@YALE.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <122229.861122.JAR@AI.AI.MIT.EDU>

    Date: 22 Nov 86 11:23:34 EST (Sat)
    From: James F Philbin <philbin-jim at YALE.ARPA>
    To:   Rees at YALE.ARPA
    Re:   truncate

    The definition of TRUNCATE in R3RS, p 20., seems ambiguous.

	TRUNCATE returns the integer of maximal absolute
	value not larger than the absolute value of x.

    In the case of -1.1, for example, both 1 and -1 are of maximal
    absolute value not larger than the absolute value of -1.1.
    I suggest adding the phrase,

       ... with the same sign as x.

Right.

∂25-Nov-86  1315	@MC.LCS.MIT.EDU:camp%home%ti-csl.csnet@RELAY.CS.NET 	PC Scheme Utilities   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Nov 86  13:12:00 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 25 Nov 86 16:04:51 EST
Received: from ti-csl by csnet-relay.csnet id ae04601; 25 Nov 86 15:43 EST
Received: from  (home.ARPA) by tilde id AA24272; Tue, 25 Nov 86 14:05:13 cst
Received: by  id AA13329; Tue, 25 Nov 86 14:04:35 cst
Date: Tue, 25 Nov 86 14:04:35 cst
From: Clyde Camp <camp%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8611252004.AA13329@>
To: SCHEME@MC.LCS.MIT.EDU
Subject: PC Scheme Utilities



For those of you interested in PCS, a set of free utilities with
documentation is available from:

        Clyde R. Camp
        Texas Instruments, Inc.
        P.O.Box 226015, MS 238
        Dallas, TX  75266

Send two blank, FORMATTED disks and a self-addressed, stamped envelope.
Although written primarily for the TIPC, everything except the
graphics should work on and of the IBM clones.  The directories are:


UTILITY - Various text windowing, file printing and keyboard handlers
which simplify writing application programs (includes a file
pretty-printer and a new top-level read-eval-print loop which uses an
emacs-like line-editor with the capability to scroll back through
previous entries)
 
SWI - A convenient mechanism for invoking 8086 ASSY routines via the
rather undocumented SWI-INT.

HELP - A user-extendable on-line help facility which includes all of
the PCS functions and syntax as well as other info

GRAF - A object-style graphics package

PLOT - A general prupose function plotter

GAME1 - Self explanatory - non-graphics
GAME2 - for TIPC graphics

ERR←STAT - more utilities for messing with the status window

MENUSHEL - two menu driven command shells


This should also be available in ARC'd format on COMPUSERVE in the
near future.

- Clyde



∂03-Dec-86  1055	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Scheme redistribution for BITNET   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 86  10:55:01 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU  3 Dec 86 13:12:32 EST
Date: Wed,  3 Dec 86 13:12:30 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Scheme redistribution for BITNET
To: scheme@MC.LCS.MIT.EDU
Message-ID: <125886.861203.JAR@AI.AI.MIT.EDU>


I'm looking for someone on BITNET to volunteer to maintain a BITNET
redistribution list for the Scheme@MC mailing list.  This is necessary
because	the machine that's acting as the Internet/BITNET gateway,
WISCVM.WISC.EDU, is swamped with mailing list mail.  List administrators
(like me) are being asked to set up redistribution lists to help lighten
the load.  If we can set one up for Scheme then WISCVM will only have to
relay each message to one host instead of the current 11 or 12 (more in
future).

If you're willing and able to take this on, please let me know.
Thanks...

- Jonathan


∂08-Dec-86  0049	@MC.LCS.MIT.EDU:CPH@AI.AI.MIT.EDU 	Ambiguity in number syntax    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 86  00:49:07 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU  8 Dec 86 03:49:17 EST
Date: Mon,  8 Dec 86 03:47:50 EST
From: Chris Hanson <CPH@AI.AI.MIT.EDU>
Subject:  Ambiguity in number syntax
To: GJS@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU
cc: RRRS-AUTHORS@MC.LCS.MIT.EDU
Message-ID: <127818.861208.CPH@AI.AI.MIT.EDU>

I was trying to implement a parser for the full number syntax in R3RS
and noticed that

#x1234e57

is ambiguous.  Does it mean

(* #x1234 (expt 10 57))

or

19091031

Some solutions:

1. Flush scientific notation for hexadecimal numbers.  Does anybody
really want to write real numbers (as opposed to integers or
rationals) in hexadecimal?

2. Require an explicit sign character in the exponent for such
numbers.  Thus we would say

#x1234e+57

which is unambiguous.

I favor solution (2) since it leaves the syntax as general as
possible.


∂08-Dec-86  0835	@MC.LCS.MIT.EDU:muller@BU-CS.BU.EDU 	IBM PC Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 86  08:35:11 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU  8 Dec 86 11:30:53 EST
Received: from bu-cs.bu.edu by RELAY.CS.NET id aa00472; 8 Dec 86 11:03 EST
Return-Path: <muller>
Received: by bu-cs.bu.edu (5.31/4.7)
	id AA14034; Sun, 7 Dec 86 08:41:05 EST
Date: Sun, 7 Dec 86 08:41:05 EST
From: Robert Muller <muller@BU-CS.BU.EDU>
Message-Id: <8612071341.AA14034@bu-cs.bu.edu>
To: scheme@MC.LCS.MIT.EDU
Subject: IBM PC Scheme


Does anyone know where I can pickup a version of Scheme that runs
on the IBM PC (XT w only 256k)?

thanks,

  - Bob Muller

∂08-Dec-86  0934	@MC.LCS.MIT.EDU:HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	IBM PC Scheme  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 86  09:34:10 PST
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 DEC 86  12:06:32 EST
Date: Mon, 8 Dec 1986  12:06 EST
Message-ID: <HAL.12261186063.BABYL@MIT-OZ>
From: HAL%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To:   Robert Muller <muller@BU-CS.BU.EDU>
Cc:   scheme@MC.LCS.MIT.EDU
Subject: IBM PC Scheme
In-reply-to: Msg of 7 Dec 1986  08:41-EST from Robert Muller <muller at BU-CS.BU.EDU>


Texas instrument's PC scheme runs (barely) in 256K, but you can't
use the editor.

∂08-Dec-86  1016	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	Ambiguity in number syntax    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 86  10:16:39 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU  8 Dec 86 13:03:21 EST
Received: by GENEVA.AI.MIT.EDU; Mon, 8 Dec 86 12:51:20 est
Date: Mon, 8 Dec 86 12:51:20 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8612081751.AA02460@geneva>
To: CPH@AI.AI.MIT.EDU
Cc: GJS@AI.AI.MIT.EDU, JAR@AI.AI.MIT.EDU, RRRS-AUTHORS@MC.LCS.MIT.EDU
In-Reply-To: Chris Hanson's message of Mon,  8 Dec 86 03:47:50 EST
Subject: Ambiguity in number syntax

There is yet another possibility, which is the one I like best:

#x1234e57

means

(* #x1234 (expt #x10 #x57))

∂09-Dec-86  0812	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	(define foo)   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 86  08:12:11 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU  9 Dec 86 11:11:32 EST
Date: Tue,  9 Dec 86 11:10:05 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  (define foo)
To: andy@ADS.ARPA
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Sun 7 Dec 86 22:56:01 PST from andy at hobbes.ads.ARPA (Andy Cromarty)
Message-ID: <128392.861209.JAR@AI.AI.MIT.EDU>

    Date: Sun, 7 Dec 86 22:56:01 PST
    From: andy at hobbes.ads.ARPA (Andy Cromarty)

    A lot of MIT code (among other software) seems to contain the cliche'

    (define foo)				; Create an unbound instance of FOO
    (let ((some-lexical-var 'x))		; Create a closure....
          (set! foo (lambda () 		; Define outer FOO to reference
    		:			;  vars visible only in this lexenv.
    		:
    		)))

    This does not seem to be permitted, even optionally, by the existing R3RS,
    as far as I've noticed.  Did I miss something, or is it intentional that
    (DEFINE FOO) is not permitted, or was it an oversight?  I don't recall
    having seen discussion of this topic.

If you missed something then I did too.  I have no recollection of this
being discussed.

In trying to write portable Scheme code (it's difficult) I find myself
saying things like (define foo 'undefined) pretty often.  I don't find
this to be a major inconvenience, but it is an inconvenience.  I don't
see any serious problem with the (define foo) construct.  It would
presumably mean the same thing as (define foo <undefined>) where
<undefined> is that mysterious expression described in the discussion of
LETREC in section 7.3.  A correct immplementation of <undefined> would
of course be 'undefined (or just about anything else), the only
disadvantage of which is that it allow certain error situations to go
undetected.

For symmetry you'd want the syntax to be allowed for both internal
define's and top-level define's.  For this to work you'd have to apply the
(define foo) => (define foo <undefined>) rewrite before applying the
define => letrec rewrite.

This feature is implicitly permitted "optionally", because it is a
compatible extension.

Jonathan


∂17-Dec-86  0712	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	What is comma-dot? 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 86  07:12:43 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 17 Dec 86 10:11:42 EST
Received: from ti-csl by csnet-relay.csnet id ah05539; 17 Dec 86 9:36 EST
Received: from  (home.ARPA) by tilde id AA06413; Tue, 16 Dec 86 13:40:14 cst
Received: by  id AA01741; Tue, 16 Dec 86 13:39:29 cst
Date: Tue, 16 Dec 86 13:39:29 cst
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8612161939.AA01741@>
To: RRRS-Authors@MC.LCS.MIT.EDU
Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET
Subject: What is comma-dot?

Can those of us that permit the destructive splicing operation `,.'
inside quasiquote agree on the symbol it corresponds to?  That is, if
,@X is equivalent to (unquote-splicing X), what is ,.X equivalent to?
Perhaps a future R↑nRS should mention this as an extension.


∂31-Dec-86  1100	@MC.LCS.MIT.EDU:NETWORK%FRSAC11.BITNET@WISCVM.WISC.EDU 	SCOOPS   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 86  11:00:00 PST
Received: from WISCVM.WISC.EDU (TCP 20032201015) by MC.LCS.MIT.EDU 31 Dec 86 13:37:15 EST
Received: from (NETWORK)FRSAC11.BITNET by WISCVM.WISC.EDU on 12/30/86
  at 14:48:44 CST
Date: Tue, 30 Dec 86 19:30:47 ZONE
To:  SCHEME@MC.LCS.MIT.EDU
From:  NETWORK%FRSAC11.BITNET@WISCVM.WISC.EDU
Subject:  SCOOPS

NETWORK  at FRSAC11
To:   SCHEME   at MC.LCS.M
I just got PC-SCOOPS, (by FTP, courtesy of TI), but I do not run PC-Scheme
but CScheme.... Anybody can help ? (In CScheme there is the rrrs compatibility
package... never tried it, but should be good.)

Sincerly,

        +--------------------------------------------------+
        | Jean-Pierre H. Dumas                             |
        | Cisi-Telematique                                 |
        | CEN Saclay, BP 24                                |
        | 91190 Gif sur Yvette                             |
        | France                                           |
        |                                                  |
        | Phone: +33 (1) 69 08 46 87                       |
        |                                                  |
        | network@frsac11 (bitnet)                         |
        | network%frsac11.bitnet@wiscvm.wisc.edu (arpanet) |
        | ..!ihnp4!frsac11.bitnet!network (usenet ?)       |
        | dumas@sumex-aim.stanford.edu (arpanet)           |
        +--------------------------------------------------+

∂31-Dec-86  1319	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	What is comma-dot?  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 86  13:19:46 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Dec 86 15:59:23 EST
Date: Wed, 31 Dec 86 16:01:03 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  What is comma-dot?
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 16 Dec 86 13:39:29 cst from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <135327.861231.JAR@AI.AI.MIT.EDU>

    Date: Tue, 16 Dec 86 13:39:29 cst
    From: David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
    To:   RRRS-Authors at MC.LCS.MIT.EDU
    cc:   Bartley%home%ti-csl.csnet at RELAY.CS.NET
    Re:   What is comma-dot?
    Message-Id: <8612161939.AA01741@>

    Can those of us that permit the destructive splicing operation `,.'
    inside quasiquote agree on the symbol it corresponds to?  That is, if
    ,@X is equivalent to (unquote-splicing X), what is ,.X equivalent to?
    Perhaps a future R↑nRS should mention this as an extension.

I think this feature is a kludge; I presume you have Common Lisp in
mind.  How about "UNQUOTE-SPLICING!" ?

Jonathan


∂31-Dec-86  1333	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[COMSAT: Msg of Monday, 22 December 1986 16:31-EST]    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 86  13:33:28 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Dec 86 15:59:42 EST
Date: Wed, 31 Dec 86 16:01:47 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  [COMSAT: Msg of Monday, 22 December 1986 16:31-EST]
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <135329.861231.JAR@AI.AI.MIT.EDU>

Date: Thu, 25 Dec 86 21:08:55 EST
From: Communications Satellite <COMSAT at AI.AI.MIT.EDU>
To:   JAR at AI.AI.MIT.EDU
Re:   Msg of Monday, 22 December 1986 16:31-EST
Message-ID: <134306.861225@AI.AI.MIT.EDU>

FAILED: rrrs-authors at MC.LCS.MIT.EDU; Host appears to be permanently down or not accepting mail.
 Failed message follows:
-------
Date: Mon, 22 Dec 86 16:31:02 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  New, improved quasiquote
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 17 Dec 86 16:40:28 cst from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <133673.861222.JAR@AI.AI.MIT.EDU>

    Date: Wed, 17 Dec 86 16:40:28 cst
    From: David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>

    You mailed out a copy of your expand-quasiquote procedure at my
    request 13 months ago.  Do you have an updated version you could be
    persuaded to make public?  We never switched over to your algorithm,
    but the recent changes to the specification mean we have to rewrite
    our quasiquote handler anyway, so it would be nice to continue our
    grand tradition of "borrowing" from university sources!

I have several versions.  Here is one from which I have removed several
different optimizations.  I did this in an attempt to make the code as
simple as possible, without sacrificing too much efficiency.  Simpler
versions are possible, as are more optimal ones.  E.g. this one won't
generate (vector ...) or (list ...), but it does do maximal sharing of
constant substructure.

You can do (define (system x) x) to get this to work, although in the
Scheme implementation from which this was taken I actually make this
return a funny expression which is an absolute reference to x, so that
things like (let ((cons +)) `(,a b)) works.

- Jonathan

;;; Quasiquote

(define-rewriter 'quasiquote
  (lambda (x)
    (expand-quasiquote x 0)))

(define (expand-quasiquote x level)
  (descend-quasiquote x level finalize-quasiquote))

(define (finalize-quasiquote mode arg)
  (cond ((eq? mode 'quote) `',arg)
	((eq? mode 'unquote) arg)
	((eq? mode 'unquote-splicing)
	 (error ",@ in illegal context" arg))
	(else `(,mode ,@arg))))

(define (descend-quasiquote x level return)
  (cond ((vector? x)
	 (descend-quasiquote-vector x level return))
	((not (pair? x))
	 (return 'quote x))
	((interesting-to-quasiquote? x 'quasiquote)
	 (descend-quasiquote-pair x (1+ level) return))
	((interesting-to-quasiquote? x 'unquote)
	 (cond ((= level 0)
		(return 'unquote (cadr x)))
	       (else
		(descend-quasiquote-pair x (- level 1) return))))
	((interesting-to-quasiquote? x 'unquote-splicing)
	 (cond ((= level 0)
		(return 'unquote-splicing (cadr x)))
	       (else
		(descend-quasiquote-pair x (- level 1) return))))
        (else
	 (descend-quasiquote-pair x level return))))

(define (descend-quasiquote-pair x level return)
  (descend-quasiquote (car x) level
    (lambda (car-mode car-arg)
      (descend-quasiquote (cdr x) level
        (lambda (cdr-mode cdr-arg)
	  (cond ((and (eq? car-mode 'quote) (eq? cdr-mode 'quote))
		 (return 'quote x))
		((eq? car-mode 'unquote-splicing)
		 ;; (,@mumble ...)
		 (cond ((and (eq? cdr-mode 'quote) (null? cdr-arg))
			(return 'unquote
				car-arg))
		       (else
			(return (system 'append)
				(list car-arg (finalize-quasiquote cdr-mode cdr-arg))))))
		(else
		 (return (system 'cons)
			 (list (finalize-quasiquote car-mode car-arg)
			       (finalize-quasiquote cdr-mode cdr-arg))))))))))

(define (descend-quasiquote-vector x level return)
  (descend-quasiquote (vector->list x) level
    (lambda (mode arg)
      (case mode
	((quote) (return 'quote x))
	(else (return (system 'list->vector)
		      (list (finalize-quasiquote mode arg))))))))

(define (interesting-to-quasiquote? x marker)
  (and (pair? x) (eq? (car x) marker)))


∂05-Jan-87  0803	@MC.LCS.MIT.EDU:NETWORK%FRSAC11.BITNET@WISCVM.WISC.EDU 	SYMBOLIC COMPUTATION.   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87  08:03:49 PST
Received: from WISCVM.WISC.EDU (TCP 20032201015) by MC.LCS.MIT.EDU  5 Jan 87 10:57:12 EST
Received: from (NETWORK)FRSAC11.BITNET by WISCVM.WISC.EDU on 01/05/87
  at 09:57:19 CST
Date: Wed, 31 Dec 86 16:27:48 ZONE
To:  SCHEME@MC.LCS.MIT.EDU
From:  NETWORK%FRSAC11.BITNET@WISCVM.WISC.EDU
Subject:  SYMBOLIC COMPUTATION.

NETWORK  at FRSAC11
To:   SCHEME   at MC.LCS.M
Does anybody know about a Scheme package to do symbolic computation ??
(a la  Reduce, Macsyma...)
P.S. I run CScheme on UTS/V.

Happy new year.

        +--------------------------------------------------+
        | Jean-Pierre H. Dumas                             |
        | Cisi-Telematique                                 |
        | CEN Saclay, BP 24                                |
        | 91190 Gif sur Yvette                             |
        | France                                           |
        |                                                  |
        | Phone: +33 (1) 69 08 46 87                       |
        |                                                  |
        | network@frsac11 (bitnet)                         |
        | network%frsac11.bitnet@wiscvm.wisc.edu (arpanet) |
        | ..!ihnp4!frsac11.bitnet!network (usenet ?)       ∀
        | dumas@sumex-aim.stanford.edu (arpanet)           |
        +--------------------------------------------------+

∂05-Jan-87  2047	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	Re: What is comma-dot?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87  20:46:48 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU  5 Jan 87 23:44:13 EST
Received: from tektronix.tek.com by csnet-relay.csnet id aa06713;
          5 Jan 87 18:44 EST
Received: by tektronix.TEK.COM (5.31/6.18)
	id AA10436; Mon, 5 Jan 87 12:57:18 PST
Received: by tekchips.TEK (5.31/6.16)
	id AA06076; Mon, 5 Jan 87 12:58:16 PST
Message-Id: <8701052058.AA06076@tekchips.TEK>
To: JAR@AI.AI.MIT.EDU, bartley%home%ti-csl.csnet@RELAY.CS.NET
Cc: adams%tekchips.tek.com@RELAY.CS.NET, rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: What is comma-dot?
In-Reply-To: Your message of Wed, 31 Dec 86 16:01:03 EST.
	     <135327.861231.JAR@AI.AI.MIT.EDU>
Date: 05 Jan 87 12:58:13 PST (Mon)
From: willc%tekchips.tek.com@RELAY.CS.NET

Just as standardization can be a destructive force, by encouraging the use
of standardized but doubtful features, so can lack of standardization be a
creative force, by discouraging use of non-standardized doubtful features.
I consider comma-dot an excellent candidate for non-standardization.

Will

∂06-Jan-87  0824	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	What is comma-dot? 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87  08:24:41 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU  6 Jan 87 11:21:14 EST
Received: from ti-csl by csnet-relay.csnet id ab01368; 6 Jan 87 10:22 EST
Received: from  (home.ARPA) by tilde id AA09833; Tue, 6 Jan 87 08:46:02 cst
Received: by  id AA20269; Tue, 6 Jan 87 08:46:09 cst
Date: Tue, 6 Jan 87 08:46:09 cst
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8701061446.AA20269@>
To: RRRS-Authors@MC.LCS.MIT.EDU
Subject: What is comma-dot?

> From: David Bartley <bartley@home>
>
> Can those of us that permit the destructive splicing operation `,.'
> inside quasiquote agree on the symbol it corresponds to?  That is, if
> ,@X is equivalent to (unquote-splicing X), what is ,.X equivalent to?
> Perhaps a future R↑nRS should mention this as an extension.

> From: willc@tekchips.tek.com
>
>Just as standardization can be a destructive force, by encouraging the use
>of standardized but doubtful features, so can lack of standardization be a
>creative force, by discouraging use of non-standardized doubtful features.
>I consider comma-dot an excellent candidate for non-standardization.

Will seems to have stated the consensus, if the other replies to my
original message are representative.  I will adopt JAR's suggested
name, UNQUOTE-SPLICING!, but agree that this is a "doubtful" feature
and that standardization isn't called for.


∂10-Jan-87  1130	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	2nd test  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Jan 87  11:30:03 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 10 Jan 87 14:12:22 EST
Date: Sat, 10 Jan 87 14:15:10 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  2nd test
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <138728.870110.JAR@AI.AI.MIT.EDU>


This is a second test message for today, which everyone should feel at
liberty to ignore.


∂16-Jan-87  0850	@MC.LCS.MIT.EDU:dfried%iuvax.cs.indiana.edu@RELAY.CS.NET 	multiple values and T 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87  08:50:06 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 16 Jan 87 11:45:30 EST
Received: from indiana by csnet-relay.csnet id ac26709; 16 Jan 87 11:32 EST
Date: Fri, 16 Jan 87 09:56:21 est
From: Dan Friedman <dfried%iuvax.cs.indiana.edu@RELAY.CS.NET>
To: rrrs-authors%mit-mc.CSNET@RELAY.CS.NET
Subject: multiple values and T

Here is the material taken from "T Version 3.0 Release Notes" concerning
multiple return values.  Following this material will be a short example
which demonstrates how this could be made more general.

Version 3.0 of T supports multiple return values.  This makes procedure
call and return uniform, in te sense that a procedure can be invoked with
zero or more values and can return zero or more values.

   (return {value}*) ==> {value}*                            procedure

return returns its arguments as the values(s) of the current expression.
In order to access the value(s) of a return expression the value(s) must be
bound to identifiers using either receive or receive-values.

For example,

   ((lambda () (return 1 2 3))) ==> 1 2 3

where "==> 1 2 3" denotes evaluates to the three values 1, 2, and 3.

return when invoked with no arguments returns to the calling procedure with
no value.  Thus (return) will return to its caller with no value.  It is an
error to return no value to a value requiring poisition.  For example,

   (list 'a (return)) ==> error

The idiom (return) is useful for procedures that return an undefined value and
many of the system procedures whose value(s) is(are) undefined now return no
value.  However, the procedure undefined-value may provide a more informative
error message.

   (receive-values receiver sender)                          procedure
      ==> value(s) of receiver

receive-values returns the value of applying receiver, a procedure of n
arguments, to the values returned by sender.  sender is a thunk, a procedure
of no arguments, which returns n values.

For example,

   (receive-values (lambda (x y) (list x y))
                   (lambda () (return 1 2)))  ==> (1 2)

   (receive ({ident}*) expression {body}*)                  syntax
      ==> value of body

In a receive form the expression is evaluated in the current environment
and the values returned by the expression are bound to the corresponding
identifiers.  body, which should be a lambda body, i.e. a sequence of one
or more expressions, is evaluated in the extended environment and the
value(s) of the last expression in body is returned.

The expression

   (receive (a b c) (return 1 2 3)
      (list a b c))
      ==>   (1 2 3)

is equivalent to

   (receive-values (lambda (a b c) (list a b c))
                   (lambda () (return 1 2 3)))
      ==>  (1 2 3)

Other froms have been extended in T3.0 to allow multiple return values.

   (catch identifier {body}*)  ==> value of body            syntax

The identifier is bound to the continuation of the catch form, which is now
an n-ary procedure.  This means that catch forms can return multiple values.
The continuation can be invoked only during the dynamic extent of the catch
form.  In T2 the continuation was a procedure of one argument.  For example,

   (catch x (list 1 (x 2 3) 4)) ==> 2 3

   (ret {value}*) ==> {value}*                              procedure

returns zero or more values as the value of the current read-eval-print loop.

Note:  Multiple values are implemented efficiently.  It may be more efficient
       to use multiple values than to pass continuations.
                                          
End of disccusion from the Relases Notes.

What disturbs me is the way that it does not seem to be as general as it
could be.  What I would like to propose is the ability to splice in return
values.  Here is an example:

   ((lambda (a b c q x y) ...)
    (return 1 2 3) 4 (return 5 6)).

It is possible that this capability is exactly what T Version 3.0 does.
However, there were no examples of this type so I believe this has been
overlooked.

I know that when we met in Cambridge Jonathan offered to work on multiple
values.  This is something for all of us to consider.

Dan


∂16-Jan-87  1400	@MC.LCS.MIT.EDU:hudak-paul@YALE.ARPA 	Re: multiple values and T  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87  13:59:53 PST
Received: from yale-eli.YALE.ARPA (TCP 20011000001) by MC.LCS.MIT.EDU 16 Jan 87 16:59:39 EST
Received: by yale-eli.YALE.ARPA; Fri, 16 Jan 87 16:22:37 est
Date: Fri, 16 Jan 87 16:22:37 est
From: Paul Hudak <hudak-paul@YALE.ARPA>
Message-Id: <8701162122.AA06172@yale-eli.YALE.ARPA>
Received: by yale-ring (node-add2.ring.cs.yale.edu/ADD2) 
          via WIMP-MAIL (Version 1.2/1.4) ; Fri Jan 16 16:19:37
Subject: Re: multiple values and T
To: Dan Friedman <dfried%iuvax.cs.indiana.edu@RELAY.CS.NET>
Cc: rrrs-authors@mc.lcs.mit.edu
In-Reply-To: Dan Friedman <dfried%iuvax.cs.indiana.edu@RELAY.CS.NET>, Fri, 16 Jan 87 09:56:21 est

    ...
    End of disccusion from the Relases Notes.
    
    What disturbs me is the way that it does not seem to be as general as it
    could be.  What I would like to propose is the ability to splice in return
    values.  Here is an example:
    
       ((lambda (a b c q x y) ...)
        (return 1 2 3) 4 (return 5 6)).
    
    It is possible that this capability is exactly what T Version 3.0 does.
    However, there were no examples of this type so I believe this has been
    overlooked.
    
No, T does not do this (by design).  The problem is that it's not always
obvious what the bindings are.  For example, replace the above two
occurrences of RETURN with calls to unknown procedures:

       ((lambda (a b c q x y) ...)
        (f) 4 (g))

The problem with this is that one cannot tell, looking at this code alone, 
which bound variable 4 is bound to.  Indeed, different invocations of this
may induce different bindings, depending on the bindings of f and g!  This
seems to us to violate one's notion of referential transparency.

    Paul Hudak
    David Kranz
    Richard Kelsey
-------



∂16-Jan-87  1645	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87  16:45:24 PST
Received: from ZERMATT.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 16 JAN 87  19:45:15 EST
Received: from ROCKY-GRAZIANO.LCS.MIT.EDU by ZERMATT.LCS.MIT.EDU via CHAOS with CHAOS-MAIL id 24803; Fri 16-Jan-87 19:45:02 EST
Date: Fri, 16 Jan 87 19:45 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: multiple values
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <870116194506.1.JAR@ROCKY-GRAZIANO.LCS.MIT.EDU>


Maybe some of you missed or have forgotten the relevant discussion last
October and November, so here's a digest.  If you remember this stuff,
you needn't examine this message any further, and I apologize for
cluttering your mailboxes.

The mechanism in T3 is essentially the same as that presented in my
message of Thu, 30 Oct 86 22:08:03 EST.  That message also includes some
motivation, which I won't repeat here, and Dan has already sent out the
technical content.  The rather important detail ommitted from the T3
release notes is that it's an error whenever the number of values
expected doesn't match the number delivered, and argument and predicate
positions expect exactly one value.  Thus (list (return 1 2)) is an
error in T3 and in my proposal.

The mechanism that Dan Friedman proposes was suggested on this list by
Andy Freeman:

    Date: Thu 30 Oct 86 12:25:22-PST
    From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
    
    This proposal is a variant on the technique Carolyn Talcott used
    in her thesis; Richard Weyrauch was also involved in that work.
    
    Their idea requires one procedure; I'll call it values.  Procedure
    invocation spreads multiple values; (cons (values 1 2)) is completely
    equivalent to (cons 1 2) and (list (values) 4 (values 1 2) 3) is
    equivalent to (list 4 1 2 3). ...

It was dismissed by the only people on the list (besides maybe Sussman)
who had actual experience using it, namely Steele and Gabriel:

    Date: Mon, 3 Nov 86 11:24 EST
    From: Guy Steele <gls@Think.COM>
    
    It [MARVEL] did pretty much all the obvious things: every function
    call was implicitly like the Common Lisp MULTIPLE-VALUE-CALL, and
    most side-effecting forms such as SETQ, PRINT, and COMMENT were made
    to return zero values.  I believe I also arranged for variables to
    be able to hold multiple values.
    
    My experience with the language was that it was perfectly clean
    and elegant, but programs that made non-trivial use of multiple
    values were very hard to read, precisely because of the loss
    of the one-form/one-value correspondence.  Having the extra power
    everywhere in the language was not worth the loss of clarity.
    I therefore abandoned the experiment without writing it up.
    (Maybe I should have, but there were other, more promising variations
    of Scheme to explore.)
    ...
    I believe that experience with the POP languages (especially POP-2)
    may be relevant to this discussion, but I am not an expert there.
    

    Date: 03 Nov 86  1214 PST
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
    ...    
    The code, as Steele mentions, was elegant in a certain sense, but
    very hard to read most of the time, because you had to take into
    account that some other values than the primary value (the first
    one) would be passed to some program.  The places where SEUS code
    was easy to read were when you were writing something that, in
    Common Lisp, would be
    
    (multiple-value-call #'foo (baz) (bar))
    
    The places where it was hard to read were when you were writing something
    that, in Common Lisp, would be
    
    (foo (baz) (bar))
    
    That is, there was no easy way to check that the right values from the
    right places got passed. I think that the latter is the more commonly
    used case, so SEUS was optimized the wrong way.
    ...
    When the Common Lisp multiple value scheme was being devised, I thought
    that we (the designers) should look at SEUS for its experience. I'm now
    glad we didn't do anything more that invent MULTIPLE-VALUE-CALL as a
    result of that experience.

I tend to agree that it's a bad idea, not only from the point of view of
someone using it, but also for implementation reasons: unlike the T
proposal, which is trivially implementable (VALUES = LIST) in any scheme
implementation, it's grossly incompatible with current implementations;
and it has a performance cost that you have to always pay for, even when
you're not using the feature, because all calls to unknown procedures
must be prepared to splice in an arbitrary amount of crud.

Jonathan

∂16-Jan-87  1656	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[vanroggen%bizet.DEC: LISP POINTERS newsletter announcement]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87  16:56:12 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Jan 87 19:48:29 EST
Date: Fri, 16 Jan 87 19:51:30 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  [vanroggen%bizet.DEC: LISP POINTERS newsletter announcement]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <141187.870116.JAR@AI.AI.MIT.EDU>

Apologies to those of you who are on both SCHEME and COMMON-LISP.

Date: Friday, 16 Jan 1987 06:42:06-PST
From: vanroggen%bizet.DEC at decwrl.DEC.COM
To:   common-lisp at sail.stanford.edu,
      vanroggen%bizet.DEC at decwrl.DEC.COM
Re:   LISP POINTERS newsletter announcement
Message-Id: <8701161443.AA21565@decwrl.dec.com>

                      *** ANNOUNCEMENT ***

                          LISP POINTERS

We're putting together a newsletter and we'd like you to come along.

Every other month, starting in March of 1987, Lisp Pointers will
be bringing you articles, implementation summaries, opinion columns,
and information on the lastest action on the standardization front.
And we need you -- to contribute to our departments, to read the
results of our efforts, and to suggest ways we can provide more of the
kinds of information you want to see.

Lisp Pointers is being funded by companies who care about the future
of Lisp.  The editorial content of the newsletter will not be
influenced by these companies nor will the companies be responsible
for the material contained within Lisp Pointers.  Until such time as
we affiliate with a more formal organization, subscriptions to Lisp
Pointers will be free.  Please spread the word among your friends,
both real and electronic.

Our newsletter will be available through the mails.  To join our
mailing list, send your name and address to:

Mary S. Van Deusen, Editor
IBM Research
PO Box 704
Yorktown Heights, New York  10598
914-789-7845
617-384-2526
MAIDA@IBM.COM

Contributions should be sent directly to the appropriate department:

***LETTERS TO THE EDITOR, NEWS ITEMS***
Mary S. Van Deusen (see above)

***IMPLEMENTATIONS***
Walter van Roggen
DEC
77 Reed Road
HL02-3/E9
Hudson, Massachusetts  01749
617-568-5617
VANROGGEN%BACH.DEC@DECWRL.DEC.COM

***BOOK REVIEWS, BIBLIOGRAPHIES***
Daniel Weinreb
Symbolics, Inc.
11 Cambridge Center
Cambridge, Massachusetts  02142
617-577-7500
DLW@MC.LCS.MIT.EDU

***X3J3 LISP STANDARDIZATION***
Robert F. Mathis
9712 Ceralene Drive
Fairfax, Virginia  22032
703-425-5923
mathis@b.isi.edu

***USERS***
Susan Ennis
Amoco Production Co.
PO Box 3385
Tulsa, Oklahoma  74102
918-660-3588

***TECHNICAL ARTICLES***
Jonl White
Lucid, Inc.
707 Laurel Street
Menlo Park, California  94025
415-329-8400
edsel!bhopal!jonl@navajo.stanford.edu

***ENVIRONMENTS***
John Foderaro
Franz Inc.
1141 Harbor Bay Parkway
Suite 270
Alameda, California  94501
415-769-5656
jkf%franz.uucp@berkeley.edu

***SCHEME***
Will Clinger M/S 50-662
Tektronics Inc.
PO Box 500
Beaverton, Oregon 97077
willc%tekchips@tek.csnet
503-627-4675

***LISP QUESTIONS***
Patrick Dussud
Texas Instruments
12501 Research Boulevard
MS 2201
Austin, Texas  78759
dussud%jenner%ti-csl.csnet@csnet-relay

***INTERNATIONAL ISSUES***
Christian Quiennec
LITP
4 Place Jussieu
F-75252, Paris Cedex 05
FRANCE
tel: +33 (1) 43 36 25 25 x 5251
UUCP: ..!mcvax!inria!queinnec
ARPA: mcvax!inria!queinnec@seismo.css.GOV


∂18-Jan-87  2027	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Scheme time   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Jan 87  20:27:48 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 18 Jan 87 23:26:54 EST
Organization: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
	id AA10400; Sun, 18 Jan 87 23:25:14 est
Date: Sun, 18 Jan 87 23:25:14 est
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Sun, 18 Jan 87 23:25:14 est
Message-Id: <8701190425.AA10400@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Scheme time

I noticed there is no standard time function for scheme.
Let me propose the following:

(days-after-J2000.0)  =>  current time in units of days
as a floating point number.  The time origin is noon,
January 1, 2000.  This date is called J2000.0 by astronomers,
and represents a good time origin for those who are interested
in computing the position of the sun and other stars.  For
example, a formula that gives the approximate location of the
sun in these units is in "The Astronomical Almanac for the Year 
1984", US Naval Observatory and Royal Greenwich Observatory,
US Government Printing Office, Washington DC, 1984.

John

∂25-Jan-87  1837	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[vanroggen%bach.DEC: Looking for Lisps...]   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jan 87  18:36:48 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 25 Jan 87 21:34:00 EST
Date: Sun, 25 Jan 87 21:32:13 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  [vanroggen%bach.DEC: Looking for Lisps...]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <144637.870125.JAR@AI.AI.MIT.EDU>

Apologies to those of you who have seen this message already.
I have nothing to do with this newsletter; I'm just forwarding this
message because I thought people on the scheme list might be interested.
- Jonathan

Date: Tuesday, 20 Jan 1987 14:48:29-PST
From: vanroggen%bach.DEC at decwrl.DEC.COM
To:   common-lisp at sail.stanford.edu,
      vanroggen%bach.DEC at decwrl.DEC.COM
Re:   Looking for Lisps...
Message-Id: <8701202249.AA09113@decwrl.dec.com>

As part of a feature of the LISP POINTERS newsletter, we'd like to collect
descriptions of all currently available Lisp implementations.

Any kind of Lisp is acceptable; it doesn't have to be Common Lisp or Scheme or
Interlisp or MacLisp. It doesn't have to be a commercially supported product
either; it can be free with no warranties whatsoever.

If you're working on an implementation, and you're willing to describe it
for everyone's benefit, send us at least the following information:

  Implementation Name
  Implemented to which standard (if any)
  Features (if no standard; see the suggested list of issues below)
  Additional Features (if implemented according to a standard)
  Missing Features (if implemented according to a standard)
  Current version/availability/prices
  Support (if supported, by whom; sources available?)
  Machine(s)
  Operating System(s)
  Source or Contact
  Any other comments
  Submitter's name, address, and net-address

Some features you might want to comment on include:

  Predefined data types
  Name spaces and scopes and extents
  Control structures (e.g., special forms, non-local goto's, multiple
	values, multiple stacks, tasking, multi-processor support)
  Typing and declarations
  Garbage collection
  I/O functions
  Compiler
  Object-oriented support
  Graphics and windowing support
  Programming tools (e.g., graphics packages, editor interaction,
	system maintenance)
  Interaction with other languages
  AI-oriented tools (e.g., pattern matching, rules, database support,
	natural language interface)
  Any other interesting features

Send this information to:

  Walter van Roggen
  Net address: VANROGGEN%BACH.DEC@DECWRL.DEC.COM
  Mail address: HLO2-3/E9, 77 Reed Rd, Hudson MA, 01749, USA


∂02-Feb-87  1040	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Time Scales   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Feb 87  10:37:56 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU  2 Feb 87 13:34:57 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
	id AA04621; Mon, 2 Feb 87 13:30:28 est
Date: Mon, 2 Feb 87 13:30:28 est
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Mon, 2 Feb 87 13:30:28 est
Message-Id: <8702021830.AA04621@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Time Scales

Astromomers often measure time using the Julian Date and the
Modified Julian Date.  The Julian date is the number of days
since the "begining of time" as estimated by some one from the
god squad of the Middle Ages.  The day begins at noon GMT, and 
today's date at 1PM EST is JD2446829.3.  The Julian date is
useful because there is no need to worry about things like
leap years and changes in the calendar when measuring time
differences.  Another useful unit of measurement is the 
Modified Julian Date.  It is the number of years after
0, January 1, noon GMT.  The number looks like the year we
are used to.  Today's date is J1987.2.  Useful conversions:
J2000.0 = 2000 January 1, noon GMT = JD2451545.0.
J2000.0 is the origin of many formulas that give the position of
the sun and the moon, and these formulas often measure time in
units of days.  Hence, my suggestion for (days-after-J2000.0).
John

∂03-Feb-87  0433	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	X windows
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Feb 87  04:32:36 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU  3 Feb 87 07:33:34 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
	id AA10580; Tue, 3 Feb 87 07:30:51 est
Date: Tue, 3 Feb 87 07:30:51 est
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Tue, 3 Feb 87 07:30:51 est
Message-Id: <8702031230.AA10580@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: X windows

I seems that many are standardizing on X windows.
Maybe we should add some X window calls as non-essential
Scheme?
John

∂04-Feb-87  0744	@MC.LCS.MIT.EDU:andy@hobbes.ads.ARPA 	Re:  X windows   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Feb 87  07:42:00 PST
Received: from grape.ads.ARPA (TCP 1200400070) by MC.LCS.MIT.EDU  4 Feb 87 10:41:35 EST
Received: by hobbes.ads.arpa (3.2/SMI-3.2)
	id AA12106; Tue, 3 Feb 87 09:16:18 PST
Date: Tue, 3 Feb 87 09:16:18 PST
From: andy@hobbes.ads.ARPA (Andy Cromarty)
Message-Id: <8702031716.AA12106@hobbes.ads.arpa>
To: rrrs-authors@mc.lcs.mit.edu
Subject: Re:  X windows
Cc: ramsdell%faron@mitre-bedford.ARPA
Reply-To: andy@ads.arpa

Standardization on a window system seems premature.   Use of
X (or any other system) is a local phenomenon; in different locales
many competing window systems are in use.  If we were to support
window system primitives, it seems to make more sense to support
a metastandard like NeWS, which will incorporate X, Postscript, possibly
Andrew, and other windowing and graphical display approaches -- although 
this too seems premature at the present.

If we are going to support graphics and other "foreign" capabilities,
I believe our time would be more fruitfully spent in defining a
general mechanism for embedding foreign (non-Scheme) functions
into the Scheme environment.  This is far from a cleanly solved
problem in current LISPs, and a good solution would subsume, and
hence obviate the need for, definition of a case-by-case approach 
to embedding specific window, graphics, numerical, and other foreign 
packages into Scheme.

					asc

∂05-Feb-87  0742	@MC.LCS.MIT.EDU:ramsdell%linus@mitre-bedford.ARPA 	Windows  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87  07:42:37 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU  5 Feb 87 10:33:30 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: by linus.MENET (1.1/4.7)
	id AA00820; Thu, 5 Feb 87 07:51:00 EST
Date: Thu, 5 Feb 87 07:51:00 EST
From: John D. Ramsdell <ramsdell%linus@mitre-bedford.ARPA>
Posted-Date: Thu, 5 Feb 87 07:51:00 EST
Message-Id: <8702051251.AA00820@linus.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Windows

Even though I'm a Sun user, it looks to me that NeWS is
a loser, and X window will be supported by many more
venders.  However, on reflection, I strongly agree we
should spend our time on other matters rather than windows.

Speaking of packages (ugh! -- too many Common Lisp connotations)
what do people think of Gelernter, Jagannathan and London's
paper "Environments as First Class Objects" in Jan 1987
ACM Symp. Princ. Prog. Lang?
John

∂20-Feb-87  0746	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[hay%ubc.csnet: no mail] 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Feb 87  07:46:24 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Feb 87 10:39:48 EST
Date: Fri, 20 Feb 87 10:39:27 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  [hay%ubc.csnet: no mail]
To: scheme@MC.LCS.MIT.EDU
Message-ID: <157166.870220.JAR@AI.AI.MIT.EDU>

I don't have an answer to the following.  Can anyone help?  (This is a
half-facetious question.  My conjecture: people who like Scheme for its
minimality like to have their mailing lists be that way too.)
-Jonathan

Date: 19 Feb 87 10:53 -0800
From: Marilyn Hay <hay%ubc.csnet at RELAY.CS.NET>
To:   Scheme Co-ordinator <scheme-request at MC.LCS.MIT.EDU>
Re:   no mail

I have noticed that there has not been any traffic on this list for
some time.  Is there any particular reason or has there just not been
any submissions to the list?  Thanks for any indication as to what has
happened.  Take care,

	Marilyn Hay
	University of British Columbia
	hay@ean.ubc.cdn
	hay@ubc.csnet
	hay%ubc.csnet@csnet-relay.arpa


∂24-Feb-87  0834	@MC.LCS.MIT.EDU:Larry_Brooks.EdServices@Xerox.COM 	help -- set command
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Feb 87  08:34:04 PST
Received: from Xerox.COM (TCP 1200400040) by MC.LCS.MIT.EDU 24 Feb 87 11:31:44 EST
Received: from Riesling.ms by ArpaGateway.ms ; 24 FEB 87 08:28:57 PST
Sender: "Larry_Brooks.EdServices"@Xerox.COM
Date: 24 Feb 87 08:28:17 PST (Tuesday)
Subject: help -- set command
From: "Larry_Brooks.EdServices"@Xerox.COM
To: scheme@MC.LCS.MIT.EDU
cc: "Larry_Brooks.EdServices"@Xerox.COM
Message-ID: <870224-082857-9076@Xerox>

I recently purchased TI's PCScheme for the IBM PC.  I have a question
that I hope someone out there can answer for me.  I would like to use a
command that acts like "set" (i.e., evaluates both its arguments) in
Interlisp.  More specifically, I would like to do the following:

	(SETQ ALIST '(A B C))  {equivalent to set! or define}

	(SET (CAR ALIST) 'Z)    {equivalent to ????}

	(EVAL (CAR ALIST))  {Should return Z}

Neither define or set! evaluate their first arguments.  Does anyone know
of a function that will act like set in Interlisp or of an easy way
around this problem?  (I can think of awkward ways to get around it for
specific applications, but I am looking for a nice generic fix.)

Sorry if this question seems basic to the people on this DL, but I'm a
beginner in both Lisp (a few months of experience) and Scheme (a week of
experience).

Thanks for any help,
Larry

∂26-Feb-87  0457	@MC.LCS.MIT.EDU:Larry_Brooks.EdServices@Xerox.COM 	Re: help -- set command 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Feb 87  04:57:12 PST
Received: from Xerox.COM (TCP 1200400040) by MC.LCS.MIT.EDU 26 Feb 87 07:56:20 EST
Received: from Riesling.ms by ArpaGateway.ms ; 26 FEB 87 04:53:08 PST
Sender: "Larry_Brooks.EdServices"@Xerox.COM
Date: 26 Feb 87 04:43:20 PST (Thursday)
Subject: Re: help -- set command
From: "Larry_Brooks.EdServices"@Xerox.COM
To: willc%tekchips.tek.com@RELAY.CS.NET
cc: "Larry_Brooks.EdServices"@Xerox.COM, scheme@MC.LCS.MIT.EDU
In-Reply-to: "willc%tekchips.tek.com%RELAY.CS.NET":GV:Xerox's message of
 25 Feb 87 16:26
Message-ID: <870226-045308-2404@Xerox>

Thanks for the information.  It looks like going from Interlisp to
Scheme is not quite as easy as I  expected.  I think part of my problem
is learning to "think lexically".  Your advice is much appreciated.  By
the way, TI's PCScheme does support dynamic variables and there are a
couple of environment commands (I still need to learn what they do)
avaliable also.

Take care,

Larry

∂04-Mar-87  0925	@MC.LCS.MIT.EDU:bc@MEDIA-LAB.MEDIA.MIT.EDU 	OOPSs for Scheme, MacScheme    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Mar 87  09:25:28 PST
Received: from MEDIA-LAB.MIT.EDU (TCP 2225200002) by MC.LCS.MIT.EDU  4 Mar 87 12:01:39 EST
Received: by MEDIA-LAB.MIT.EDU (5.54/4.8)  id AA28819; Wed, 4 Mar 87 11:19:50 EST
Date: Wed, 4 Mar 87 11:19:50 EST
From: bill coderre <bc@MEDIA-LAB.MEDIA.MIT.EDU>
Message-Id: <8703041619.AA28819@MEDIA-LAB.MIT.EDU>
To: scheme@mc.lcs.mit.edu
Subject: OOPSs for Scheme, MacScheme



Two Questions.


ONE:

What are the significant differences between the Revised2 and Revised3
Reports on Scheme?


TWO:

I now have MacSheme, which looks pretty good. Recently I have been
programming in a forthcoming Common Lisp which includes Gary
Drescher's Object Lisp system. 

Is there a similar system around that wouldn't be hard to port to
MacScheme? I don't think I'm a good enough hacker to implement one, or
to do a major rewrite kind of port. (I don't need multiple
inheritance, but I do need single inheritance, which isn't very
obvious to me how to do.)


Thank you for the help......................................bc


∂04-Mar-87  1200	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	r↑2 vs. r↑3    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Mar 87  11:59:49 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU  4 Mar 87 14:23:08 EST
Date: Wed,  4 Mar 87 14:23:07 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  r↑2 vs. r↑3
To: bc@MEDIA-LAB.MEDIA.MIT.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Wed 4 Mar 87 11:19:50 EST from bill coderre <bc at MEDIA-LAB.MEDIA.MIT.EDU>
Message-ID: <163107.870304.JAR@AI.AI.MIT.EDU>

    Date: Wed, 4 Mar 87 11:19:50 EST
    From: bill coderre <bc at MEDIA-LAB.MEDIA.MIT.EDU>

    ONE:

    What are the significant differences between the Revised2 and Revised3
    Reports on Scheme?

The changes in the language are mostly trivial.  I'd say the most
visible changes are (1) the boolean constants are written #T and #F
instead of #!TRUE and #!FALSE and (2) a number of peripheral and/or
redundant features have been removed or simplified.

As for the report itself, the R↑3 report has some additional
description, e.g. formal semantics & syntax, and its organization is
somewhat different in places.

For completeness, I'll list all the changes of which I'm aware, not just
the significant ones.  This list appears in the "notes" section of the
r↑3 report.  What constitutes a "clarification" as opposed to an
"incompatible change" is subjective; this is my own classification, not
that of the (other) authors.

New features: 
 - DELAY and FORCE (as in Abelson & Sussman's book)
 - New predicates BOOLEAN? and PROCEDURE?
 - ATAN now admits either one or two arguments.
 - ↑ is now extended alphabetic.

Features removed:
 - NAMED-LAMBDA and REC are both gone.
 - "Curried define", e.g. (define (((f x) y z) w) ...), has been removed.
 - A number of things had more than one name in the R↑2 report; now everything
   has only one name.  Thus SEQUENCE, <?, <=?, =?, >=?, and > are gone.
 - A number of marginal procedures have been flushed, namely:
   APPEND!, STRING-NULL?, SUBSTRING-FILL!, SUBSTRING-MOVE-LEFT!
   SUBSTRING-MOVE-RIGHT!, OBJECT-HASH, OBJECT-UNHASH, 1+, and -1+.
 - The #!NULL syntax for the empty list is gone (use () instead).

Incompatible changes:
 - The boolean constants are now written #t and #f instead of #!true and
   #!false.
 - (define (foo ...) ...) now means (define foo (lambda (...) ...))
   instead of (define foo (letrec ((foo (lambda (...) ...))) foo)).

Technical clarifications:  [In many of these cases, the r↑2 report was at
variance with what the way various implementations behaved, and it seemed
better to change the report than to change the implementations.]
 - The objects returned by literal expressions (e.g. '(a b)) are permitted
   to be immutable.
 - The list to which a rest-argument becomes bound must be newly allocated.
 - DO variables are updated by rebinding rather than by assignment.
 - Backquote allows vectors and nesting, and there's an official read/print
   syntax for backquoted forms (so you can know what you get if you say
   '`(a ,b) ).
 - EQ? on equal numbers is unspecified.
 - Implementations are permitted to do things like
    (EQ? (LAMBDA (X) X) (LAMBDA (Y) Y))  =>  #T.
 - EQV? distinguishes exact numbers from inexact ones, even if they
   are equal according to =.
 - List, string, and vector indexes must be exact integers.


Someone else will have to answer your question number two.

- Jonathan


∂04-Mar-87  1808	@MC.LCS.MIT.EDU:cpd@CS.UCLA.EDU 	Re:  r↑2 vs. r↑3 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Mar 87  18:08:06 PST
Received: from hera.CS.UCLA.EDU (TCP 20030201024) by MC.LCS.MIT.EDU  4 Mar 87 21:02:52 EST
Received: by hera.CS.UCLA.EDU (Sendmail 5.54/5.14)
	id AA17690; Wed, 4 Mar 87 17:14:39 PST
Date: Wed, 4 Mar 87 17:14:39 PST
From: cpd@CS.UCLA.EDU (Charles Dolan)
Message-Id: <8703050114.AA17690@hera.CS.UCLA.EDU>
To: JAR@ai.ai.mit.edu, bc@media-lab.media.mit.edu
Subject: Re:  r↑2 vs. r↑3
Cc: scheme@mc.lcs.mit.edu

Here is a small objected oriented system which I wrote one day
to see how small I could make it.  It does single inheritence.
Objects and classes are procedures. New instances are
created by send a class object the message NEW.  SUPER
is a smalltalk style pseudo instance which calls the method
dispatcher for the class one higher in the heirarchy.  The
DEFINE-METHOD macro walks the code for the message and replaces
varaible references and sets with VECTOR-REFs and VECTOR-SET!s
for a vector of instance variables.  This code was written
using a library of utility functions I use.  I have attempted
to remove all those references.

Sorry for the lack of comments, this is almost a pedagogical example.

(define *metamethod-offset* 0)
(define *method-offset* 1)
(define *parent-offset* 2)
(define *ivs-offset* 3)
(macro define-class 
 (lambda (dummy class parent ivs cvs)
  (set! ivs (combine-var-lists 
             (if parent (property parent 'ivs) nil) ivs))
  (set! cvs (combine-var-lists
             (if parent (property parent 'cvs) nil)
             (append '(metamethods methods parent ivs) cvs)))
  `(set! ,class
     (begin
      (set-property! ',class 'ivs ',ivs)
      (set-property! ',class 'cvs ',cvs)
      (make-class-object ,parent ',ivs ',cvs)))

(define (combine-var-lists l1 l2)
  (letrec
    ((combine
      (lambda (l1 l2)
        (if (null? l2)
            (reverse l1)
            (if (memq (car l2) l1)
                (combine l1 (cdr l2))
                (combine (cons (car l2) l1) (cdr l2)))))))
    (combine (reverse l1) l2)))

(macro define-metamethod
 (lambd (dummy class spec . body)
  (let ((message (car spec))
        (arg-spec (cdr spec)))
    `(add-metamethod-to-class-object ,class ',message
      (lambda (self class %%method-object %%var-vector ,@arg-spec)
        ,@(walk-code-and-replace-variables
           body (property class 'cvs))))))

(define (make-class-object parent ivs cvs)
  (let ((cv-vector (make-vector (length cvs)))
        (class-object nil))
    (vector-set! cv-vector *metamethods-offset* (list 'metamethods))
    (vector-set! cv-vector *methods-offset* (list 'methods))
    (vector-set! cv-vector *parent-offset* parent)
    (vector-set! cv-vector *ivs-offset* ivs)
    (set! class-object
          (lambda (message . args)
            (cond ((eq? message 'cv-vector) cv-vector)
                  ((eq? message 'class-object?) t)
                  (T  (dispatch-metamethod
                       class-object class-object message args
                       cv-vector)))))))

(define (add-metamethod-to-class-object class-object message func)
  (let* ((a-list (vector-ref (class-object 'cv-vector)
                             *metamethod-offset*))
         (pair (assq message (cdr a-list))))
    (if pair
        (set-cdr! pair func)
        (set-cdr! a-list (cons (cons message func) (cdr a-list))))))

(define (dispatch-metamethod class-object method-object message args
                             cv-vector)
  (let* ((method-vector (if (null? method-object)
                            (cerror "No metamethod" message args)
                            (method-object 'cv-vector)))
         (pair (assq message (cdr (vector-ref method-vector
                                              *metamethod-offset*)))))
    (if pair
        (apply (cdr pair)
               (cons class-object
                     (cons ()
                           (cons method-object
                                 (cons cv-vector args)))))
        (dispatch-metamethod class-object
                             (vector-ref method-vector *parent-offset*)
                             message args cv-vector))))

(define (walk-code-and-replace-variables expr vars)
  (cond ((symbol? expr)
         (if (memq expr vars)
             `(vector-ref %%var-vector ,(nth-inv vars expr))
             expr))
        ((atom? expr) expr)
        ((pair? expr)
         (cond ((eq? (car expr) 'quote)
                expr)
               ((eq? (car expr) 'set!)
                (if (memq (cadr expr) vars)
                    `(vector-set! %%var-vector
                                  ,(nth-inv vars (cadr expr))
                                  ,(walk-code-and-replace-variables
                                    (caddr expr) vars))
                    expr))
               (T (cons
                   (walk-code-and-replace-variables (car expr) vars)
                   (walk-code-and-replace-variables (cdr expr) vars)))))))

(macro define-method
 (lambda (dummy class spec . body)
  (let ((message (car spec))
        (arg-spec (cdr spec)))
    `(add-method-to-class-object ,class ',message
       (lambda (self class %%method-object %%var-vector ,@arg-spec)
         ,@(walk-code-and-replace-variables
            body (property class 'ivs))))))

(define (add-method-to-class-object class-object message func)
  (let* ((a-list (vector-ref (class-object 'cv-vector) 1))
         (pair (assq message (cdr a-list))))
    (if pair
        (set-cdr! pair func)
        (set-cdr! a-list (cons (cons message func) (cdr a-list))))))

(define (make-instance-object class-object)
  (let ((iv-vector (make-vector
                    (length (vector-ref (class-object 'cv-vector) 
                                        *iv-offset*))))
        (instance-object nil))
    (set! instance-object
          (lambda (message . args)
            (cond ((eq? message 'iv-vector) iv-vector)
                  ((eq? message 'class-object?) nil)
                  (T (dispatch-method class-object class-object
                                      message args
                                      instance-object iv-vector)))))
    instance-object))

(define (dispatch-method class-object method-object message args
                         instance-object iv-vector)
  (let* ((cv-vector (if (null? method-object)
                        (cerror "No method" message args)
                        (method-object 'cv-vector)))
         (pair (assq message
                    (cdr (vector-ref cv-vector *methods-offset*)))))
    (if pair
        (apply (cdr pair)
               (cons instance-object
                     (cons class-object
                           (cons method-object 
                                 (cons iv-vector args)))))
        (dispatch-method class-object
                         (vector-ref cv-vector *parent-offset*)
                         message args
                         instance-object iv-vector))))

(macro super 
 (lambda (dummy message . args)
  `(dispatch-super class %%method-object
                   ,message (list ,@args)
                   self %%var-vector))

(define (dispatch-super class-object method-object message args
                        instance-object iv-vector)
  (let ((parent (vector-ref (method-object 'cv-vector) *parent-offset*)))
    (if (null? parent)
        (cerror "No super-method or super-metamethod" message args)
        (if (null? (instance-object 'class-object?))
            (dispatch-method class-object parent message args
                             instance-object iv-vector)
            (dispatch-metamethod instance-object parent message args
                                 iv-vector)))))

; A little documentation
;
;  (DEFINE-CLASS class-name parent instance-variables class-variables)
;  (DEFINE-METHOD class-name (method-name . args) . body)
;  (DEFINE-METAMETHOD class-name (method-name . args) . body)
;
;  Here is a small example
;
;  (DEFINE-CLASS NEW-CLASS () (NAME) (INSTANCE-COUNT))
;
;  (DEFINE-METAMETHOD NEW-CLASS (NEW)
;    (LET ((NEW-OBJECT (SUPER 'NEW)))
;      (SET! INSTANCE-COUNT (1+ INSTANCE-COUNT))
;      OBJECT))
;
;  (DEFINE-METAMETHOD NEW-CLASS (GET-INSTANCE-COUNT)
;    INSTANCE-COUNT)
;
;  (DEFINE-METHOD NEW-CLASS (SET-NAME NEW-NAME)
;    (SET! NAME NEW-NAME))
;
;  (DEFINE-CLASS ANOTHER-NEW-CLASS (NEW-CLASS () ())
;
;  (DEFINE-METHOD ANOTHER-NEW-CLASS (SET-NAME NEW-NAME)
;     (SUPER 'SET-NAME NEW-NAME)
;     (DISPLAY NEW-NAME)
;     (NEWLINE))

Enjoy, comments welcome, flame to yourself.

-Charlie Dolan

∂05-Mar-87  1253	@MC.LCS.MIT.EDU:wolfgang%cantuar%math.waterloo.edu@RELAY.CS.NET 	Re:  OOPSs for Scheme, MacScheme   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Mar 87  12:52:54 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU  5 Mar 87 15:12:38 EST
Received: from relay2.cs.net by RELAY.CS.NET id ai07823; 5 Mar 87 11:26 EST
Received: from waterloo by csnet-relay.csnet id aq01858; 5 Mar 87 11:22 EST
Received: from cantuar.uucp by watmath; Wed, 4 Mar 87 23:42:05 est
Date: Thu, 5 Mar 87 11:21:57+1200
From: "W. Kreutzer" <wolfgang%cantuar%math.waterloo.edu@RELAY.CS.NET>
To: scheme@MC.LCS.MIT.EDU, bc@MEDIA-LAB.MEDIA.MIT.EDU
Subject: Re:  OOPSs for Scheme, MacScheme

If you get an answer to that question I would be interested in it. We have
a locally developed class and flavour package for ChezScheme, if that is
any help. So far I have not got around to port it to MacScheme.
--- wolfgang kreutzer, computer science, University of Canterbury,
New Zealand ---


∂05-Mar-87  1955	@MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET 	Tiny Object System    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Mar 87  19:55:18 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU  5 Mar 87 15:22:02 EST
Received: from relay2.cs.net by RELAY.CS.NET id ae08210; 5 Mar 87 12:28 EST
Received: from northeastern.edu by RELAY.CS.NET id ah02163; 5 Mar 87 12:23 EST
Received: from corwin.ccs.northeastern.edu by
           nuhub.acs.northeastern.edu; Thu, 5 Mar 87 09:51 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/5.17)
	id AA00230; Thu, 5 Mar 87 09:23:39 EST
Date: Thu, 5 Mar 87 09:23:39 EST
From: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET
To: scheme@MC.LCS.MIT.EDU
Subject: Tiny Object System

OK, here is my entry in the "smallest pedagogical OOPS".  It is not quite as
refined as I would like, but it's close.  Note that flavors and operations
(methods) are first-class citizens, more or less:  in particular, messages are
NOT quoted symbols.

-- Mitch Wand (wand@corwin.ccs.northeastern.edu)

;;; A Toy Flavors System in Scheme, based on Generic Functions
;;; or, Object-Oriented Programming without Objects

;;; In this version, we introduce a functional model of operations.

;;; Definitions of data structures:

;;; flavor = ([parent|nil] . instance-names)  
; cons-cell is hash code for unique flavor (test equality of flavors
; with eq?)
; instance-names are all required fields, beginning with ancestors and
; concluding with local names)

;;; instance = (flavor . instance-values)

;;; method = (cell operation)	 ; the cell is probably superfluous.

;;; operation = instance->flavor->operation->fcn

;;; An operation takes 3 arguments:  the INSTANCE, the FLAVOR of which
;;; it is supposed to be an instance, and another OPERATION (to be
;;; invoked upon inheritance), and produces a FCN to be applied to the
;;; instance. 

;;; fcn = lambda (self af1 ... af_k lf_1 ... lf_n . extra-fields) .
;;;         lambda (param_1 ... param_p) . M

;;; The point is that the fcn might be applied to an instance of a
;;; DESCENDENT of this flavor, so it will be a record consisting of
;;; the fields of this flavor (af_1 .. lf_n), plus some additional
;;; fields.


;;; Data Structures

(define make-cell (lambda (v) (cons v nil)))
(define deref-cell car)
(define set-cell! set-car!)

(define fl->parent cadr)
(define fl->instance-names cddr)
(define mk-fl (lambda (parent names) (cons '&flavor (cons parent names))))
(make-unprintable '&flavor '<FLAVOR>)

(define inst->flavor car)
(define inst->values cdr)
(define mk-inst cons)

;;; Functional Core

(define make-flavor
  (lambda (parent new-names)
    (mk-fl parent (append (fl->instance-names parent) new-names))))

;;; here is the empty method.  It tries to invoke inheritance if it
;;; can.  The third argument is the method to be used if inheritance
;;; is to be followed.  Note the implicit Y operator in the last line.

(define empty-method
  (lambda (instance flavor whole-method)
    (let ((parent (fl->parent flavor)))
      (if (null? parent)
          (error "Couldn't apply method" whole-method instance)
          (whole-method parent instance whole-method)))))

(define make-method
  (lambda ()
    (make-cell empty-method)))

;;; here is how we add a new "unit method" to an existing method.
;;; This is just the familiar notion of functional extension EXCEPT
;;; for the whole-method argument.  This is passed along as we search
;;; for an applicable method, and is eventually used by empty-method
;;; to invoke inheritance.

(define cons-composite-method
  (lambda (new-flavor new-fcn old-method)
    (lambda (instance flavor whole-method)
      (if (eq? flavor new-flavor)
	 (apply new-fcn
	  (cons instance (inst->values instance)))
         (old-method flavor instance whole-method)))))

(define add-method!
  (lambda (method flavor fcn)
    (set-cell! method
               (cons-composite-method flavor fcn (deref-cell method)))))

;;; Next we write some user-interfaces

; the null flavor has no parent and no fields

(define null-flavor '(nil))

; define new flavors with define-flavor

(extend-syntax (define-flavor)
  [(define-flavor name parent instance-name ...)
   (define name (make-flavor (if (null? parent) null-flavor parent)
			     '(instance-name ...)))])

; make new instances with make-instance.  Put parent values first,
; then local values.  This could use call-by-keyword, with a SMOP.

(extend-syntax (make-instance)
  [(make-instance flavor values ...)
   (list flavor values ...)])

; make new methods with define-method

(extend-syntax (define-method)
  [(define-method name)
   (define name (make-method))])

; add options to methods with add-method

(define expand-add-method
  (lambda (exp)
    (record-case exp
      [add-method (method flavor params body)
	(let ([bvl (cons 'self (append (fl->instance-names
					(execute (compile flavor)))
				       'extras))])
	 `(begin
	   (add-method! ,method ,flavor
		      (lambda ,bvl (lambda ,params ,body)))
	   ',method))])))

(macro add-method expand-add-method)

;;; apply-method is the user-level invocation of methods.  It
;;; evaluates and dereferences its method and object arguments exactly
;;; once.  Notice how real-method is passed as the third argument to
;;; itself in order to initiate the inheritance search loop.

(extend-syntax (apply-method)
  [(apply-method method object arg ...)
   (let ((real-method (deref-cell method))
         (real-object object))     
     ((real-method (inst->flavor real-object) real-object real-method)
      arg ...))])

;;; Just for laughs, here is a general setter:

(define-method :set)

(add-method :set null-flavor (name val)
	    (iterate loop
	      ([names (fl->instance-names (inst->flavor self))]
	       [vals  (inst->values self)])
	      (cond
		[(null? names) (error "cannot set " name)]
		[(eqv? (car names) name) (set-car! vals val) val]
		[else (loop (cdr names) (cdr vals))])))


(define-method :run-super)

(add-method :run-super null-flavor (method)
	    (let ((parent (fl->parent (inst->flavor self))))
	      (if (null? parent)
		  (error "no super")
		  (apply-method method (mk-inst parent (inst->values
							self))))))

  

;;; and here is a test file:

(define-flavor terminal () val)
(define-flavor Ident terminal)
(define-flavor Number terminal)
(define-flavor Compound () Operator argument1 argument2)
(define-flavor MulSym ())
(define-flavor AddSym ())

(define-method :eval)

(add-method :eval Number () val)

(add-method :eval Compound ()
	    (apply-method :operator-result Operator
			  (apply-method :eval argument1)
			  (apply-method :eval argument2)))

(define-method :operator-result)

(add-method :operator-result MulSym (v1 v2) (* v1 v2))
(add-method :operator-result AddSym (v1 v2) (+ v1 v2))


(define test1
  (lambda ()
    (let* ([mulsym (make-instance MulSym)]
	   [addsym (make-instance AddSym)]
	   [obj1 (make-instance Compound addsym 
		    (make-instance Number 5)
		    (make-instance Number 7))])
	  (writeln (apply-method :eval obj1) " = " 12)
	  (apply-method :set obj1 'Operator mulsym)
	  (writeln (apply-method :eval obj1) " = " 35))))























∂07-Mar-87  0351	@MC.LCS.MIT.EDU:munnari!cidam.oz!mg@seismo.CSS.GOV 	distribution list 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Mar 87  03:51:46 PST
Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU  6 Mar 87 09:32:00 EST
Received: from munnari.oz by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA03842; Thu, 5 Mar 87 22:41:38 EST
Message-Id: <8703060341.AA03842@seismo.CSS.GOV>
Received: from cidam (via goanna) by munnari with SunIII (5.5)
	id AA29000; Fri, 6 Mar 87 14:28:07 EST
Received: by cidam.rmit.oz (4.3+RMIT/4.7)
	id AA18877; Fri, 6 Mar 87 10:24:09 EST
Date: Fri, 6 Mar 87 10:24:09 EST
From: munnari!cidam.rmit.oz!mg@seismo.CSS.GOV (Mike A. Gigante)
To: SCHEME@mc.lcs.mit.edu
Subject: distribution list


There is now a distribution list here in Australia.  For anyone else receiving
the list direct, send your details to scheme-request@cidam.oz (Australia only)

Mike Gigante,  munnari!cidam.oz!mg@seismo.css.gov

∂09-Mar-87  0055	@MC.LCS.MIT.EDU:wolfgang%cantuar%math.waterloo.edu@RELAY.CS.NET 	Re:  distribution list   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Mar 87  00:55:03 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU  9 Mar 87 03:43:54 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa08194; 9 Mar 87 3:39 EST
Received: from waterloo by csnet-relay.csnet id aa08421; 9 Mar 87 3:32 EST
Received: from cantuar.uucp by watmath; Mon, 9 Mar 87 02:27:15 est
Date: Mon, 9 Mar 87 10:25:37+1200
From: "W. Kreutzer" <wolfgang%cantuar%math.waterloo.edu@RELAY.CS.NET>
To: SCHEME@MC.LCS.MIT.EDU, 
    mg <@RELAY.CS.NET,@cidam.rmit.oz,@munnari.csnet:mg@SEISMO.CSS.GOV>
Subject: Re:  distribution list

yes, we are on the MIT scheme news list. If there is a cheaper way to get 
the stuff from you, we are interested. Thanks
--- w. kreutzer, computer science, university of canterbury
christchurch, new zealand ---


∂10-Mar-87  1930	@MC.LCS.MIT.EDU:jar@ZURICH.AI.MIT.EDU 	test suite candidate 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87  19:30:06 PST
Received: from zurich (TCP 2206400260) by MC.LCS.MIT.EDU 10 Mar 87 22:32:51 EST
Received: by ZURICH.AI.MIT.EDU; Tue, 10 Mar 87 22:08:22 est
Date: Tue, 10 Mar 87 22:08:22 est
From: jar@ZURICH.AI.MIT.EDU (Jonathan Rees)
Message-Id: <8703110308.AA07187@zurich>
To: rrrs-authors@mc.lcs.mit.edu
Subject: test suite candidate
Reply-To: JAR@AI.AI.MIT.EDU


Has anyone worked on a test suite?  Here's a suggestion for inclusion,
which, fortunately, works in the three implementation in which I tried
it.  I leave the significance of this test as an exercise.

		- Jonathan


(define (tst)
  
  (define k1 #f)
  (define k2 #f)
  (define cwcc call-with-current-continuation)
  (define step 0)
  
  (define (detect-lossage)
    (set! step (+ step 1))
    (case step
      ((1) (cwcc (lambda (k) (set! k1 k) 'a)))
      ((2) (cwcc (lambda (k) (set! k2 k) 'b)))
      ((4) 'd)))
  
  (let ((answer (list (detect-lossage) (detect-lossage))))
    (set! step (+ step 1))
    (case step
      ((3) (k1 'c))   ;answer = (a b) or (b a)
      ((5) (k2 'e))   ;answer = (c d) or (d c)
      ((6)
       (cond ((or (equal? answer '(a e))
		  (equal? answer '(e a)))
	      'wins)
	     ((or (equal? answer '(c e))
		  (equal? answer '(e c)))
	      'loses)
	     (else (list 'really-loses answer)))))))

∂10-Mar-87  2309	@MC.LCS.MIT.EDU:cth%iucs.cs.indiana.edu@RELAY.CS.NET   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87  23:08:34 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Mar 87 18:31:25 EST
Received: from relay2.cs.net by RELAY.CS.NET id ac24159; 10 Mar 87 17:36 EST
Received: from indiana by RELAY.CS.NET id af19280; 10 Mar 87 17:32 EST
Date: Tue, 10 Mar 87 16:01:55 est
From: Chris Haynes <cth%iucs.cs.indiana.edu@RELAY.CS.NET>
To: vanroggen%bach.dec@DECWRL.DEC.COM, scheme@MC.LCS.MIT.EDU

Scheme 84 compiles source to an intermediate s-expression code, which
is then interpreted by a Virtual Scheme Machine (VSM) written in
compiled Franz Lisp.  This note outlines the relative merits of
Scheme 84.
 
ADVANTAGES:
 
-- COST:  It is FREE, available via anonymous ftp on arpanet as 
   directory pub/scheme84 on iucs.cs.indiana.edu (since we are new 
   to arpanet, you may have to use 192.12.206.205), or send a tape to
 
		Nancy Garrett
		Lindley Hall
		Bloomington, IN 47405.
		
   It will be returned with Scheme 84 in Unix tar format, with an
   Indiana University Computer Science Department Technical Report
   that documents the language.  Scheme 84 was developed under
   Berkley Unix, but also runs under VMS if you have Franz Lisp.
   
-- PORTABILITY:  It is very easy to port Scheme 84 to any machine
   that runs Franz Lisp.  Without much difficulty it could also be
   ported to run under other Lisp systems, such as Common Lisp or
   PSL.  Only a small set of Lisp features are used.
   
-- MALEABILITY:  It is easy to modify.  Many interesting features can
   be added to Scheme 84 with only a few hours (or even minutes) of
   work.  The entire Scheme 84 implementation can be digested easily
   in a few days.  We have found this to be of great value in our
   research.  For example, engines, an abstraction of timed preemption 
   [Haynes and Friedman 84], was first implemented in Scheme 84.
   It is particularly easy to import Franz Lisp features into Scheme.
   This has been used, for example, to implement a Semantic
   Prototyping System [Wand 84] with hooks to Lex and Yacc.

DISADVANTAGES:
 
-- SPEED:  It is much slower than Scheme implementations
   based on native code compilation, such as Chez Scheme or T.
   However, the intermediate code and VSM were carefully designed to
   get the most out of the Franz compiler so that Scheme 84 is 
   comparable in speed to other interpreted Scheme implementations.
   
-- FRANZ FOIBLES:  A few unfortunate features of Franz Lisp show through.
   For example, some run time errors are caught by Franz, not Scheme,
   and result in inappropriate error messages (though Scheme 84 always
   recovers control).  

-- STANDARDIZATION:  Scheme 84 is fairly close to the Scheme standard
   [Rees and Clinger 86], but has not been brought completely up to
   date.  (Any volunteers?)
   
   
[Rees and Clinger 86] Rees, J., and Clinger, W., Revised Report on 
   the Algorithmic Language Scheme, SIGPLAN Notices 21:12, pp. 37-79
   (1986).
 
[Haynes and Friedman 84] Haynes, C.T., and Friedman, D.P., Engines 
   build process abstractions, Conf. Rec. of the 1984 ACM Symposium 
   on Lisp and Functional Programming, pp. 18-24.
 
[Wand 84] Wand, M., A semantic prototyping system, Proc. ACM SIGPLAN '84
   Compiler Construction Conference, pp. 213-221.


∂11-Mar-87  2251	@MC.LCS.MIT.EDU:cth@IUCS.CS.INDIANA.EDU 	Scheme 84
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Mar 87  22:51:07 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 11 Mar 87 13:56:25 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa02343; 11 Mar 87 13:34 EST
Received: from indiana by RELAY.CS.NET id ad25226; 11 Mar 87 13:28 EST
Date: Wed, 11 Mar 87 12:30:00 est
From: Chris Haynes <cth@IUCS.CS.INDIANA.EDU>
To: scheme@MC.LCS.MIT.EDU
Subject: Scheme 84

Scheme 84 compiles source to an intermediate s-expression code, which
is then interpreted by a Virtual Scheme Machine (VSM) written in
compiled Franz Lisp.  This note outlines the relative merits of
Scheme 84.
 
ADVANTAGES:
 
-- COST:  It is FREE, available via anonymous ftp on arpanet as 
   directory pub/scheme84 on iucs.cs.indiana.edu (since we are new 
   to arpanet, you may have to use 192.12.206.205), or send a tape to
 
		Nancy Garrett
		Lindley Hall
		Bloomington, IN 47405.
		
   It will be returned with Scheme 84 in Unix tar format, with an
   Indiana University Computer Science Department Technical Report
   that documents the language.  Scheme 84 was developed under
   Berkley Unix, but also runs under VMS if you have Franz Lisp.
   
-- PORTABILITY:  It is very easy to port Scheme 84 to any machine
   that runs Franz Lisp.  Without much difficulty it could also be
   ported to run under other Lisp systems, such as Common Lisp or
   PSL.  Only a small set of Lisp features are used.
   
-- MALEABILITY:  It is easy to modify.  Many interesting features can
   be added to Scheme 84 with only a few hours (or even minutes) of
   work.  The entire Scheme 84 implementation can be digested easily
   in a few days.  We have found this to be of great value in our
   research.  For example, engines, an abstraction of timed preemption 
   [Haynes and Friedman 84], was first implemented in Scheme 84.
   It is particularly easy to import Franz Lisp features into Scheme.
   This has been used, for example, to implement a Semantic
   Prototyping System [Wand 84] with hooks to Lex and Yacc.

DISADVANTAGES:
 
-- SPEED:  It is much slower than Scheme implementations
   based on native code compilation, such as Chez Scheme or T.
   However, the intermediate code and VSM were carefully designed to
   get the most out of the Franz compiler so that Scheme 84 is 
   comparable in speed to other interpreted Scheme implementations.
   
-- FRANZ FOIBLES:  A few unfortunate features of Franz Lisp show through.
   For example, some run time errors are caught by Franz, not Scheme,
   and result in inappropriate error messages (though Scheme 84 always
   recovers control).  

-- STANDARDIZATION:  Scheme 84 is fairly close to the Scheme standard
   [Rees and Clinger 86], but has not been brought completely up to
   date.  (Any volunteers?)
   
   
[Rees and Clinger 86] Rees, J., and Clinger, W., Revised Report on 
   the Algorithmic Language Scheme, SIGPLAN Notices 21:12, pp. 37-79
   (1986).
 
[Haynes and Friedman 84] Haynes, C.T., and Friedman, D.P., Engines 
   build process abstractions, Conf. Rec. of the 1984 ACM Symposium 
   on Lisp and Functional Programming, pp. 18-24.
 
[Wand 84] Wand, M., A semantic prototyping system, Proc. ACM SIGPLAN '84
   Compiler Construction Conference, pp. 213-221.


∂12-Mar-87  0356	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET 	Question: are theres ANY VIDEO TAPES available for Scheme ?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Mar 87  03:56:36 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 Mar 87 06:56:01 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa08863; 12 Mar 87 6:52 EST
Received: from switzerland by RELAY.CS.NET id aa00256; 12 Mar 87 6:45 EST
Received: from ean by SWITZERLAND.CSNET id a017020; 12 Mar 87 12:37 WET
From: "Daniel K. Schneider" <shneider%cui.unige.chunet@RELAY.CS.NET>
To:  scheme@MC.LCS.MIT.EDU
MMDF-Warning:  Parse error in original version of preceding line at SWITZERLAND.CSNET
Message-ID: <203:shneider@cui.unige.chunet>
Subject: Question: are theres ANY VIDEO TAPES available for Scheme ?

We heard that there were some video tapes around which teach programming
in Scheme (maybe some MIT "6.001" lessons).

If #T,  (1) where could I get them ?
        (2) for what price (incl. handling, mail to Switzerland) ?

Thanks for any help !
--
Daniel K.Schneider
ISSCO, University of Geneva, 54 route des Acacias, 1227 Carouge (Switzerland)
Tel. (..41) (22) 20 93 33 ext. 2114
          to VMS/BITNET:                    to UNIX/EAN (preferable):
BITNET:   SCHNEIDE@CGEUGE51                 shneider%cui.unige.chunet@CERNVAX
ARPA:     SCHNEIDE%CGEUGE51.BITNET@WISCVM   shneider@cui.unige.CHUNET
                                        or: shneider%cui.unige.chunet@ubc.csnet
uucp:                                       mcvax!cernvax!cui!shneider   



∂12-Mar-87  0608	@MC.LCS.MIT.EDU:dyb@IUVAX.CS.INDIANA.EDU 	Re:  test suite candidate   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Mar 87  06:08:27 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 12 Mar 87 09:03:01 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa09740; 12 Mar 87 8:57 EST
Received: from indiana by RELAY.CS.NET id ac00825; 12 Mar 87 8:52 EST
Date: Wed, 11 Mar 87 23:58:18 est
From: "R. Kent Dybvig" <dyb@IUVAX.CS.INDIANA.EDU>
To: JAR@MC.LCS.MIT.EDU
Subject: Re:  test suite candidate
Cc: rrrs-authors@MC.LCS.MIT.EDU

I believe I was the one who volunteered to work on this at last year's
Lisp conference, and I plan to do so over the summer.  I'll save your
program away (it does work in Chez Scheme, incidentally).  I also
welcome any other test programs people have written or wish to write.

We have a favorite continuation example here, but it is probably more
challenging to people than to Scheme systems.  It is "mondo-bizarro",
whose definition is given below.  Work it out on paper before trying
it out.

(define mondo-bizarro
   (lambda ()
      (let ([k (call/cc (lambda (c) c))])
         (write 1)
         (call/cc (lambda (c) (k c)))
         (write 2)
         (call/cc (lambda (c) (k c)))
         (write 3))))

Kent


∂16-Mar-87  1056	@MC.LCS.MIT.EDU:DAN@cis.upenn.edu 	Revised Revised Revised Report on Scheme
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Mar 87  10:54:30 PST
Received: from linc.cis.upenn.edu (TCP 1201000140) by MC.LCS.MIT.EDU 16 Mar 87 13:49:53 EST
Received: by linc.cis.upenn.edu
	id AA04208; Mon, 16 Mar 87 13:44:04 EST
Posted-Date: Mon, 16 Mar 87 13:46 EST
Message-Id: <8703161844.AA04208@linc.cis.upenn.edu>
From: Dan Zigmond <Dan@cis.upenn.edu>
Subject: Revised Revised Revised Report on Scheme
To: scheme@mc.lcs.mit.edu
Date: Mon, 16 Mar 87 13:46 EST

How does one get a copy of this new spec?  Is it FTPable from somewhere?

	Dan

∂16-Mar-87  1517	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Revised↑3 Report on Scheme; administrivia    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Mar 87  15:17:23 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Mar 87 17:51:05 EST
Date: Mon, 16 Mar 87 17:49:49 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Revised↑3 Report on Scheme; administrivia
To: Dan@CIS.UPENN.EDU, scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 16 Mar 87 13:46 EST from Dan Zigmond <Dan at cis.upenn.edu>
Message-ID: <169287.870316.JAR@AI.AI.MIT.EDU>

    Date: Mon, 16 Mar 87 13:46 EST
    From: Dan Zigmond <Dan at cis.upenn.edu>
    To:   scheme at mc.lcs.mit.edu
    Re:   Revised Revised Revised Report on Scheme

    How does one get a copy of this new spec?  Is it FTPable from somewhere?

It's in ACM SIGPLAN Notices, December 1986.  You can also get it from
the MIT AI Lab Publications Office, 545 Technology Square, Cambridge MA
02139, for $6.00, prepaid; ask for AI Memo 848a.  If you want the
LaTeX sources, you can get them from MIT-PREP:/scheme/r3rs.tar (that's a
Unix "tar" file), but I think you're better off dealing with the
hardcopy, unless you want to modify it.

Attention new arrivals to the list: rather than bother everyone on the
list with requests like this for basic information which has a high
probability of having already been posted, please send your easy
questions to Scheme-Request@MIT-MC.  In particular, I can send you a
compendium of implementation announcements, consisting of messages which
have been sent to this list.  Don't get upset if a week or two goes by
without an answer from me, since I tend to deal with scheme-request
messages in batches; be patient.

Implementors & others: if you want to add or change things in this
standard information packet I send out, please let me know.

One last thing:  I would like for people to get in the habit of sending
mail pertaining to the Scheme mailing list to Scheme-Request, not to me
personally.  This is both to make my own record-keeping easier
(messages sent to Scheme-Request are archived) and to be prepared
in case someone else ever takes over management of the list
either temporarily or permanently.

Thanks

Jonathan


∂16-Mar-87  2003	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Request for public domain Scheme programs    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Mar 87  20:03:25 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Mar 87 22:59:43 EST
Date: Mon, 16 Mar 87 22:59:01 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Request for public domain Scheme programs
To: scheme@MC.LCS.MIT.EDU
Message-ID: <169444.870316.JAR@AI.AI.MIT.EDU>

Date: Mon 16 Mar 87 18:57:21-MST
From: Raul Machuca <RMACHUCA at SIMTEL20.ARPA>
To:   scheme-request at MC.LCS.MIT.EDU

Are there any public domain scheme pgrams that can be ftp'd, in
particular for TI PC Scheme?


∂17-Mar-87  0847	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Revised↑3 Report on Scheme; administrivia    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Mar 87  08:47:16 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Mar 87 11:39:27 EST
Date: Tue, 17 Mar 87 11:38:33 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Revised↑3 Report on Scheme; administrivia
To: zs01#@ANDREW.CMU.EDU
cc: scheme@MC.LCS.MIT.EDU
In-reply-to: Msg of Mon 16 Mar 87 23:05:57 est from zs01# at andrew.cmu.edu (Zalman Stern)
Message-ID: <169681.870317.JAR@AI.AI.MIT.EDU>

    Date: Mon, 16 Mar 87 23:05:57 est
    From: zs01# at andrew.cmu.edu (Zalman Stern)
    To:   scheme-request at mit-mc

    Could you please send me the "standard information packet" as advertised in
    the above message.

I omitted to say that people on Internet can FTP this from host MIT-MC.
It's in file "LSPMAI; SCHEME IMPLS".  Back message are in "LSPMAI;
SCHEME MAIL" on MIT-MC and even older messages are in "LSPMAI; SCHEME
MAIL1" on MIT-AI.

If you don't have FTP access to the Internet, I'm willing to send the
list of implementations.  I won't mail the archives, they're too big.


∂17-Mar-87  1405	@MC.LCS.MIT.EDU:cph@KLEPH.AI.MIT.EDU 	eqv?   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Mar 87  14:05:24 PST
Received: from kleph (TCP 2206400254) by MC.LCS.MIT.EDU 17 Mar 87 16:19:07 EST
Received: by KLEPH.AI.MIT.EDU; Tue, 17 Mar 87 16:08:11 est
Date: Tue, 17 Mar 87 16:08:11 est
From: cph@KLEPH.AI.MIT.EDU (Chris Hanson)
Message-Id: <8703172108.AA02948@kleph>
To: jar@ai
Cc: rrrs-authors@mc
Subject: eqv?

I believe that the paragraph starting "There is only one empty
list..." on page 13, section 6.2 of R3RS should be modified.  In MIT
Scheme, the statement that

(eqv? "" "") ==> #t

is actually false, because there is a user operation,
`set-string-length!', which distinguishes between two empty strings.
I think that the same might be true of #() in an implementation with
`vector-grow!'.

The statement should be modified to indicate that it is true given the
operations described in the report, and may not be true in a given
implementation with extended operations.

∂17-Mar-87  1526	@MC.LCS.MIT.EDU:SUSSMAN@G.BBN.COM 	Re: Question: are theres ANY VIDEO TAPES available for Scheme ?  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Mar 87  15:26:44 PST
Received: from G.BBN.COM (TCP 30000201103) by MC.LCS.MIT.EDU 17 Mar 87 17:10:12 EST
Date: 17 Mar 1987 16:40-EST
Sender: SUSSMAN@G.BBN.COM
Subject: Re: Question: are theres ANY VIDEO TAPES available for Scheme ?
From: SUSSMAN@G.BBN.COM
To: shneider%cui.unige.chunet@RELAY.CS.NET
Cc: scheme@MC.LCS.MIT.EDU
Message-ID: <[G.BBN.COM]17-Mar-87 16:40:17.SUSSMAN>
In-Reply-To: <203:shneider@cui.unige.chunet>

There is a videotaped version of 6.001.  You should contact CAES
(The Center for Advanced Engineering Study) about availability and price.
There may be better prices for universities than for industry --
I don't know anything about pricing.  I think that Hewlett Packard
is supplying the tapes to U.S. universities, but I don't know about
foreign universities.  CAES might know more about this too.

Julie Sussman

∂22-Mar-87  1714	@MC.LCS.MIT.EDU:munnari!cidam.oz!mg@seismo.CSS.GOV 	dump-world problem on 4.2BSD vax (version 4 C-scheme)
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Mar 87  17:14:02 PST
Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU 22 Mar 87 20:14:02 EST
Received: from munnari.oz by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA15239; Sun, 22 Mar 87 20:09:11 EST
Message-Id: <8703230109.AA15239@seismo.CSS.GOV>
Received: from cidam (via goanna) by munnari with SunIII (5.5)
	id AA23604; Mon, 23 Mar 87 10:15:26 EST
Received: by cidam.rmit.oz (4.3+RMIT/4.7)
	id AA24441; Sun, 22 Mar 87 14:27:04 EST
Date: Sun, 22 Mar 87 14:27:04 EST
From: munnari!cidam.rmit.oz!mg@seismo.CSS.GOV (Mike A. Gigante)
To: scheme@mc.lcs.mit.edu
Subject: dump-world problem on 4.2BSD vax (version 4 C-scheme)


I get the following error when using dump-world. (vax 750, 4.2BSD)


% scheme
Scheme Microcode Version 8.2
MIT Scheme, UNIX version
↑AH (CTRL-A, then H) shows help on interrupt keys.
FASLoading file /usr/mg/lib/scheme/scheme.bin

Scheme saved on Saturday March 21, 1987 at 9:55:37 AM
  Release 4.1.1
  Microcode 8.2
  Runtime 11.4
  Features 1.2
  Cross 11.1
  Unix Interface 1.2

1 ]=> (dump-world "myScheme")

Failure operating on scheme

Anomalous error -- get a wizard 23
There is no environment available;
using the current read-eval-print environment.

The error also occurs when usinmg a full pathname in place of "myScheme".

Any ideas would be appreciated.

Mike Gigante	mg%cidam.oz@seismo.css.gov  munnari!cidam.oz!mg@seismo.css.gov
Royal Melbourne Institute of Technology, Australia

∂23-Mar-87  0752	@MC.LCS.MIT.EDU:muller@bu-cs.bu.edu 	Scheme mode in GNU Emacs    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Mar 87  07:51:51 PST
Received: from bu-cs.bu.edu (TCP 30003134401) by MC.LCS.MIT.EDU 23 Mar 87 10:51:43 EST
Received: from bucse.bu.edu by bu-cs.bu.edu (3.2/4.7)
	id AA20861; Mon, 23 Mar 87 10:45:26 EST
Return-Path: <muller@bu-cs.bu.edu>
Received: by bucse.bu.edu (5.31/4.7)
	id AA03759; Mon, 23 Mar 87 10:47:11 EST
Date: Mon, 23 Mar 87 10:47:11 EST
From: muller@bu-cs.bu.edu
Message-Id: <8703231547.AA03759@bucse.bu.edu>
To: scheme@MC.LCS.MIT.EDU
Subject: Scheme mode in GNU Emacs


Has anyone out there taken the time to rewrite the Scheme support for
GNU Emacs so that it understands R↑3 Scheme syntax? In particular I'd like
to use the Scheme84 "[" and "]" for parentheses and have the indentation
and balancing come out right. Inferior scheme mode also seems to be
intolerant of vt200 series terminals. Has anyone repaired this?

Thanks

bob

∂23-Mar-87  0850	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	Scheme mode in GNU Emacs 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Mar 87  08:50:25 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 23 Mar 87 11:49:51 EST
Received: by GENEVA.AI.MIT.EDU; Mon, 23 Mar 87 11:46:14 est
Date: Mon, 23 Mar 87 11:46:14 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8703231646.AA09139@geneva>
To: muller@bu-cs.bu.edu
Cc: scheme@MC.LCS.MIT.EDU
In-Reply-To: muller@bu-cs.bu.edu's message of Mon, 23 Mar 87 10:47:11 EST <8703231547.AA03759@bucse.bu.edu>
Subject: Scheme mode in GNU Emacs

    Has anyone out there taken the time to rewrite the Scheme support for
    GNU Emacs so that it understands R↑3 Scheme syntax? In particular I'd like
    to use the Scheme84 "[" and "]" for parentheses and have the indentation
    and balancing come out right. Inferior scheme mode also seems to be
    intolerant of vt200 series terminals. Has anyone repaired this?

R↑3RS does not define the syntax of [ and ].  That is Scheme84 and
ChezScheme specific (as far as I know).  You can probably do that
by copying the syntax table entries from ( and ) to [ and ],
respectively.

The currently released version of the GNU Emacs scheme support matches
MIT CScheme release 4, which is not 100% compatible with R↑3RS.  As
soon as we make our 5th release, 100% compatible with R↑3RS (in a
couple of weeks, if all goes well), a new version of the interface
will be released.  It will not support [ and ], since that is not a
"feature" of MIT Scheme (some of us think it is a really bad idea).

The released version of inferior Scheme mode does nothing which is
terminal dependent, so there must be a bug in GNU Emacs which is
manifesting itself in this mode.  Are you using MIT Scheme as the
inferior scheme?

∂23-Mar-87  2309	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET 	Looking for comments on an introductory article about Scheme    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Mar 87  23:08:57 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 24 Mar 87 02:09:48 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa19225; 24 Mar 87 1:56 EST
Received: from switzerland by RELAY.CS.NET id aa15408; 24 Mar 87 1:52 EST
Received: from ean by SWITZERLAND.CSNET id a013971; 24 Mar 87 7:44 WET
From: "Daniel K. Schneider" <shneider%cui.unige.chunet@RELAY.CS.NET>
To:  scheme@MC.LCS.MIT.EDU
MMDF-Warning:  Parse error in original version of preceding line at SWITZERLAND.CSNET
Message-ID: <211:shneider@cui.unige.chunet>
Subject: Looking for comments on an introductory article about Scheme

    I just finished an introductory article about Scheme which is due by the
end of this week (sorry) and which will appear in the SGAICO/SI Newsletter.
SGAICO (Swiss Group for AI and CO) is a special interest group of SI (Swiss
ACM Chapter)

TOPIC: 1. Philosophy and History of Scheme 
          (lots of quotes from the R↑3 appendix and S&ICP)
       2. The language
          (inspired by R↑3 and the banking account of S&ICP)
       3. List of implementations
       4. A review of PC Scheme

    I wonder, if any kind soul out there could have a look at it and make
some comments and/or corrections. The article is certainly *not* worth
looking at, but for somebody it might be important that the Swiss get the
good things right. :)

    The whole thing is written by an amateur, who does not want to clutter up
this mailing list. If anybody has some spare time, please reply. I can send
you either a Scribe file or a semi-formatted thing. If REPLY does not work,
try one of the addresses below.

Thanks - Daniel
-------------------------------------------------------------------------------
Daniel K.Schneider
ISSCO, University of Geneva, 54 route des Acacias, 1227 Carouge (Switzerland)
Tel. (..41) (22) 20 93 33 ext. 2114
          to VMS/BITNET:                    to UNIX/EAN (preferable):
BITNET:   SCHNEIDER@CGEUGE51                shneider%cui.unige.chunet@CERNVAX
ARPA:     SCHNEIDER%CGEUGE51.BITNET@WISCVM  shneider@cui.unige.CHUNET
                                        or: shneider%cui.unige.chunet@ubc.csnet
uucp:                                       mcvax!cernvax!cui!shneider   

∂24-Mar-87  1029	@MC.LCS.MIT.EDU:wand%corwin.ccs.northeastern.edu@RELAY.CS.NET 	Scheme mode in GNU Emacs   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Mar 87  10:29:06 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 24 Mar 87 12:58:00 EST
Received: from relay2.cs.net by RELAY.CS.NET id af22835; 24 Mar 87 12:37 EST
Received: from northeastern.edu by RELAY.CS.NET id ak18416; 24 Mar 87 12:33 EST
Received: from corwin.ccs.northeastern.edu by
           nuhub.acs.northeastern.edu; Tue, 24 Mar 87 11:06 EST
Received: by corwin.CCS.Northeastern.EDU (5.51/5.17)
	id AA13177; Tue, 24 Mar 87 11:00:39 EST
Date: Tue, 24 Mar 87 11:00:39 EST
From: wand%corwin.ccs.northeastern.edu@RELAY.CS.NET
To: muller@BU-CS.BU.EDU
Cc: scheme@MC.LCS.MIT.EDU
In-Reply-To: muller@bu-cs.bu.edu's message of Mon, 23 Mar 87 10:47:11 EST
Subject: Scheme mode in GNU Emacs

Yes, I have a modified version of scheme.el (and shell.el) to do the right
thing with [] and also to run scheme as an inferior process reasonably.

I will mail it if anyone is interested.

Mitch Wand




∂25-Mar-87  0925	@MC.LCS.MIT.EDU:mcvax!crcge1!adams@seismo.CSS.GOV 	scheme mailing list
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87  09:25:04 PST
Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU 25 Mar 87 12:25:21 EST
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA05803; Wed, 25 Mar 87 12:20:10 EST
Received: by mcvax.cwi.nl; Wed, 25 Mar 87 18:19:22 +0100 (MET)
Received: by inria.inria.fr; Wed, 25 Mar 87 17:42:51 +0100 (MET)
Received: by crcge1.DIN; Wed, 25 Mar 87 13:25:34 -0100
Date: Wed, 25 Mar 87 13:25:34 -0100
From: mcvax!crcge1!adams@seismo.CSS.GOV (Drew Adams)
Message-Id: <8703251225.AA16715@crcge1.DIN>
To: scheme@mc.lcs.mit.edu
Subject: scheme mailing list

Please place me on your mailing list.  Thanks.

Drew ADAMS, Laboratoires de Marcoussis, Centre de Recherche de la Compagnie 
            Generale d'Electricite, Route de Nozay, 91460 MARCOUSSIS, FRANCE
            Tel. 64.49.11.54, seismo!mcvax!inria!crcge1!adams

∂26-Mar-87  0235	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET 	Private message to Cynthia Mason. (mail problem) 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87  02:34:51 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 26 Mar 87 05:35:09 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa08512; 26 Mar 87 5:30 EST
Received: from switzerland by RELAY.CS.NET id aa00706; 26 Mar 87 5:23 EST
Received: from ean by SWITZERLAND.CSNET id a020472; 26 Mar 87 11:15 WET
From: "Daniel K. Schneider" <shneider%cui.unige.chunet@RELAY.CS.NET>
Sender: "Daniel K. Schneider" <shneider%cui.unige.chunet@RELAY.CS.NET>
To:  scheme@MC.LCS.MIT.EDU
MMDF-Warning:  Parse error in original version of preceding line at SWITZERLAND.CSNET
Message-ID: <222:shneider@cui.unige.chunet>
Subject: Private message to Cynthia Mason. (mail problem)

Sorry, I can't get back to you, something in your adress got chewed up,
(probably by your mailer). I tried Arpa, but it did not work.

I get this: Cynthia Mason 423-9404 <clm@lll-zaphod.a>

Send me your message again with your address included *in* the message text.
preferably one of: ARPA/EDU, uucp, cs-net, BITNET

∂26-Mar-87  0356	@MC.LCS.MIT.EDU:shneider%cui.unige.chunet@RELAY.CS.NET 	Correction mistake: Looking for comments on an introductory article ..    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87  03:55:50 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 26 Mar 87 06:43:59 EST
Received: from relay2.cs.net by RELAY.CS.NET id aa08831; 26 Mar 87 6:37 EST
Received: from switzerland by RELAY.CS.NET id aa00959; 26 Mar 87 6:31 EST
Received: from ean by SWITZERLAND.CSNET id a020686; 26 Mar 87 12:20 WET
From: "Daniel K. Schneider" <shneider%cui.unige.chunet@RELAY.CS.NET>
To:  scheme@MC.LCS.MIT.EDU
MMDF-Warning:  Parse error in original version of preceding line at SWITZERLAND.CSNET
Message-ID: <223:shneider@cui.unige.chunet>
Subject: Correction mistake: Looking for comments on an introductory article ..

>    I just finished an introductory article about Scheme which is due by the
>end of this week (sorry) and which will appear in the SGAICO/SI Newsletter.

SORRY, I goofed ↑↑↑ , this article (cf. my posting march 24th)
is due in three weeks only.
(for those who wanted to look at it actually, but couldn't this week !)

- d.s.

PS: I am amazed, I already got 5 replies (BIG thanks to the scheme community)



∂27-Mar-87  1850	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	multiple return values
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Mar 87  18:49:52 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 27 Mar 87 21:55:00 EST
Received: from relay2.cs.net by RELAY.CS.NET id ac29893; 27 Mar 87 21:49 EST
Received: from tektronix.tek.com by RELAY.CS.NET id ah11897; 27 Mar 87 21:42 EST
Received: by tektronix.TEK.COM (5.51/6.20)
	id AA14104; Fri, 27 Mar 87 15:48:41 PST
Received: by tekchips.TEK.COM (5.31/6.19)
	id AA03757; Fri, 27 Mar 87 15:47:10 PST
Message-Id: <8703272347.AA03757@tekchips.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: multiple return values
Date: 27 Mar 87 15:47:06 PST (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET

Our previous round of discussions on multiple return values reached
no consensus.  I want to try again with the very simple, specific
proposal that follows.  The proposal consists of additions and changes
to the formal semantics that appears in R3RS, an informal description,
and a rationale.


FORMAL SEMANTICS

[Notation: The "\" character should be read as a Greek lambda,
and the "!" character should be read as a down-arrow.]

Add a procedure RECEIVE-VALUES whose semantics is given by

    receive_values: E* --> K --> C

    receive_values
      = twoarg (\ e1 e2 k . applicate e1 <> (\ e* . applicate e2 e* k))

Add a procedure RETURN-VALUES whose semantics is given by

    return_values: E* --> K --> C

    return_values = \ e* k . k e*

Either leave the equation of the auxiliary function "single" as is
(equation 1 below), or change it as indicated in equation 2 or as
indicated in equation 3.

    single: (E --> C) --> K

 1. single = \ f e* . # e* = 1 --> f (e* ! 1), wrong "..."

 2. single = \ f e* . # e* >= 1 --> f (e* ! 1), wrong "..."

 3. single = \ f e* . # e* >= 1 --> f (e* ! 1), f unspecified


INFORMAL DESCRIPTION

(RECEIVE-VALUES thunk proc)                                procedure

The first argument is a procedure of no arguments, the second is any
procedure.  Calls the first argument, obtaining 0 or more return
values, and then calls the second argument on the value(s) returned
by the first argument.  See RETURN-VALUES.

    (receive-values (lambda () (return-values 3 7))
                    (lambda (a b) (* a b)))         -->  21



(RETURN-VALUES x ...)                                      procedure

Takes any number of arguments, and returns them as multiple return
values.  [See the rationale for a discussion of how many return values
a continuation expects, and the error conditions that may result when
the expectations are not met.]  See RECEIVE-VALUES.

    (receive-values (lambda () (return-values 'a 'b 'c))
                    vector)                          -->  #(a b c)

    (letrec ((f (lambda (x) (if (zero? x) (g x) (g x))))
             (g (lambda (x) (return-values x (- x))))
             (h (lambda (x)
                  (receive-values (lambda () (f x)) list))))
      (h 3))
                                        -->  (3 -3)

    (letrec ((f (lambda (x) (+ (g x) 13)))
             (g (lambda (x) (return-values x (- x))))
             (h (lambda (x)
                  (receive-values (lambda () (f x)) list))))
      (h 3))
                                        -->  error [equation 1]
                                        -->  (16)  [equation 2 or 3]

    (receive-values (lambda () (return-values)) vector)  -->  #()

    (receive-values (lambda () (return-values 1))
                    (lambda (x . y) y))
                                        -->  ()

    (receive-values (lambda () (return-values))
                    (lambda (x . y) y))
                                        -->  error

    (list (return-values 'a 'b 'c 'd))  -->  (a)

    (car (list (return-values)))  -->  error       [equation 1 or 2]
                                  -->  unspecified [equation 3]


RATIONALE

This proposal is along the lines of multiple return values as in
Common Lisp, but is somewhat simpler and more rational.  The simplicity
of the proposal, as compared to the exposition in CLtL, is attributable
to a better choice of primitives and to Scheme's tail-recursive semantics.

RECEIVE-VALUES and RETURN-VALUES correspond to T3's RECEIVE-VALUES
and RETURN.  The name "RETURN" was rejected because it would confuse
people who are accustomed to the use of RETURN in Common Lisp and
similar Lisps.  Note that these are procedures, not syntax, and that
neither would be essential Scheme.

The arguments to RECEIVE-VALUES are reversed from the way they are in T3.
Feel free to argue the argument order.

Argue also about which equation we should choose for "single".  It
determines what happens in the case where RETURN-VALUES returns to a
continuation that was not created by RECEIVE-VALUES.  Equation 1 says
that in such a case there must be exactly one return value.  Equation 2
says that in such a case there must be at least one value; the extra
values are ignored.  Equation 3 allows zero return values, in which case
the value received by the continuation is unspecified.  No matter which
equation is chosen, there is no difference between returning a single
value in the usual way and returning a single "multiple value" using
RETURN-VALUES.

I didn't give equations for the extreme positions.  The fascist position
would say that it is always an error for RETURN-VALUES to return to a
continuation that was not created by RECEIVE-VALUES.  The commonlisp
position would say that when zero values are returned to a continuation
that is expecting one value, then the symbol NIL is passed to the
continuation.  If there is sufficient demand, I will post equations for
these.

If we interpret the use of "wrong" in the semantic equations to mean
"is an error" instead of "signals an error", then all of the equations
allow implementations in which Scheme multiple return values are
compatible with the semantics of Common Lisp's multiple return values.
This should make it easier to support a Scheme subset in Common Lisp or
vice versa.

I see no way to implement the proposed procedures in R3RS Scheme, but
most implementations should find it easy to add them.

William Clinger

∂27-Mar-87  1858	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	Let's get together again   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Mar 87  18:58:21 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 27 Mar 87 21:58:11 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab29893; 27 Mar 87 21:49 EST
Received: from tektronix.tek.com by RELAY.CS.NET id ag11897; 27 Mar 87 21:42 EST
Received: by tektronix.TEK.COM (5.51/6.20)
	id AA12620; Fri, 27 Mar 87 15:14:08 PST
Received: by tekchips.TEK.COM (5.31/6.19)
	id AA03301; Fri, 27 Mar 87 15:12:35 PST
Message-Id: <8703272312.AA03301@tekchips.TEK.COM>
To: rrrs-authors@MC.LCS.MIT.EDU
Subject: Let's get together again
Date: 27 Mar 87 15:12:31 PST (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET

It's been the better part of a year since many of us got to see each
other at the 1986 Lisp conference, and two and a half years since we
got together at Brandeis.  The next X3J13 (Common Lisp) meeting will
be in Boston or Cambridge 30 June and 1 July (a Tuesday and Wednesday),
so David Bartley and I would like to suggest that we meet in Cambridge
to discuss Scheme standardization issues on Thursday, 2 July, possibly
spilling over into Friday morning, 3 July.  We need volunteers to
arrange for a room, prepare an agenda, and chair the meeting.

Some issues that Bartley and I would like to see resolved are:

    multiple return values
    customizable reader
    number syntax and exactness
    macros
    optional arguments
    structures and opaque objects
    environments
    modules

These are in rough order of our priorities, where we give priority to
things that can be standardized easily as well as to things that are
important.  We'll be posting some proposals to this mailing list in
hopes of generating some thought, interest, or at least discussion
before we next get together.

Another thing we should talk about is what we want to come after Scheme.

Peace,
Will Clinger
Tektronix, Inc.

∂27-Mar-87  2120	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple return values   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Mar 87  21:20:19 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 28 Mar 87 00:06:45 EST
Date: Sat, 28 Mar 87 00:03:12 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  multiple return values
To: willc%tekchips.tek.com@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 27 Mar 87 15:47:06 PST (Fri) from willc%tekchips.tek.com at RELAY.CS.NET
Message-ID: <174983.870328.JAR@AI.AI.MIT.EDU>

    Date: 27 Mar 87 15:47:06 PST (Fri)
    From: willc%tekchips.tek.com at RELAY.CS.NET

        single: (E --> C) --> K

     1. single = \ f e* . # e* = 1 --> f (e* ! 1), wrong "..."

     2. single = \ f e* . # e* >= 1 --> f (e* ! 1), wrong "..."

     3. single = \ f e* . # e* >= 1 --> f (e* ! 1), f unspecified

I have already put in my vote for 1.


    I see no way to implement the proposed procedures in R3RS Scheme, but
    most implementations should find it easy to add them.

If "wrong" doesn't imply "signals an error" then the following is a
correct implementation of alternative 1.  This is pretty much how the
feature was implemented in T2.


(define values-marker (list 'values-marker))

(define receive-values
  (lambda (thunk proc)
    (let ((vals (thunk)))
      (if (and (pair? vals) (eq? (car vals) values-marker))
	  (apply proc (cdr vals))
	  (proc vals)))))

(define return-values
  (lambda vals
    (cons values-marker vals)))


I think that the fact that this is so easy is a significant reason to
favor alternative 1.

----

I find the feature to be pretty unuseable unless there is some
syntactically sugared way to use RECEIVE-VALUES (viz. T's RECEIVE
and CL's MULTIPLE-VALUE-BIND), but maybe this issue can be argued
separately.

Jonathan


∂28-Mar-87  1146	@MC.LCS.MIT.EDU:KMP@YUKON.SCRC.Symbolics.COM 	Let's get together again
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Mar 87  11:46:31 PST
Received: from YUKON.SCRC.Symbolics.COM (TCP 30002424403) by MC.LCS.MIT.EDU 28 Mar 87 14:51:46 EST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 185960; Sat 28-Mar-87 14:36:06 EST
Date: Sat, 28 Mar 87 14:35 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Let's get together again
To: willc%tekchips.tek.com@csnet-relay
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-Reply-To: <8703272312.AA03301@tekchips.TEK.COM>
Message-ID: <870328143552.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I'm all for getting together, but because my (paid) job is Lisp and not
Scheme, I'd be happier if it were over a weekend so I wouldn't have to
take time away from work. Also, many of the X3J13 participants will be
arriving for Monday subcommittee meetings and if they came Saturday, 
they could get cheaper fares. Note, too, that Thursday/Friday is 4th
of July weekend and not everyone will necessarily want to spend that time
in Boston -- though certainly I plan to be there so this last point is
not a problem for me, just another possible reason why the weekend before
(27-28 June) might be better for meeting.


∂28-Mar-87  1400	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	Let's get together again 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Mar 87  14:00:04 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 28 Mar 87 16:14:05 EST
Received: by GENEVA.AI.MIT.EDU; Sat, 28 Mar 87 16:11:21 est
Date: Sat, 28 Mar 87 16:11:21 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8703282111.AA05557@geneva>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: willc%tekchips.tek.com@csnet-relay, RRRS-Authors@MC.LCS.MIT.EDU
In-Reply-To: Kent M Pitman's message of Sat, 28 Mar 87 14:35 EST <870328143552.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Let's get together again

I agree with KMP.  I think the weekend before, if at all possible,
would be better.

I also think that a new meeting would be a good idea.

∂28-Mar-87  2023	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	a modest macro proposal  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Mar 87  20:22:59 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 28 Mar 87 23:28:18 EST
Date: Sat, 28 Mar 87 23:24:42 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  a modest macro proposal
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <175356.870328.JAR@AI.AI.MIT.EDU>

			  Macros for Scheme
			    Jonathan Rees
			    28 March 1987

Primary objectives:

  - Macros are scoped, so users won't step on each others' toes.

  - The client of a macro need not know anything about the macro's
    implementation.  In particular, capture problems must be avoidable
    both for syntactic keywords and variables.

Secondary objectives:

  - Consistent with the "expansion passing style" described
    in [1].

  - Consistent with the spirit of the macro facilities provided by
    MIT Scheme and T.

This is a rough draft, and contains more questions than answers, but I
want to get feedback, and answers to the questions, so here it is.



Overview:

  1. Fundamental mechanism
        Describes the basic ideas of syntax tables and preprocessed
	expressions.

  2. Defining macros
        Describes two new expression types that introduce scoped macro
	definitions.

  3. Avoiding free variable capture
        Describes ways to circumvent capture problems.

  4. Convenience features
        Discusses higher-level layers that could make macro writing
	easier.

  5. Notes and questions

  Appendix. An implementation



1. Fundamental mechanism

Two abstractions are introduced, "syntax table" and "preprocessed
expression".  A "syntax table" describes a particular mapping from
concrete syntax (expressions) to abstract syntax (preprocessed
expressions).  When a user defines a macro, he implicitly defines a
variant on the language and therefore a new mapping from expressions
to preprocessed expressions.


1.1. Reference guide

(For the purposes of this discussion, the term "expression" means
"s-expression", or more precisely:
    - Symbols, numbers, booleans, characters, strings, and empty lists
      are expressions.
    - If E1 and E2 are expressions then the pair (E1 . E2) is an
      expression.  (In particular, lists of expressions are
      expressions.)
    - If E0, ... En are expressions, then the vector #(E1 ... En) is
      an expression.
    - A preprocessed expression is an expression.
    - There are no other expressions.)

(PREPROCESS expression syntax-table)

  PREPROCESS preprocesses expression according to syntax-table,
  and returns a preprocessed expression.  The manner in which
  the preprocessed expression is determined depends entirely on the
  syntax table argument (see the various ways to create syntax tables,
  below), with the following exception: (PREPROCESS p syntax-table)
  always returns p if p is already a preprocessed expression.

  It is an error if expression is not syntactically valid according
  to syntax-table.

SCHEME-SYNTAX-TABLE

  The value of SCHEME-SYNTAX-TABLE is a syntax table that corresponds
  to a language conforming to the Revised↑3 Report.  In gory detail,
  this means: let E be an expression, and let P be the preprocessed
  expression that results from calling
  (PREPROCESS E SCHEME-SYNTAX-TABLE).

    - If E is a number, boolean, string, or character, then P denotes
      an appropriate literal expression.
    - If E is a symbol, and E is not a Scheme syntactic keyword (QUOTE,
      LAMBDA, etc.), then P denotes a variable reference.
    - If E is a pair whose car is a syntactic keyword, then P denotes
      an appriopriate expression (unless it contins a syntax error).
    - If E is a nonempty list whose car is an expression, then P denotes a
      combination (unless some subexpression contains a syntax error).
    - If E is already a preprocessed expression, E is equal to P.
    - Otherwise E is not syntactically valid.

(ADD-KEYWORD syntax-table symbol expansion-proc)

  Expansion-proc must be a procedure of two arguments, an expression
  and a syntax table.  Expansion-proc must return a preprocessed
  expression.

  ADD-KEYWORD returns a new syntax table according to which
  expressions of the form (symbol ...) are preprocessed by
  expansion-proc.  That is, PREPROCESS will call expansion-proc and
  return what it returns.  The arguments passed to expansion-proc will
  be the expression and syntax-table that were passed to PREPROCESS.

  Any other expression E is preprocessed the same way it would have
  been preprocessed according to syntax-table.  If this means that it
  is to be preprocessed according to SCHEME-SYNTAX-TABLE, then any
  subexpressions of the expression will be preprocessed according to
  the syntax table that was originally passed to PREPROCESS, not
  according to SCHEME-SYNTAX-TABLE.

(REMOVE-KEYWORD syntax-table symbol)

  This returns a syntax table in which an expression of the form
  (symbol ...) denotes a combination.  If symbol had an associated
  expansion procedure in syntax-table, that expansion procedure will
  be ignored in the new syntax table.


1.2. Discussion

The following may be a helpful analogy:

   (EVAL                      (PREPROCESS
      lambda-expression	         expression
      environment)		 syntax-table)
    => closure		       => preprocessed-expression

EVAL (or the ENCLOSE of the Revised Report) takes a lambda-expression,
which is context-dependent or "open" because it contains free
variables, and turns it into something that's context-independent or
"closed", namely a closure.  PREPROCESS takes an expression, which is
context-dependent because the meanings of subexpressions depend on
what macros are in effect, and returns something that is
context-independent and therefore immune to the vagaries of the macro
context into which it may be placed.

Preprocessed expressions may legitimately appear as subexpressions of
expressions to be passed to PREPROCESS.  For example, if M1 and M2 are
preprocessed-expressions, then `(AND ,M1 ,M2) is a valid expression
that can be passed again to PREPROCESS (assuming AND has its usual
meaning).  The effect of this is the same as if the expression had
been an AND-expression whose subexpressions were expressions that
would have been preprocessed as M1 and M2 in whatever syntax-table was
the second argument to the call to PREPROCESS.

The nature of "preprocessed-expression" objects is not specified here;
they may or may not be lists, vectors, procedures, etc., or objects of
some new data type.  This proposal does not provide any explicit
operations on preprocessed expressions, but it doesn't preclude such
operations, either.  Presumably LOAD, EVAL, and compilers know how to
manipulate preprocessed-expressions.  Similarly, there may be
operations on syntax tables other than the ones given here; in
particular the clever tricks in [1] could easily work in this
framework.

Note that the syntax table passed to an expansion procedure is not
necessarily the same as the syntax table returned by the call to
ADD-KEYWORD that defined its keyword.  The syntax table is the
appropriate one to use in processing subexpressions.  The syntax table
argument serves the same purpose as the expansion procedure passed to
expanders in [1].

Detail: definitions, as well as expressions, may be passed to
PREPROCESS.


1.3. Examples

Example 1: The following evaluates to a syntax table that is the
same as that for R↑3R Scheme except that FOO is a syntactic keyword and
(FOO x) means the same as (QUOTE x).

  (add-keyword scheme-syntax-table 'foo
    (lambda (e st)
      (preprocess `(quote ,(cadr e)) scheme-syntax-table)))

This illustrates the general principle that a more complicated
syntax-table can be defined in terms of a simpler one.  An expression E
written in a more complicated language L (not even known at macro
definition time) is transformed into a new expression (the expansion),
and then the preprocessed version of the new expression is determined
according to a syntax-table that is known by the expansion procedure to
support the QUOTE keyword in the expected way.

Example 2: The following procedure will augment a given syntax table
with a definition of a simple LET macro.

  (define (add-let st)
    (add-keyword st 'let
      (lambda (exp st)
	(let ((bindings (cadr exp))
	      (body (cddr exp)))
	  (preprocess `((lambda ,(map car bindings)
			  ,@(map (lambda (exp)
				   (preprocess exp st))
				 body))
			,@(map (lambda (binding)
				 (preprocess (cadr binding) st))
			       bindings))
		      scheme-syntax-table)))))

The fact that preprocessed-expressions act like normal forms permits the
use of ordinary list constructors (like backquote) in constructing
partially preprocessed expressions.

Note that PREPROCESS is used within expansion procedures for two
distinct purposes:

(a) To compute a preprocessed expression, in the current syntax table,
    for each sub-expressions of the expression being expanded.

(b) To preprocess, according to some known syntax table, an expression
    that has been determined to be equivalent to the original expression.

Why are syntax tables immutable?  This aids (but doesn't guarantee)
consistency between compiled and interpreted code.


2. Defining macros

2.1. LET-SYNTAX

(LET-SYNTAX (((keyword exp-var st-var) . expansion) ...) . body)

  LET-SYNTAX is used to define a macro that is local to a single
  expression (in practice it is often wrapped around most of a file).
  (T and MIT Scheme both have constructs like this.)

  For example,

    (let-syntax (((foo exp st)
		  (preprocess `(quote ,(cadr exp)) scheme-syntax-table)))
      (foo (a b c)))

     =>  (a b c)

  LET-SYNTAX need not be primitive, assuming there exists an EVAL
  procedure and some environment EXPANDER-ENV in which to close
  expansion procedures.  The following adds a LET-SYNTAX expression
  type to any syntax table S:

  (add-keyword S 'let-syntax
    (lambda (exp st)
      (do ((specs (cadr exp) (cdr specs))
	   (st st
	       (let ((spec (car specs)))
		 (add-keyword st (caar spec)
			      (eval `(lambda ,(cdar spec)
				       ,@(cdr spec))
				    expander-env)))))
	  ((null? specs)
	   (preprocess `(begin ,@(map (lambda (exp)
					(preprocess exp st))
				      (cddr exp)))
		       scheme-syntax-table)))))

  In order to reduce the possibility that a macro could accidentally
  or intentionally depend on some run-time binding, it is
  strongly advised to make the environment in which expanders
  are closed be disjoint from the environment in which the expanded
  code will be run.  Otherwise one could find oneself in the embarrasssing
  situation of having code that "works" in an incrementally compiled
  implementation but not in a block- or cross-compiled implementation.


2.2. USING-SYNTAX

  (USING-SYNTAX syntax-table-exp . body)

  USING-SYNTAX lets one make use of some specific macro environment.

    (using-syntax scheme-syntax-table (quote yow))  =>  yow

  (add-keyword syntax-table 'using-syntax
    (lambda (exp syntax-table)
      ;; ignore syntax-table
      (let ((syntax-table (eval (cadr exp) expander-env)))
	(preprocess `(begin ,@(map (lambda (exp)
				     (preprocess exp syntax-table))
			     (cddr exp)))
		    scheme-syntax-table))))

Subtle point:

For these two forms, it might make just as much sense, and perhaps more,
to say

  (eval (preprocess foo syntax-table) expander-env)
as
  (eval	            foo               expander-env) --

i.e. macros can be written using the macros in effect where the text of
the macro definition occurs, even if they can't make use of the lexical
environment.



3. Avoiding free variable capture

3.1. Free variables introduced into expansions

We want to be able to do things like

  (let ((cons +))
    `(a ,(cons 1 2) b))

and not lose when QUASIQUOTE expanding into a call to CONS.  It
doesn't work to write (as Dan Friedman and others have suggested)

  `(',car ,z)

in the definition of QUASIQUOTE because this presents horrible questions
about the meaning of cross-compilation that no one is prepared to
answer right now.

Kohlbecker's solution amounts to performing alpha-conversion and macro
expansion at the same time.  This is a lot of mechanism and breaks
down in a few places.  Here is a much simpler, low-tech solution.

The solution is for the expander to introduce special expressions into
the expansion that represent "absolute" or "global" references.
Such references are not sensitive to the lexical environment.

(ABSOLUTE node1 node2 ...)         [syntax]

  Finds a value in an implementation-dependent, tree-structured
  namespace.  Each node_i should be an identifier; this is to be
  considered analogous to a Multics-style pathname >node1>node2>....

  In order to make it as easy as possible, Scheme implementors are
  urged to cooperate in apportioning sections of this namespace so that
  there no conflicts can arise.  This is an aministrative problem 
  analgous to domain naming on the Internet, and perhaps solvable by
  similar means.

  Only one portion of the namespace is defined here, namely that the
  top-level SCHEME-ENV node has as subnodes all the names in the
  initial R↑3R Scheme environment.  E.g.

    (let ((+ -))
      ((absolute scheme-env +) 1 2))    =>  3

(Note that ABSOLUTE must be a new kind of expression -- a procedure
can't so the trick, since that would beg the question of how to name
THAT procedure.)


3.2. Bound variables introduced into the expansion

The flip side of this problem is that macros often want to introduce
new bound variables into expansions, and we don't want these names to
accidentally conflict with names already used in the client's code.

Common Lisp (Maclisp, etc.) programmers don't consider this to be a
problem, since GENSYM and GENTEMP exist.  T has GENERATE-SYMBOL (?) and
MIT Scheme has GENERATE-UNINTERNED-SYMBOL.  I think something like
this would do the trick.  However, I would very much like to
preserve the invariant

  (EQ? SYM (STRING->SYMBOL (SYMBOL->STRING SYM))).

which is violated by GENSYM (and GENERATE-UNINTERNED-SYMBOL).

One solution, with a well-defined semantics, would be to have a
procedure that returns a symbol not ocurring in a given expression
(or expressions):

  (SYMBOL-NOT-OCCURRING-IN exp)  =>  symbol

This has a nice functional flavor to it, but it could be implemented
nondeterministically, in such a way that only the symbol table need be
examined, not exp itself.  (I think T3 does this.)

Another possibility would be to apportion some subset of the set of
all symbols for use as "unique identifiers", e.g. all symbols starting
with some "obscure" prefix, not necessarily even readable (although
read/print symmetry is also a nice feature...).

I don't want to make a concrete proposal at this time.


4. Convenience features

Writing correct macros using ADD-KEYWORD is possible, but cumbersome
and error prone.  One must remember to call PREPROCESS on
sub-expressions and on the final output, passing the correct syntax
table to each.

There are several possible ways to address this problem.  One is to
say that we should not be in the business of making it easy to write
macros, but instead should do what we can to discourage users from
writing macros, or at least make them recognize the pitfalls.  In this
view, the complexity of the process is good.

A second solution is Kohlbecker's "hygienic expansion", which makes it
easy to write correct macros.  I suspect this mechanism could be
implemented in terms of the low-level primitives given above, but I
think it has some drawbacks; there are many useful kinds of macros that
can't be written.

I am working on a third solution that, loosely speaking, makes use of
a syntactic description (BNF-like) of the expression type in order to
preprocess subexpressions before handing them to the expansion procedure.
The result is more verbose than hygienic macros and only a little more
verbose than Common Lisp's macros.


5. Notes and open questions

5.1. Compatibility notes

T and MIT Scheme already have syntax tables, but they're mutable.
Expansion procedures are called "syntax descriptors" in T.  T has a
MACRO-EXPANDER macro that creates expansion procedures.  MIT Scheme has
a MACRO macro for the same purpose.

In MIT Scheme, the syntax table is passed implicitly as a fluid-bound
variable.  In T, it is possible to get at the syntax table, as an extra
argument to an expander, but it's painful.  In Common Lisp, the
syntax-table corresponds roughly to the &environment argument to macros
(except that in CL you are forbidden to redefine a special
form -- this proposal permits that).

PREPROCESS is similar to the SYNTAX procedure in MIT Scheme, and
vaguely similar to STANDARD-COMPILER in T.

ABSOLUTE is similar to MIT Scheme's ACCESS.  In ACCESS, the last
subform is evaluated, which isn't quite what we want, since that makes
it context-sensitive again (although this greatly reduces
opportunities for lossage).  [Also, I find the argument order to
ACCESS confusing; it's backwards from the way filenames are usually
written (on Multics and Unix at least) and also backwards from things
like VECTOR-REF, where the aggregate or superior object comes first.]



5.2. Syntax table used by LOAD and/or command loop

1. Which syntax table is used to process forms read by LOAD?

2. Which syntax table is used to process forms typed at a
   read-eval-print loop?

3. How can one perform definitions in the environment that will
   be seen by USING-SYNTAX?

Here is one conservative proposal, although there are many
possibilities and variations:

The top level syntax-table for any file is initially
SCHEME-SYNTAX-TABLE.  Changes must be made explicitly via USING-SYNTAX
or LET-SYNTAX, which should be wrapped around the enire file if
necessary.

The syntax table used at the read-eval-print loop is changed in some
implementation-dependent manner (there's nothing that even says there
IS a read-eval-print loop).  E.g. there could be a procedure
(SET-CURRENT-SYNTAX-TABLE! syntax-table).


5.3. Keywords and variables

Several people have complained that

  (let ((if list))
    (if 1 2 3))

ought, according to the rules of lexical scope, to evaluate to (1 2 3).
It is possible in this framework to make syntax-tables in which variable
bindings shadow syntax bindings, but it requires cooperation from
every macro that binds variables (LET, LETREC, LAMBDA, etc.):

  (add-syntax foo 'lambda
    (lambda (exp st)
      ... (do ((vars vars (cdr vars))
	       (st st (remove-syntax (car vars) st)))
	      ...) ...))

I'd rather not raise this question here since it's really orthogonal to
the rest of this proposal.


5.4. Macros that expand into multiple definitions

The syntax of <program> should be extended to include sequence
expressions:

      <program>  -->  <top>*
      <top>	 -->  <definition>
		   |  <expression>
		   |  (begin <top>+)

This is so that macros at top level can expand into multiple
definitions: (begin (define foo ...) (define bar ...)).

There is an ambiguity here in that (begin <expression>+) can be parsed
in either of two ways, but the meaning is the same in either case, so
this isn't a grave problem.

Should the syntax of a <body> be similarly extended to allow
expansions like
   (lambda (...) (begin (define ...) (define ...)) ...)?
What about
   (lambda (...) (begin (define ...) (compute ...)) ...)?
What about 
   (lambda (...) (begin (compute ...) (define ...)) ...)?


5.5. Delayed expansion

Some implementations may want to delay macro expansion (preprocessing)
so that the expression tree is processed breadth-first instead of
depth-first.  This could be handy for any number of purposes, e.g. in
preventing propagation of syntax errors, in performing
alpha-conversion in parallel with macro expansion, or to speed up file
loading.  This should be explicitly permitted by the proposal.  The
only way it would make a difference is if a macro expander could
observe or perform a side-effect.


5.6. Analysis of subexpressions

I think it's a bad idea for macros to go snooping into their
subexpressions.  This should be unnecessary for "optimization" (the
main reason people did this in Maclisp); it's hard to come
up with valid reasons to want to do it.

On the other hand, it would be nice if someone writing a compiler
could portably use PREPROCESS as a front end.  This would mandate having
operations for decomposing preprocessed expressions.  One possibility
would be to define a set of accessors and predicates, as MIT Scheme
does.  Another way to do it would be to have one or more coercion
functions to do the inverse of PREPROCESS, e.g. (UNPREPROCESS p-e)
would return an expression e such that

  (PREPROCESS e SCHEME-SYNTAX-TABLE)

would return something equivalent to p-e; then one could use CAR and
CDR to take the result apart.

Either way you have to answer sticky questions, however, such as
whether derived expressions like LETREC should be expanded out or
preserved.


5.7. Other ways to manipulate the keyword/expander association

Maybe we also want MOVE-KEYWORD or RENAME-KEYWORD?




References.

[1] Dybvig, Friedman, and Haynes.  Expansion-passing style:  Beyond
    conventional macros.  1986 ACM Lisp & FP Conference.

[2] Kohlbecker's thesis.

[3] T manual.

[4] Common Lisp.

[5] Revised↑3 Scheme Report.



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

Appendix: a rudimentary implementation.

;;; Preprocessed expressions

(define (preprocessed? obj)
  (and (vector? obj)
       (= (vector-length obj) 2)
       (eq? (vector-ref obj 0) 'preprocessed)))

(define (make-preprocessed core-exp)
  (if (preprocessed? core-exp)
      core-exp
      (vector 'preprocessed core-exp)))

;;; ->CORE translates a preprocessed expression into the core language.

(define (->core exp)
  (if (preprocessed? exp)
      (vector-ref exp 1)
      (error "not a preprocessed expression" exp)))

;;; A syntax table is a procedure, and PREPROCESS is FUNCALL.

(define (preprocess exp st)
  (st exp st))

(define (add-keyword st0 keyword proc)
  (lambda (exp st)
    (if (and (pair? exp) (eq? (car exp) keyword))
	(proc exp st)
	(st0 exp st))))

;;; An empty syntax table; defines no special expression types.

(define empty-syntax-table
  (lambda (exp st)
    (cond ((symbol? exp)
	   (make-preprocessed exp))
	  ((or (boolean? exp) (number? exp) (char? exp) (string? exp))
	   (make-preprocessed exp))
	  ((preprocessed? exp)
	   exp)				;Idempotent!
	  ((not (pair? exp))
	   (error "not a syntactically valid expression" exp))
	  (else
	   ;; Combination
	   ;; (There is a small bug here if REMOVE-KEYWORD exists)
	   (make-preprocessed (map (lambda (arg)
				     (->core (preprocess arg st)))
				   exp))))))

;;; Core syntax table.  Understands the primitive expression types, but
;;; not the derived ones.

(define core-syntax-table
  (do ((st empty-syntax-table
	   (add-keyword st (caar z) (cadar z)))
       (z `((quote
	     ,(lambda (exp st)
		(make-preprocessed exp)))
	    (lambda
	     ,(lambda (exp st)
		(make-preprocessed
		  `(lambda ,(cadr exp)
		     ,(->core (preprocess (caddr exp) st))))))
	    (set!
	     ,(lambda (exp st)
		(make-preprocessed
		  `(set! ,(cadr exp)
			 ,(->core (preprocess (caddr exp) st))))))
	    (define
	     ,(lambda (exp st)
		(make-preprocessed
		  `(define ,(cadr exp)
		     ,(->core (preprocess (caddr exp) st))))))
	    (if
	     ,(lambda (exp st)
		(make-preprocessed
		  `(if ,(->core (preprocess (cadr exp) st))
		       ,(->core (preprocess (caddr exp) st))
		       ,(->core (preprocess (cadddr exp) st))))))
	    (begin
	     ,(lambda (exp st)
		(make-preprocessed
		  `(begin ,@(map (lambda (exp)
				   (->core (preprocess exp st)))
				 (cdr exp))))))
	    (absolute
	     ,(lambda (exp st)
		(make-preprocessed exp))))
	  (cdr z)))
      ((null? z) st)))

;;; The scheme syntax table defines the derived expression types.

(define scheme-syntax-table
  (do ((st core-syntax-table
	   (add-keyword st (caar z) (cadar z)))
       (z `((and
	     ,(lambda (exp st)
		(let ((forms (cdr exp))
		      (j (lambda (exp) (preprocess exp st))))
		  (cond ((null? forms) `#t)
			((null? (cdr forms)) (j (car forms)))
			(else
			 (preprocess
			    `((lambda (p th)
				(if p (th) p))
			      ,(car forms)
			      (lambda () (and ,@(map j (cdr forms)))))
			    scheme-syntax-table))))))
	    ;; ...
	    (lambda
	     ,(lambda (exp st)
		(preprocess
		 `(lambda ,(cadr exp)
		    ,(preprocess-body (cddr exp) st))
		 core-syntax-table)))
	    ;; (letrec ,...)
	    ;; ...
	    ;; (quasiquote ,... (absolute scheme-env cons) ...)
	    )
	  (cdr z)))
      ((null? z) st)))

;;; Implements implicit begin and internal defines for lambda bodies.

(define (preprocess-body body st)
  (let ((definition? (lambda (exp)
		       (and (pair? exp) (eq? (car exp) 'define))))
	(definition-lhs cadr)
	(definition-rhs caddr))
    (let loop ((l (map (lambda (exp)
			 (preprocess exp st))
		       body))
	       (d '()))
      (if (null? l)
	  (error "no non-definitions in body" body)
	  (let ((exp (->core (car l))))  ;Analyze
	    (if (not (definition? exp))
		(preprocess (if (null? d)
				`(begin ,@l)
				`(letrec ,(reverse d) ,@l))
			    scheme-syntax-table)
		(loop (cdr l)
		      (cons `(,(definition-lhs exp)
			      ,(make-preprocessed (definition-rhs exp)))
			    d))))))))

; Fin


∂29-Mar-87  1558	@MC.LCS.MIT.EDU:GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU 	meeting   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Mar 87  15:58:51 PST
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 29 MAR 87  19:04:10 EST
Date: Sun 29 Mar 87 18:57:57-EST
From: "Gerald Jay Sussman" <GJS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: meeting
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <12290358923.7.GJS@OZ.AI.MIT.EDU>

I agree with Will.  I think we should meet and get things under control.
-------

∂30-Mar-87  0917	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	[ALAN: multiple return values]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87  09:17:50 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 30 Mar 87 12:23:13 EST
Date: Mon, 30 Mar 87 12:20:13 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  [ALAN: multiple return values]
To: rrrs-authors@MC.LCS.MIT.EDU
Message-ID: <175971.870330.JAR@AI.AI.MIT.EDU>

Date: Sun, 29 Mar 87 02:29:12 EST
From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
To:   JAR at AI.AI.MIT.EDU
Re:   multiple return values

I will confine myself to reminding you of what I said the last time this
subject was raised:  Any implementation of multiple-values that doesn't
have the property that ordinary continuations (for example the continuation
passed to F in (+ (F) 3)) will accept and ignore extra values has missed
the point of multiple values.

Let me try putting it another way:  If you decide on a semantics for
multiple values that has the property that a correct implementation can be
written in straight R↑3RS Scheme, then what have you accomplished?  You
haven't given the users anything they couldn't have written for themselves.
(Yes, perhaps you can arrange to implement it more efficiently, but since
when has that been the the spirit of the language?)


∂30-Mar-87  1023	@MC.LCS.MIT.EDU:jinx@GENEVA.AI.MIT.EDU 	[ALAN: multiple return values]
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87  10:23:15 PST
Received: from geneva (TCP 2206400372) by MC.LCS.MIT.EDU 30 Mar 87 13:08:03 EST
Received: by GENEVA.AI.MIT.EDU; Mon, 30 Mar 87 13:04:33 est
Date: Mon, 30 Mar 87 13:04:33 est
From: jinx@GENEVA.AI.MIT.EDU (Guillermo J. Rozas)
Message-Id: <8703301804.AA09557@geneva>
To: JAR@AI.AI.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees's message of Mon, 30 Mar 87 12:20:13 EST <175971.870330.JAR@AI.AI.MIT.EDU>
Subject: [ALAN: multiple return values]

I agree with ALAN here.  I used to prefer the stricter semantics, but
after some thought I've arrived at the conclusion that it is silly.
It adds no new functionality and is hardly more convenient than
passing an explicit continuation (syntax for which can be provided).

The case I like to consider is the case of QUOTIENT (there are many
others like it).  It is often very cheap (or even necessary) to
produce the remainder of an integer division when computing the
quotient.  Thus it would be natural for QUOTIENT to return the
remainder as a second value.  The strict semantics would force anyone
using quotient to use RECEIVE-VALUES, although a very common use, in
fact, is to ignore the remainder.  In the absence of "loose" multiple
values, there are two possibilities, both distasteful:

- Provide another procedure which returns both (as in the case of MIT
Scheme's INTEGER-DIVIDE), but this tends to increase the number of
procedures that users have to know about to an unreasonable extent.

- Force users to use both QUOTIENT and REMAINDER when both results are
desired.  The only way to get efficiency out of this one is to fall
into the "mighty compiler" assumption.

I think, therefore, that it would not be a good idea to agree on a
standard that allows the strict semantics (and I would vote against
it).  If some people have serious objections to the "loose" semantics,
then we may be better off not standardizing at all.


∂30-Mar-87  1136	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	almost scheme in common lisp  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87  11:36:14 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 30 Mar 87 14:05:11 EST
Date: Mon, 30 Mar 87 14:01:36 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  almost scheme in common lisp
To: common-lisp@SAIL.STANFORD.EDU, scheme@MC.LCS.MIT.EDU
Message-ID: <176048.870330.JAR@AI.AI.MIT.EDU>


I have written a macro package which implements Scheme, less general
tail-recursion and first-class continuations, in Common Lisp.  It
appears to be effective at transforming any Common Lisp implementation
into an acceptable development environment for Scheme programs.

Loops written using LETREC, internal DEFINE, or "named LET" are
macroexpanded into an appropriate TAGBODY construct, but other than
that, tail recursion is only done at the whim of your particular CL
implementation.

Being a macro package and not a compiler or interpreter, continuations
also clearly can't work in general (unless, again, your CL just happens
to support them).  Other incompatibilities with the "Revised↑3" Scheme
report are minor.

It's called "Pseudoscheme" and resides in
     MC.LCS.MIT.EDU:  "JAR;PSEUDO >"
The documentation is in
     MC.LCS.MIT.EDU:  "JAR;PSEUDO DOC"

I'll send it by electronic mail to those unable to FTP it.  Please
send mail to INFO-CLSCHEME-REQUEST@MC.LCS.MIT.EDU if you start using it,
so you can stay up to date on improvements.

Feel free to redistribute it, but try to let me know if you do so.

The documentation file describes its peculiarities in somewhat more detail.

- Jonathan Rees


∂30-Mar-87  1455	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	Re: multiple return values 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87  14:54:44 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 30 Mar 87 17:33:22 EST
Received: from relay2.cs.net by RELAY.CS.NET id ac22144; 30 Mar 87 15:43 EST
Received: from tektronix.tek.com by RELAY.CS.NET id af28003; 30 Mar 87 15:39 EST
Received: by tektronix.TEK.COM (5.51/6.20)
	id AA03473; Mon, 30 Mar 87 09:24:47 PST
Received: by tekchips.TEK.COM (5.31/6.19)
	id AA02271; Mon, 30 Mar 87 09:23:19 PST
Message-Id: <8703301723.AA02271@tekchips.TEK.COM>
To: JAR@MC.LCS.MIT.EDU
Cc: rrrs-authors@MC.LCS.MIT.EDU
Subject: Re: multiple return values
In-Reply-To: Your message of Sat, 28 Mar 87 00:03:12 EST.
	     <174983.870328.JAR@AI.AI.MIT.EDU>
Date: 30 Mar 87 09:23:17 PST (Mon)
From: willc%tekchips.tek.com@RELAY.CS.NET

Will:
    I see no way to implement the proposed procedures in R3RS Scheme, but
    most implementations should find it easy to add them.

Jonathan:
  If "wrong" doesn't imply "signals an error" then the following is a
  correct implementation of alternative 1.  This is pretty much how the
  feature was implemented in T2....

Unfortunately, Jonathan's simple implementation of receive-values and
return-values doesn't quite work: (list 1 (return-values 2) 3) is
supposed to evaluate to (1 2 3) but with Jonathan's implementation it
evaluates to (1 (values-marker 2) 3).  The problem is that RETURN-VALUES
doesn't know whether it is returning to a continuation created by
RECEIVE-VALUES or to an "ordinary" continuation.  The simplest correct
implementations I've been able to imagine require that one machine
instruction be added to the standard continuation invocation sequence
(i.e. returns from closed-coded non-tail-recursive calls).

Peace, Will

∂30-Mar-87  1509	@MC.LCS.MIT.EDU:willc%tekchips.tek.com@RELAY.CS.NET 	Re: Let's get together again    
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87  15:08:53 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 30 Mar 87 17:38:45 EST
Received: from relay2.cs.net by RELAY.CS.NET id ab22416; 30 Mar 87 15:49 EST
Received: from tektronix.tek.com by RELAY.CS.NET id aj28003; 30 Mar 87 15:41 EST
Received: by tektronix.TEK.COM (5.51/6.20)
	id AA07158; Mon, 30 Mar 87 10:54:59 PST
Received: by tekchips.TEK.COM (5.31/6.19)
	id AA03755; Mon, 30 Mar 87 10:53:26 PST
Message-Id: <8703301853.AA03755@tekchips.TEK.COM>
To: RRRS-Authors@MC.LCS.MIT.EDU, willc%tekchips.tek.com@RELAY.CS.NET
Cc: KMP@SCRC-STONY-BROOK.ARPA, jinx%geneva.ai.mit.edu@RELAY.CS.NET
Subject: Re: Let's get together again
In-Reply-To: Your message of Sat, 28 Mar 87 16:11:21 est.
	     <8703282111.AA05557@geneva>
Date: 30 Mar 87 10:53:22 PST (Mon)
From: willc%tekchips.tek.com@RELAY.CS.NET

27-28 June (Saturday and Sunday) is fine with me.  The person in charge
of local arrangements probably ought to be the one to decide the dates
as well.  Any volunteers?

Norman Adams pointed out to me that Jonathan's implementation of
multiple return values (as in equation 1 for "single") can be patched
quite easily---he'll be posting the patch.  The ease of implementing
equation 1 in existing implementations must then make it my favorite
too.

Peace, Will

∂30-Mar-87  1858	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	Let's get together again 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87  18:58:08 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 30 Mar 87 21:58:15 EST
Date: Mon, 30 Mar 87 21:39:51 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Let's get together again
To: willc%tekchips.tek.com@RELAY.CS.NET
cc: RRRS-Authors@MC.LCS.MIT.EDU
In-reply-to: Msg of 30 Mar 87 10:53:22 PST (Mon) from willc%tekchips.tek.com at RELAY.CS.NET
Message-ID: <176355.870330.JAR@AI.AI.MIT.EDU>

I think it's a great idea.

If no one else from MIT wants to do local arrangements I'd be happy to.



∂30-Mar-87  2026	@MC.LCS.MIT.EDU:adams%tekchips.tek.com@RELAY.CS.NET 	Re: multiple return values 
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87  20:25:52 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 30 Mar 87 23:31:07 EST
Received: from relay2.cs.net by RELAY.CS.NET id ae29609; 30 Mar 87 22:44 EST
Received: from tektronix.tek.com by RELAY.CS.NET id ac00188; 30 Mar 87 22:40 EST
Received: by tektronix.TEK.COM (5.51/6.20)
	id AA10175; Mon, 30 Mar 87 13:58:25 PST
Received: by tekchips.TEK.COM (5.31/6.19)
	id AA06188; Mon, 30 Mar 87 13:56:53 PST
Date: Mon, 30 Mar 87 13:56:53 PST
From: Norman Adams <adams%tekchips.tek.com@RELAY.CS.NET>
Message-Id: <8703302156.AA06188@tekchips.TEK.COM>
Subject: Re: multiple return values
To: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>
Cc: rrrs-authors@MC.LCS.MIT.EDU
In-Reply-To: Jonathan A Rees <JAR@mc.lcs.mit.edu>, Sat, 28 Mar 87 00:03:12 EST

    If "wrong" doesn't imply "signals an error" then the following is a
    correct implementation of alternative 1.  This is pretty much how the
    feature was implemented in T2.
    
    (define values-marker (list 'values-marker))
    
    (define receive-values
      (lambda (thunk proc)
        (let ((vals (thunk)))
          (if (and (pair? vals) (eq? (car vals) values-marker))
    	  (apply proc (cdr vals))
    	  (proc vals)))))
    
    (define return-values
      (lambda vals
        (cons values-marker vals)))
    
Not quite a correct implementation, I think.  RETURN-VALUES should
canonicalize single return values:

(define return-values
  (lambda vals
    (if (and (pair? vals) (null? (cdr vals)))
	(car vals)
	(cons values-marker vals))))

-Norman

-------

∂30-Mar-87  2112	@MC.LCS.MIT.EDU:RPG@SAIL.STANFORD.EDU 	A Couple of Fun Programs  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87  21:12:06 PST
Received: from SAIL.STANFORD.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 31 Mar 87 00:04:46 EST
Date: 30 Mar 87  2057 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: A Couple of Fun Programs
To:   scheme@MC.LCS.MIT.EDU 


Jonathan sent out an interesting program the other day, and I was prompted
to send two more. These are (ugh, bletch) Common Lisp programs, but I
think it's instructive to see that CL programs don't have to look
completely silly (not using DO loops, &-constructs, &tc).  It's your job
to figure them out without running them. LABELS is like LETREC, TRUNCATE
rounds towards 0, (VALUES x y z) returns three values, and
(MULTIPLE-VALUE-BIND (X Y Z) (RETURN-THREE-VALUES) . <forms>) binds the
three variables X, Y, and Z appropriately and executes <forms>.

(defun f (n)
 (labels ((f (n m)
           (if (= n m)
	       n
	       (let ((h (truncate (+ m n) 2)))
		 (* (f n h) (f (+ h 1) m))))))
   (f 1 n)))

(defun f (i)
 (labels ((g (n n-1 n-2 m m-1 m-2)
           (let ((k (* n-1 m-1)))
	    (values (+ (* n m) k)
		    (+ (* n m-1) (* n-1 m-2))
		    (+ k (* n-2 m-2)))))
	  (h (i)
           (cond ((zerop i) (values 1 0 0))
		 ((= i 1) (values 1 1 0))
		 ((evenp i)
		  (multiple-value-bind (n n-1 n-2)
	           (h (truncate i 2))
	           (g n n-1 n-2 n n-1 n-2)))
		 (t
		  (multiple-value-bind (n n-1 n-2)
	           (h (1- i))
	           (g 1 1 0 n n-1 n-2))))))
  (prog1 (h i))))

They are written using non-instructive variable names. 

				-rpg-


∂31-Mar-87  1146	@MC.LCS.MIT.EDU:gls@Think.COM 	A Couple of Fun Programs
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87  11:32:07 PST
Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 31 Mar 87 12:56:36 EST
Received: from feuerbach by Think.COM via CHAOS; Tue, 31 Mar 87 12:06:05 EST
Date: Tue, 31 Mar 87 12:06 EST
From: Guy Steele <gls@Think.COM>
Subject: A Couple of Fun Programs
To: scheme@mc.lcs.mit.edu
Cc: RPG@sail.stanford.edu, gls@think.com
In-Reply-To: <8703310526.AA01555@Think.COM>
Message-Id: <870331120636.7.GLS@FEUERBACH.THINK.COM>

Those who found RPG's sample programs difficult to read because
of the "non-instructive variable names" may find the following
versions (completely equivalent, valid Common Lisp, and tested)
a bit more perspicuous:

(defun f (if)
 (labels ((packagep (if cons)
           (if (= if cons)
	       if
	       (let ((with-open-file (truncate (+ cons if) 2)))
		 (* (packagep if with-open-file) (packagep (+ with-open-file 1) cons))))))
   (packagep 1 if)))



(defun f (if)
 (labels ((atanh (go cond labels do* proclaim set-macro-character)
           (let ((setf (* cond proclaim)))
	    (values (+ (* go do*) setf)
		    (+ (* go proclaim) (* cond set-macro-character))
		    (+ setf (* labels set-macro-character)))))
	  (read-preserving-whitespace (if)
           (cond ((zerop if) (values 1 0 0))
		 ((= if 1) (values 1 1 0))
		 ((evenp if)
		  (multiple-value-bind (go cond labels)
	           (read-preserving-whitespace (truncate if 2))
	           (atanh go cond labels go cond labels)))
		 (t
		  (multiple-value-bind (go cond labels)
	           (read-preserving-whitespace (1- if))
	           (atanh 1 1 0 go cond labels))))))
  (prog1 (read-preserving-whitespace if))))

--Quux

∂31-Mar-87  1703	@MC.LCS.MIT.EDU:allen@bfly-vax.bbn.com 	Re: A Couple of Fun Programs  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87  17:03:33 PST
Received: from BFLY-VAX.BBN.COM (TCP 20026200235) by MC.LCS.MIT.EDU 31 Mar 87 19:01:10 EST
To: Guy Steele <gls@think.com>
cc: scheme@mc.lcs.mit.edu, RPG@sail.stanford.edu, allen@bfly-vax.bbn.com
Subject: Re: A Couple of Fun Programs
In-reply-to: Your message of Tue, 31 Mar 87 12:06 EST.
	     <870331120636.7.GLS@FEUERBACH.THINK.COM>
Date: 31 Mar 87 18:04:57 EST (Tue)
From: allen@bfly-vax.bbn.com

Ever thought about doing some user-interface work for Unix? It's clear that
you have the talent.

/Don

∂31-Mar-87  1743	@MC.LCS.MIT.EDU:ramsdell%faron@mitre-bedford.ARPA 	Scheme Numbers
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87  17:43:04 PST
Received: from mitre-bedford.ARPA (TCP 3200600102) by MC.LCS.MIT.EDU 31 Mar 87 19:03:33 EST
Posted-From: The MITRE Corp., Bedford, MA
Received: by faron.MENET (4.12/4.7)
	id AA11841; Tue, 31 Mar 87 15:36:20 est
Date: Tue, 31 Mar 87 15:36:20 est
From: John D. Ramsdell <ramsdell%faron@mitre-bedford.ARPA>
Posted-Date: Tue, 31 Mar 87 15:36:20 est
Message-Id: <8703312036.AA11841@faron.MENET>
To: rrrs-authors%mc.lcs.mit.edu@mitre-bedford.ARPA
Subject: Scheme Numbers

Last night I tried to find out where the R↑3RS disallows
the reordering of computation involving inexact numbers.
Numerical analysts know that floating point addition and
multiplication are not commutative, and write code that 
depends on the fact that these operation are to be preformed
in the precise order given.  One of the things FORTRAN does
correctly is promise not to reorder computations involving
inexact numbers.  I never found that promise last night.
Let's make that promise to Scheme users in R↑4RS.
John

∂31-Mar-87  1829	@MC.LCS.MIT.EDU:bartley%home%ti-csl.csnet@RELAY.CS.NET 	multiple return values  
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87  18:29:12 PST
Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 31 Mar 87 21:14:11 EST
Received: from relay2.cs.net by RELAY.CS.NET id ag22435; 31 Mar 87 20:42 EST
Received: from ti-csl by RELAY.CS.NET id ar06470; 31 Mar 87 20:35 EST
Received: from home (home.ARPA) by tilde id AA22798; Tue, 31 Mar 87 18:25:08 cst
Received: by home id AA08042; Tue, 31 Mar 87 18:25:03 cst
Date: Tue, 31 Mar 87 18:25:03 cst
From: David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>
Message-Id: <8704010025.AA08042@home>
To: rrrs-authors@MC.LCS.MIT.EDU
Cc: Bartley%home%ti-csl.csnet@RELAY.CS.NET
Subject: multiple return values

(1) I agree with ALAN and Jinx that it seems pretty useless to specify
a multiple value capability and not go beyond Will's alternative #1.
Since I intend to implement Common Lisp on top of Scheme, I will want
to extend the essential capability anyway.  (Are ALAN and Jinx arguing
for #2 or #3?)

(2) In his rationale, Will said "The Common Lisp position would say
that when zero values are returned to a continuation that is expecting
one value, then the symbol NIL is passed to the continuation."  I
think we could specify this to be "the false value" or "the empty
list" and remain compatible with Common Lisp without having to make
the symbol NIL noteworthy in Scheme.

(3) Will's proposal does not mention CALL-WITH-CURRENT-CONTINUATION.
It seems that a continuation object should accept an arbitrary number
of arguments if we take alternative #2 or #3.  If so, we could define
(RETURN-VALUES A B) to be the same as (CALL/CC (LAMBDA (K) (K A B))).

(4) It seems to me that the hairiest part of the multiple value
"feature" in Common Lisp is MULTIPLE-VALUE-PROG1.  Something like this
is needed, at least "behind the scenes", if we expect DYNAMIC-WIND
(etc.) to pass through multiple values.  We could express
(MULTIPLE-VALUE-PROG1 A B ...) as

(receive-values A (lambda L B ... (apply return-values L))) ,

but that is pretty expensive.  Is this common enough to require
standardization so implementors could work on more efficient
mechanisms?

(5) JAR finds the proposed feature "to be pretty unuseable unless
there is some syntactically sugared way to use RECEIVE-VALUES."  If
this is true, I think we must agree on what sugar to add.  What's the
point of standardizing on something that is too cryptic to be used by
anyone?

I like T's RECEIVE, which I understand to be defined as

(receive <formals> <m-v-expression> . <body>)

==> (receive-values (lambda () <m-v-expression>)
		    (lambda <formals> . body>))

The key for me is that <formals> is a complete lambda list, possibly
containing "optional" and "rest" arguments, and is not just a list of
"required" identifiers.  This seems more flexible than Common Lisp's
MULTIPLE-VALUE-BIND.

If we keep the name RECEIVE-VALUES, then the name RECEIVE is ok here,
but I would prefer something like MULTIPLE-VALUE-LET.

(6) Let's get down to brass tacks and argue about names!  I'm bothered
by the "return" in RETURN-VALUES.  As Will pointed out, the name
RETURN would be confusing to refugees from other Lisps.  However,
RETURN-VALUES still seems to imply an exit from the calling procedure.
A user might ask whether the procedure

 (LAMBDA (A B C) (+ A (RETURN-VALUES B) C))

returns the sum of A, B, and C or just B?  I think we all intend for
RETURN-VALUES to "return" to its caller (the middle of the body), not
to that procedure's caller.  I suggest renaming RETURN-VALUES to be
MULTIPLE-VALUES.

Likewise, the "receive" in RECEIVE-VALUES seems strange; I would
expect the complementary routine to be SEND-VALUES.  How about
CALL-WITH-MULTIPLE-VALUES (call/mv?) by analogy with CALL-WITH-
CURRENT-CONTINUATION (call/cc)?  (I'm not sure if I'm joking!)

Regards,
David Bartley


∂31-Mar-87  2009	@MC.LCS.MIT.EDU:JAR@AI.AI.MIT.EDU 	multiple return values   
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87  20:08:55 PST
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Mar 87 23:02:38 EST
Date: Tue, 31 Mar 87 22:13:26 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  multiple return values
To: bartley%home%ti-csl.csnet@RELAY.CS.NET
cc: rrrs-authors@MC.LCS.MIT.EDU
In-reply-to: Msg of Tue 31 Mar 87 18:25:03 cst from David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
Message-ID: <177055.870331.JAR@AI.AI.MIT.EDU>


I would strongly oppose the Common Lisp multiple value semantics.  I
find it to be very distasteful.  If this means that the language has no
multiple values primitively, and I have to implement semantics #1 myself
using lists or closures or whatever, that's fine with me.

If I have many sympathizers then I'd say it appears that we're
as deadlocked as we were last time this came up...

There's a deeper issue here:  I have found that I use a number of
features which can be implemented easily enough in Scheme, but for which
particular scheme implementations have efficient, low-level, nonstandard
support.  For example: multiple values, fixnum arithmetic, byte vectors,
certain string operations (like what was in the R↑2 report), hash
tables, PEEK-CHAR, and bitwise logical opertions.  What I do is I have
one particular file which implements all these features portably.  I can
then replace this file for particular implementations to get better
performance.  In general I'll have N+1 versions of this file, one
portable version plus one version for each implementation for which it's
been tuned.

Does anyone else do things like this?  Or am I the only person who really
tries to write nontrivial programs that are both portable and fast?

The fact that my programs are portable, and that this "tuning file" is
small in size, is of course due to our standardization effort.  It's not
clear that implementation-dependent tuning can go away completely, but
the smaller that file is, the