perm filename CLEDIT.MSG[COM,LSP]21 blob sn#876202 filedate 1989-08-21 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00201 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00027 00002	∂31-Mar-88  1358	chapman%aitg.DEC@decwrl.dec.com 	editorial subcommittee notes    
C00043 00003	∂03-May-88  0658	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-PROPOSAL-FORMAT    
C00046 00004	∂03-May-88  0909	CL-Editorial-mailer 	Re: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
C00049 00005	∂03-May-88  1114	CL-Editorial-mailer 	editorial committee meeting  
C00050 00006	∂03-May-88  1118	CL-Editorial-mailer 	EDITORIAL-COMITTEE-STANDARD-REVIEW
C00062 00007	∂03-May-88  1251	CL-Editorial-mailer 	EDITORIAL-COMITTEE-STANDARD-REVIEW
C00067 00008	∂03-May-88  1302	CL-Editorial-mailer 	re:barmar comments 
C00069 00009	∂05-May-88  2216	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-STANDARD-REVIEW    
C00082 00010	∂06-May-88  0934	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-STANDARD-REVIEW    
C00084 00011	∂26-May-88  0728	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-PROPOSAL-FORMAT    
C00087 00012	∂26-May-88  0807	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-STANDARD-REVIEW    
C00090 00013	∂26-May-88  1007	CL-Editorial-mailer 	hard copy
C00093 00014	∂26-May-88  1123	CL-Editorial-mailer 	$$'s for Words
C00095 00015	∂26-May-88  1134	CL-Editorial-mailer 	re: Sonya's comments    
C00099 00016	∂26-May-88  2052	CL-Editorial-mailer 	editorial committee meeting  
C00104 00017	∂10-Jun-88  0909	CL-Editorial-mailer 	standard mailing   
C00106 00018	∂16-Jun-88  1621	CL-Editorial-mailer 	Comments on the snapshot version  
C00110 00019	∂05-Jul-88  1129	CL-Editorial-mailer 	Editorial Committee Meetings - June    
C00130 00020	∂19-Jul-88  1046	CL-Editorial-mailer 	just to let you know    
C00132 00021	∂26-Jul-88  0613	CL-Editorial-mailer 	standard mailing   
C00133 00022	∂06-Aug-88  0325	CL-Editorial-mailer 	mailing list change
C00134 00023	∂06-Aug-88  0326	CL-Editorial-mailer 	mailing list change
C00135 00024	∂08-Aug-88  1243	CL-Editorial-mailer 	CL standard   
C00137 00025	∂23-Aug-88  0749	CL-Editorial-mailer 	standard 
C00138 00026	∂23-Aug-88  0907	CL-Editorial-mailer 	standard 
C00140 00027	∂30-Aug-88  0858	CL-Editorial-mailer 	questions
C00143 00028	∂30-Aug-88  1056	CL-Editorial-mailer 	Re: questions 
C00145 00029	∂30-Aug-88  1350	CL-Editorial-mailer 	questions
C00149 00030	∂30-Aug-88  1615	CL-Editorial-mailer 	questions
C00152 00031	∂31-Aug-88  1459	CL-Editorial-mailer 	questions
C00154 00032	∂31-Aug-88  1459	CL-Editorial-mailer 	questions
C00156 00033	∂02-Sep-88  2136	CL-Editorial-mailer 	wording about Symbols   
C00158 00034	∂06-Sep-88  1348	CL-Editorial-mailer 	Notation in standard for function argument/value types
C00161 00035	∂06-Sep-88  1414	CL-Editorial-mailer 	Notation in standard for function argument/value types
C00163 00036	∂06-Sep-88  1450	CL-Editorial-mailer 	Re: Notation in standard for function argument/value types 
C00165 00037	∂06-Sep-88  2131	CL-Editorial-mailer 	Notation in standard for function argument/value types
C00169 00038	∂06-Sep-88  2346	CL-Editorial-mailer 	Re: Notation in standard for function argument/value types 
C00171 00039	∂07-Sep-88  1017	CL-Editorial-mailer 	Audience of the Standard
C00174 00040	∂09-Sep-88  1217	CL-Editorial-mailer 	type specifiers    
C00176 00041	∂12-Sep-88  0843	CL-Editorial-mailer 	committee
C00177 00042	∂12-Sep-88  1037	CL-Editorial-mailer 	Issue: CLOS-:initform-typographical-errors  
C00187 00043	∂19-Sep-88  1439	CL-Editorial-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)   
C00196 00044	∂19-Sep-88  1505	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1) 
C00198 00045	∂19-Sep-88  1542	CL-Cleanup-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
C00209 00046	∂28-Sep-88  1344	CL-Editorial-mailer 	[Robert S. Boyer <boyer@CLI.COM>: Clean Up] 
C00212 00047	∂28-Sep-88  1442	CL-Editorial-mailer 	as if you haven't got enough to review 
C00234 00048	∂28-Sep-88  1707	CL-Editorial-mailer 	as if you haven't got enough to review 
C00244 00049	∂29-Sep-88  1220	CL-Editorial-mailer 	re: barmar comments on error paper
C00256 00050	∂29-Sep-88  1404	CL-Editorial-mailer 	re: barmar comments on error paper
C00268 00051	∂03-Oct-88  1125	CL-Editorial-mailer 	    
C00280 00052	∂03-Oct-88  1233	CL-Editorial-mailer 	October agenda
C00284 00053	∂03-Oct-88  1255	CL-Editorial-mailer 	error definitions  
C00295 00054	∂03-Oct-88  1406	CL-Editorial-mailer 	Error Terminology  
C00297 00055	∂03-Oct-88  1429	CL-Editorial-mailer 	Error Terminology  
C00302 00056	∂04-Oct-88  0951	CL-Editorial-mailer 	barmar questions about error terms
C00305 00057	∂04-Oct-88  1101	CL-Editorial-mailer 	Error Terminology  
C00308 00058	∂04-Oct-88  2041	X3J13-mailer 	Re: error definitions
C00312 00059	∂05-Oct-88  0021	CL-Editorial-mailer 	Re: Error Terminology   
C00314 00060	∂14-Oct-88  1149	CL-Editorial-mailer 	proposal for specification of standard features  
C00322 00061	∂18-Oct-88  0922	CL-Editorial-mailer 	next meeting  
C00323 00062	∂18-Oct-88  1229	CL-Editorial-mailer 	editorial committee meeting notes 
C00332 00063	∂18-Oct-88  1436	CL-Editorial-mailer 	subsetting/features
C00334 00064	∂18-Oct-88  1539	CL-Editorial-mailer 	Re: proposal for specification of standard features   
C00337 00065	∂18-Oct-88  1611	CL-Editorial-mailer 	Re: proposal for specification of standard features   
C00340 00066	∂28-Oct-88  0346	CL-Editorial-mailer 	mailing list update
C00341 00067	∂28-Oct-88  1613	CL-Editorial-mailer 	A Note on Examples For Standard   
C00343 00068	∂07-Nov-88  1742	CL-Editorial-mailer 	"arguments to a @i(form)"    
C00345 00069	∂20-Nov-88  0416	CL-Editorial-mailer 	conformance, subsetting...   
C00354 00070	∂06-Dec-88  1153	CL-Editorial-mailer 	second request for comments  
C00364 00071	∂15-Dec-88  0124	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION  
C00368 00072	∂15-Dec-88  0125	CL-Editorial-mailer 	Issue: DEPRECATION-POSITION  
C00372 00073	∂15-Dec-88  0125	CL-Editorial-mailer 	Issue: EXTENSIONS-POSITION   
C00375 00074	∂15-Dec-88  0126	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
C00380 00075	∂15-Dec-88  1132	CL-Editorial-mailer 	Issues: CONFORMANCE-POSITION, EXTENSIONS-POSITION
C00388 00076	∂15-Dec-88  1137	CL-Editorial-mailer 	Issue: DEPRECATION-POSITION  
C00392 00077	∂16-Dec-88  0932	CL-Editorial-mailer 	Re: Issue: DEPRECATION-POSITION   
C00395 00078	∂20-Dec-88  0850	CL-Editorial-mailer 	file names    
C00419 00079	∂20-Dec-88  0858	CL-Editorial-mailer 	functions changed by X3J13 issues 
C00422 00080	∂20-Dec-88  1253	CL-Editorial-mailer 	Hawaii   
C00425 00081	∂20-Dec-88  1319	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
C00430 00082	∂20-Dec-88  1348	CL-Editorial-mailer 	Issue: EXTENSIONS-POSITION   
C00435 00083	∂20-Dec-88  1423	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION  
C00440 00084	∂20-Dec-88  1423	CL-Editorial-mailer 	Issue: DEPRECATION-POSITION  
C00446 00085	∂20-Dec-88  1427	CL-Editorial-mailer 	Issue: CUT-OFF-DATES    
C00454 00086	∂23-Dec-88  1235	CL-Editorial-mailer 	Error terminology  
C00460 00087	∂28-Dec-88  0630	CL-Editorial-mailer 	please respond if you receive this message  
C00461 00088	∂28-Dec-88  0927	CL-Editorial-mailer 	please respond if you receive this message  
C00463 00089	∂29-Dec-88  0546	CL-Editorial-mailer 	Re: please respond if you receive this message   
C00465 00090	∂30-Dec-88  0125	CL-Editorial-mailer 	[cperdue@Sun.COM: Re:  Error terminology]   
C00468 00091	∂30-Dec-88  0829	CL-Editorial-mailer 	[cperdue@Sun.COM: Re:  Error terminology]   
C00474 00092	∂30-Dec-88  1347	CL-Editorial-mailer 	Unpredictable but Harmless   
C00479 00093	∂01-Jan-89  2011	CL-Editorial-mailer 	[cperdue@Sun.COM: Re:  Error terminology]   
C00482 00094	∂03-Jan-89  0856	CL-Editorial-mailer 	Please review and comment ASAP    
C00487 00095	∂03-Jan-89  0859	CL-Editorial-mailer 	Please review and comment ASAP    
C00492 00096	∂03-Jan-89  0901	CL-Editorial-mailer 	Please review and comment ASAP    
C00500 00097	∂03-Jan-89  0927	CL-Editorial-mailer 	Please review and comment ASAP    
C00505 00098	∂03-Jan-89  0957	CL-Editorial-mailer 	Please review and comment ASAP    
C00511 00099	∂03-Jan-89  1435	CL-Editorial-mailer 	info about issues in a 2-part message  
C00538 00100	∂03-Jan-89  1819	CL-Editorial-mailer 	Issue: CUT-OFF-DATES (Version 1)  
C00541 00101	∂03-Jan-89  1820	CL-Editorial-mailer 	Re: Issue: DEPRECATION-POSITION   
C00545 00102	∂03-Jan-89  1819	CL-Editorial-mailer 	Re: Please review and comment ASAP
C00549 00103	∂03-Jan-89  1819	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION (Version 2)
C00553 00104	∂03-Jan-89  1818	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION (Version 1) 
C00560 00105	∂04-Jan-89  0900	CL-Editorial-mailer 	part 2 (there will be a part 3 too)    
C00599 00106	∂04-Jan-89  0902	CL-Editorial-mailer 	part 3   
C00666 00107	∂04-Jan-89  1919	CL-Editorial-mailer 	Re: Unpredictable but Harmless    
C00668 00108	∂06-Jan-89  2246	CL-Editorial-mailer 	Conformance   
C00671 00109	∂08-Jan-89  1327	CL-Editorial-mailer 	conformance & extensions issues   
C00679 00110	∂09-Jan-89  0446	CL-Editorial-mailer 	Re: Issue: SUBSETTING-POSITION (Version 1)  
C00683 00111	∂09-Jan-89  0938	CL-Editorial-mailer 	conformance & extensions issues   
C00692 00112	∂09-Jan-89  1058	RPG  
C00693 00113	∂09-Jan-89  1107	CL-Editorial-mailer 	Re: Issue:CONFORMANCE-POSITION    
C00696 00114	∂09-Jan-89  1242	CL-Editorial-mailer 	Re: Issue:CUT-OFF-DATES 
C00698 00115	∂09-Jan-89  1524	CL-Editorial-mailer 	"Discussion" in issues  
C00703 00116	∂13-Jan-89  1903	CL-Editorial-mailer 	Code as Spec: {Issue: THE-AMBIGUITY (Version 2)} 
C00708 00117	∂23-Jan-89  0106	CL-Editorial-mailer 	Requests from the Japanese   
C00714 00118	∂23-Jan-89  1640	CL-Editorial-mailer 	Re: Requests from the Japanese    
C00717 00119	∂23-Jan-89  1640	CL-Cleanup-mailer 	[Robert S. Boyer <boyer@CLI.COM>: Backquote Documentation    
C00721 00120	∂27-Jan-89  0130	CL-Editorial-mailer 	The volume of ANSI draft
C00727 00121	∂27-Jan-89  0941	CL-Editorial-mailer 	The volume of ANSI draft
C00732 00122	∂29-Jan-89  2050	CL-Editorial-mailer 	The volume of ANSI draft
C00740 00123	∂30-Jan-89  0804	CL-Editorial-mailer 	The volume of ANSI draft
C00744 00124	∂30-Jan-89  1918	CL-Editorial-mailer 	The volume of ANSI draft
C00750 00125	∂31-Jan-89  1106	CL-Editorial-mailer 	Re: Issue: EXTRA-SYNTAX (Version 1)    
C00753 00126	∂31-Jan-89  1226	CL-Editorial-mailer 	Re: Issue: EXTENSIONS-POSITION (version 1)  
C00755 00127	∂31-Jan-89  1237	CL-Editorial-mailer 	Re: Issue: EXTENSIONS-POSITION (version 1)  
C00758 00128	∂31-Jan-89  1248	CL-Compiler-mailer 	Re: Issue: EXTENSIONS-POSITION (version 1)   
C00760 00129	∂31-Jan-89  1300	CL-Editorial-mailer 	Re: Issue: EXTENSIONS-POSITION (version 1)  
C00764 00130	∂31-Jan-89  1613	CL-Editorial-mailer 
C00767 00131	∂31-Jan-89  1739	CL-Editorial-mailer 	Re: Issue: EXTRA-SYNTAX (Version 1)    
C00772 00132	∂01-Feb-89  0702	CL-Editorial-mailer 
C00775 00133	∂01-Feb-89  1419	CL-Editorial-mailer 	Importance of non-US opinion 
C00780 00134	∂02-Feb-89  0727	CL-Editorial-mailer 	Issue: FONTS  
C00784 00135	∂02-Feb-89  0728	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
C00801 00136	∂02-Feb-89  0728	CL-Editorial-mailer 	Issue: TOC    
C00812 00137	∂02-Feb-89  0726	CL-Editorial-mailer 	Issue: CUT-OFF-DATES    
C00829 00138	∂02-Feb-89  0822	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION  
C00836 00139	∂02-Feb-89  0825	CL-Editorial-mailer 	Please review ASAP 
C00840 00140	∂02-Feb-89  0842	CL-Editorial-mailer 	Issue: FONTS  
C00842 00141	∂02-Feb-89  0850	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION  
C00844 00142	∂02-Feb-89  0853	CL-Editorial-mailer 	Re: Issue: CONFORMANCE-POSITION   
C00847 00143	∂02-Feb-89  0900	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
C00856 00144	∂02-Feb-89  0921	CL-Editorial-mailer 	Issue: EXTENSIONS-POSITION   
C00863 00145	∂02-Feb-89  0925	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
C00867 00146	∂02-Feb-89  0941	CL-Editorial-mailer 	Re: Issue: EXTENSIONS-POSITION    
C00870 00147	∂02-Feb-89  0955	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
C00873 00148	∂02-Feb-89  1000	CL-Editorial-mailer 	Re: Issue: SUBSETTING-POSITION    
C00876 00149	∂02-Feb-89  1023	CL-Editorial-mailer 	Re: Issue: SUBSETTING-POSITION    
C00880 00150	∂02-Feb-89  1052	CL-Editorial-mailer 	Re: Issue: SUBSETTING-POSITION    
C00884 00151	∂02-Feb-89  1115	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
C00887 00152	∂02-Feb-89  1513	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION  
C00890 00153	∂02-Feb-89  1521	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION  
C00894 00154	∂02-Feb-89  1558	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
C00898 00155	∂03-Feb-89  0811	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
C00901 00156	∂03-Feb-89  1112	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
C00906 00157	∂04-Feb-89  2258	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
C00921 00158	∂04-Feb-89  2312	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
C00923 00159	∂05-Feb-89  1137	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
C00927 00160	∂05-Feb-89  1151	CL-Editorial-mailer 	Issue: EXTENSIONS-POSITION   
C00930 00161	∂05-Feb-89  1204	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
C00931 00162	∂05-Feb-89  1956	CL-Editorial-mailer 	Issue: EXTENSIONS-POSITION   
C00933 00163	∂05-Feb-89  2139	CL-Editorial-mailer 	What is Portable?  
C00935 00164	∂06-Feb-89  0136	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
C00953 00165	∂06-Feb-89  0220	CL-Editorial-mailer 	cut off dates 
C00957 00166	∂06-Feb-89  0622	CL-Editorial-mailer 	What is Portable?  
C00964 00167	∂06-Feb-89  0637	CL-Editorial-mailer 	Issue: EXTENSIONS-POSITION   
C00970 00168	∂06-Feb-89  1614	RPG 	
C00972 00169	∂06-Feb-89  1640	RPG 	CLOS review    
C00977 00170	∂06-Feb-89  1644	CL-Editorial-mailer 	cut off dates 
C00978 00171	∂06-Feb-89  1707	CL-Editorial-mailer 	What is Portable?  
C00984 00172	∂06-Feb-89  1904	CL-Editorial-mailer 	What is Portable?  
C00991 00173	∂06-Feb-89  2108	CL-Editorial-mailer 	What is Portable?  
C00995 00174	∂07-Feb-89  0319	CL-Editorial-mailer 	editorial committee meeting  
C00996 00175	∂07-Feb-89  0810	CL-Editorial-mailer 	What is Portable?  
C00999 00176	∂07-Feb-89  1244	CL-Editorial-mailer 	Editorial Committee Meeting  
C01000 00177	∂07-Feb-89  1349	CL-Editorial-mailer 	Re: cut off dates  
C01004 00178	∂14-Feb-89  0323	CL-Editorial-mailer 	Issue: EXTRA-SYNTAX
C01007 00179	∂14-Feb-89  0325	CL-Editorial-mailer 	Issue: UNSPECIFIED-DATATYPES 
C01012 00180	∂14-Feb-89  0324	CL-Editorial-mailer 	Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
C01017 00181	∂14-Feb-89  0325	CL-Editorial-mailer 	Issue: EXTRA-RETURN-VALUES   
C01020 00182	∂14-Feb-89  0326	CL-Editorial-mailer 	Issue: MACRO-AS-FUNCTION
C01024 00183	∂14-Feb-89  0326	CL-Editorial-mailer 	Issue: UNSOLICITED-MESSAGES  
C01028 00184	∂14-Feb-89  0930	CL-Editorial-mailer 	Issue: EXTRA-SYNTAX
C01031 00185	∂14-Feb-89  0944	CL-Editorial-mailer 	Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
C01037 00186	∂16-Feb-89  2357	CL-Editorial-mailer 	Re: Issue: CONFORMANCE-POSITION   
C01041 00187	∂24-Feb-89  0354	CL-Editorial-mailer 	editorial committee meeting  
C01044 00188	∂24-Feb-89  0922	CL-Editorial-mailer 	editorial committee meeting  
C01046 00189	∂25-Feb-89  0212	CL-Editorial-mailer 	editorial committee meeting  
C01049 00190	∂03-Mar-89  1111	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
C01054 00191	∂04-Mar-89  0844	CL-Editorial-mailer 	voting   
C01058 00192	∂04-Mar-89  2051	CL-Editorial-mailer 	What is a FUNCTION?
C01062 00193	∂04-Mar-89  2223	CL-Editorial-mailer 	comments on various sections of the draft   
C01103 00194	∂05-Mar-89  0259	CL-Editorial-mailer 	comments on various sections of the draft   
C01105 00195	∂05-Mar-89  1142	CL-Editorial-mailer 	Definition of `Function'
C01108 00196	∂05-Mar-89  1604	CL-Editorial-mailer 	Re: What is a FUNCTION? 
C01111 00197	∂05-Mar-89  1624	CL-Editorial-mailer 	Sandra's Comments  
C01114 00198	∂06-Mar-89  1329	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
C01117 00199	∂06-Mar-89  1343	CL-Editorial-mailer 	Definition of `Function'
C01120 00200	∂06-Mar-89  1344	CL-Editorial-mailer 	comments on various sections of the draft   
C01124 00201	∂06-Mar-89  1533	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
C01126 ENDMK
C⊗;
∂31-Mar-88  1358	chapman%aitg.DEC@decwrl.dec.com 	editorial subcommittee notes    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 31 Mar 88  13:58:43 PST
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA15156; Thu, 31 Mar 88 13:52:57 PST
Date: Thu, 31 Mar 88 13:52:57 PST
Message-Id: <8803312152.AA15156@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: @[chapman]eddis@decwrl.dec.com, chapman%aitg.DEC@decwrl.dec.com
Subject: editorial subcommittee notes




                        Editorial Subcommittee Report
                                 March, 1988



      1  INTRODUCTION

           The editorial subcommittee of X3J13 met on  March  15,  1988,
      from 2-5 PM at Lucid.  Attendees were:



      Skona Brittain       Barry Margolin

      Kathy Chapman        Larry Masinter

      Linda deMicheal      Guy Steele

      Dick Gabriel         Walter van Roggen

      Sonya Keene          Bob Mathis
(did I leave anyone out?)



           This memo summarizes the important results  of  the  meeting,
      and lists the action items from the meeting.



      2  SUMMARY

           In  general,  the  attendees  felt  that  the  schedule   for
      completion   of  the  standard  was  agressive,  but  doable.   In
      addition,  there  is  an  increased  interest  in  completing  the
      standard  on,  or ahead of, schedule, due to the commitment the US
      has made to the ISLISP group.  Following are the decisions made by
      the attendees.

      1.  The outline and contents of the chapters of the standard  have
          been  modified.   The  next  section  of this memo details the
          changes.

      2.  A formal specification of the base forms of CL will  be  done.
          It  will  begin in July or sooner.  Initially the work will be
          done by Dick Gabriel and Kathy Chapman.  It is hoped that Will
          Clinger  and  Jonathan  Rees will have time to assist with the
          effort.

      3.  It was decided that the use of a large set of special fonts in
          explanatory material (will be Chapter 3 in the new outline) is
          distracting to the reader.  Therefore, special fonts will only
          be employed to a limited extent in Chapter 3, but will be used
          more extensively in Chapter 4 (see Action Items section).
!
                                                                Page 2


      4.  It was decided that the  use  of  a  professional  indexer  is
          probably desirable (see Action Items section).

      5.  The reader syntax and semantic rules, and other semantic rules
          of  the  language CL, will be specified in natural language in
          the form of a set of evaluation rules.  These will  appear  in
          Chapters 2 and 3 (see outline in the next section) (see Action
          Items section).

      6.  It was decided that the issues surrounding language extensions
          should be examined in detail (see Action Items section).

      7.  A new list of parts of the document to be reviewed, when  they
          will  be ready for review, and who is to review them, is to be
          constructed (see Action Items section).




      3  NEW OUTLINE AND CONTENTS OF STANDARD CHAPTERS

           Following is the new outline for the CL standard.

      1.  Chapter 1 - Introduction - Same outline as current chapter  1;
          font  key  explanation  is  expanded,  compliance  section  is
          rewritten with clarity in mind, language extensions section is
          modified (see Action Items).

      2.  Chapter 2 - Evaluation - This chapter  will  contain  a  clear
          model  of  read,  eval,  phases  of processing...  (see Action
          Items).

      3.  Chapter 3 - Concepts - This chapter will contain the following
          information:

          1.  A description of the Lisp reader, and a forward  reference
              to the read function.  In addition, the character set will
              appear  first,  and  all  the  syntactic   characteristics
              (whether  they  involve  `special'  tokens  or  not), will
              appear in the list of operators.

          2.  The data types section will contain an explanation of  the
              way CL uses data types.

          3.  The basic language constructs section  will  be  moved  to
              Chapter 2 (the evaluation model).

          4.  The rest of this chapter will contain information  similar
              to   what   is   contained   in  Chapter  1  of  the  CLOS
              specification, i.e., an explanation of  how  the  language
              works   with  forward  pointers  to  forms  that  will  be
              explained in detail (but autonomously) in Chapter 4.

!
                                                                Page 3


      4.  Chapter 4 - Form, Constant, and Variable Descriptions  -  This
          chapter  now includes the information that had previously been
          a part of Chapters 4, 5, and 7.  Following  are  some  details
          about how this chapter will look.

          1.  All  functions,  macros,  special  forms,  constants,  and
              variables   that   are   part   of   CL   will  be  listed
              alphabetically.  All  entries  with  non-alpha  characters
              appearing  in  the first position of the name of the entry
              will be positioned at the end of the alphabetic list,  and
              will  be  alphabetized  according  to  the  first alpha or
              numeric character appearing in the name of the entry.

          2.  The  `Inputs'  and  `Outputs'   labels   in   the   f/m/sf
              descriptions  are  changed  to  `Arguments'  and `Values',
              respectively.

          3.  The `Base' label is removed, and the fact that a f/m/sf is
              part of the base is notated under the label `Notes'.

          4.  A `Side Effects' label has been added.

          5.  A `See Also' label was suggested; however, its meaning  in
              a  strict specification is not clear.  For example, does a
              See Also reference mean that the  information  pointed  to
              somehow  affects  the result of the evaluation of the form
              being described?  Please comment on the addition of a `See
              Also' label.


      5.  Chapter 5 - Syntax - same as current Chapter 8.

      6.  Chapter 6 - Semantics - same as current Chapter 9.

!
                                                                Page 4


      4  ACTION ITEMS

           Following is a list of action items resulting from  both  the
      subcommittee meeting, and the X3J13 committee meeting.  Please let
      me know if I missed any items, or  have  incorrectly  assigned  an
      item to a person.


      Responsible people        Action Item


      Kathy Chapman             Get X3 to pay for professional indexer

      Kathy Chapman             Create a format for proposal submission

      Barry Margolin            Create a proposal on how language extensions are
      Larry Masinter            to be handled

      Guy Steele                Create an evaluation model strawman
      Dick Gabriel

      Kathy Chapman             Create a review cycle proposal for editorial
                                committee reviews                      

      Kathy Chapman             Create a review proposal for X3J13 committee

      Kathy Chapman             Contact typesetter to review font usage






      5  OPEN ISSUES

           Following is a list of decisions that  have  to  be  made  at
      future meetings.

      1.  Will new language features (like  CLOS)  be  imbedded  in  the
          document or will they appear as a supplement?

      2.  Should we specifically try to include the ISO community in our
          review cycles?

      3.  Other issues?




      6  SUMMARY

           The  people  that  reviewed  the  document  provided   highly
      valuable  technical  insight  and corrections.  In order for us to
      make this document as correct as possible, it  will  be  necessary
      for  this sort of review to continue to the document's completion.
!
                                                                Page 5


      As the document becomes larger and larger,  this  sort  of  review
      becomes more and more intimidating and time-consuming.  Therefore,
      I'd like to request help now working out the review cycle details,
      and  later  changing the review cycle algorithm if it doesn't work
      for you.  It would be much better to speak up if  you  don't  have
      time to review your part than to leave it left unread.

           The first request I have may be the  most  important  to  our
      success.   A  review  cycle plan will be coming to you within this
      month.  Please review it carefully, analyze the time you will have
      to  spend  on  this effort, and propose a task you can comfortably
      accomplish.  If I don't hear from you concerning the review  cycle
      plan,  I  will  assume you do not wish to review the standard.  If
      you are passing the document around to other people,  please  make
      sure  they  realize  that  their timely review is necessary to the
      success of this effort.  An unreviewed section  could  potentially
      remain  untouched, and perhaps will be wrong.  Urge the people you
      are counting on to review certain parts to only volunteer  for  as
      much as they can handle.

∂03-May-88  0658	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-PROPOSAL-FORMAT    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 88  06:58:43 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA04677; Tue, 3 May 88 06:58:45 PDT
Date: Tue, 3 May 88 06:58:45 PDT
Message-Id: <8805031358.AA04677@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN%aitg.DEC@decwrl.dec.com
Subject: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT

Issue: 		EDITORIAL-COMMITTEE-PROPOSAL-FORMAT

Category:     	Administrative

Edit History: 	Version 1, Kathy Chapman, 4/4/88
 
Problem Description: The editorial committee needs a standard format
		for submitting proposals

Proposal:	Proposals to the editorial committee should be submitted
		in the following format to cl-editorial@sail.stanford.edu.

	Issue: 		<title of issue>

	Category:     	<administrative/technical>

	Edit History: 	<version # - author - date>
 
	Problem Description: <why this issue was raised>

	Proposal:	<solution to the issue>

	Rationale:	<why this solution was chosen>
 
	Current Practice: <how the issue is currently dealt with>
 
	Cost to Implementors: <what the solution will cost vendors to implement>
 
	Cost to Users:	<how will this solution change a user's view>

	Cost of Non-adoption: <what will happen if nothing is done about the issue>

	Benefits: 	<what added value this solution provides>
 
	Discussion:	<discussion about this issue/solution>


Rationale:	Familiar, looks very similar to the clean-up committee
		proposal format.
 
Current Practice: No proposals have been submitted yet.
 
Cost to Implementors: None.
 
Cost to Users:	None.

Cost of Non-adoption: Non-standard formats for proposals will cause confusion.

Benefits: 	Tracking of issues with the CL standard will be easier.

Discussion:	

∂03-May-88  0909	CL-Editorial-mailer 	Re: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 May 88  09:09:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 03 MAY 88 09:03:07 PDT
Date: 3 May 88 09:02 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of Tue, 3 May 88 06:58:45
 PDT
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu
Message-ID: <880503-090307-5141@Xerox>

I think the editorial committee will need some less cumbersome mechanisms than
those adopted by the cleanup committee; the problem in cleanup is that there
were a lot of substantive issues that actually had costs and benefits to diverse
communities. I think given the schedule you should go for something leaner:
i.e., Cathy Chapman makes the decisions, and asks the editorial committee for
advice & review. 

With cl-cleanup, there were lots of proposals and no action, and the standard
format helped focus the discussions into the technical merits. Here, I don't see
a lot of proposals at all -- maybe you do? Are there some you are having trouble
dealing with? 

I have difficulty dealing with the abstract; maybe a concrete example of what
you think of as an "editorial committee proposal" might help me understand what
you're getting at.

∂03-May-88  1114	CL-Editorial-mailer 	editorial committee meeting  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 88  11:14:31 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA17581; Tue, 3 May 88 11:14:32 PDT
Date: Tue, 3 May 88 11:14:32 PDT
Message-Id: <8805031814.AA17581@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN%aitg.DEC@decwrl.dec.com
Subject: editorial committee meeting

I have requested a conference room for 6/14 in the afternoon for our
committee meeting. Does anyone have a problem with this?

kc

∂03-May-88  1118	CL-Editorial-mailer 	EDITORIAL-COMITTEE-STANDARD-REVIEW
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 88  11:18:15 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA17653; Tue, 3 May 88 11:18:12 PDT
Date: Tue, 3 May 88 11:18:12 PDT
Message-Id: <8805031818.AA17653@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN%aitg.DEC@decwrl.dec.com
Subject: EDITORIAL-COMITTEE-STANDARD-REVIEW

Issue: EDITORIAL-COMMITTEE-STANDARD-REVIEW
Category: Administrative
Edit History: Version 1, Kathy Chapman, 4/5/88
              Version 2, Kathy Chapman, 5/1/88

Problem Description: 
	Part 1: Reviewers must receive the parts of the
	standard they are meant to review either electronically or
	by hardcopy.
	Part 2: Reviewers must be able to comment on those sections
	they are reviewing electronically or by hardcopy.
	Part 3: Reviewers' comments must be incorporated, logged, and
	responded to electronically or by hardcopy.
	Part 4: Reviewers must have access to the complete standard and
	to the marked-up CLtL with pointers to the standard.

Proposal: 
	The files containing
	the standard are to be located in TEX format on 
	chapman@hudson.dec.com::sys$sysdevice:[chapman]*.tex.

	The review and comment process, if conducted electronically,
	will be handled by a mail monitor. A set of functions will be
	available to each group of reviewers (X3 committee, editorial
	committee, and others) which will facilitate the review process.
	
	If electronic access is not possible, it is possible to request
	a hardcopy in writing or telephonically.

	A summary of the mail monitor functions applicable to the X3
	committee follow: (use `cl-review' as subject)

	Function	Keywords		Description
        
	request		hardcopy (t or nil)	The latest copies of all 
			files (list)		sections you are responsible 
						for will be copied to 
 						chapman@hudson.dec.com,
						or mailed to your hardcopy
						address (see list below).

			
	comment		file (string)		The file being reviewed.
			qualifier (string)	Section # or contruct name.
			comment	(string)	The comment.
						A response to the comment is
						sent to the reviewer and
						cl-editorial. The possible
						files are listed below.

	update		update-frequency 	Amount of time (in days) be-
			(integer)		tween copies of the standard
						to hudson.dec.com (initially
						this is every 30 days).

	change		hardcopy-address (string) Use this function to change
			file-list (list)	the information in the data
						base that is part of this
						message. You can only change
						your own information.

	query		all-files (t or nil)	Get a list of possible files
			file-list (list)	to review, your file list,
			update-frequency	current update frequency,
			comment-list		current list of comments.

	In addition, to aid in reviewing, the mapping from the CLtL to
	the standard and visa versa will be located on hudson.dec.com
	in the files cltl-standard.txt and standard-cltl.txt.
	
	Examples:

	To request a hardcopy:

		From: decwrl::"rpg@sail.stanford.edu"
		To: chapman@hudson.dec.com
		Subject: cl-review

	Text:   (request :hardcopy t :files '(all))


	To comment on a chapter or section:

		From: decwrl::"rpg@sail.stanford.edu"
		To: chapman@hudson.dec.com
		Subject: cl-review

	Text:	(comment :chapter chap3 :qualifier "3.1.1.2" :comment
		"Paragraph 2: change wording from 
		function to macro")
			
	Possible files are:
			all (this means all you are responsible for reviewing)
			book (this means the whole standard)
			chap1
			chap2
			chap3
			ARRAYS
			CHARACTERS
			CONTROL-STRUCTURE
			DECLARATIONS
			ERRORS
			EVALUATOR
			FILES
			HASHTABLES
			IO
			LISTS
			MACROS
			MISC
			NUMBERS
			PACKAGES
			PREDICATES
			PROGRAM-STRUCTURE
			SEQUENCES
			STREAMS
			STRINGS
			STRUCTURES
			SYMBOLS
			TYPES
			chap5
			chap6			
			new-additions

Rationale: In order to get the standard done in a timely manner, it
	is necessary that the review process be stream-lined, but
	flexible.                                              

Current Practice: None.

Cost to Implementors: If a reviewer requests a hardcopy, it will be
	sent COD.

Cost to Users: Same as Cost to Implementers.    

Cost of Non-adoption: The review process could, in the best case, become
	unwieldy. In the worst case, reviewers could find that reviewing
	the document and submitting comments is too much trouble, and
	the document would thus not get reviewed.

Benefits: 
	1. Reviewers can review according to when their own schedules
	permit, not just when the document is available.
	2. Comments can be handled and logged automatically.

Discussion: Following are the default data base and the proposed review
	schedule.

	The default data base follows:

Sender					Data

maxiv@mu.edu				"Mary Boelk
					Johnson Controls, MS M67
					507 East Michigan St.
					Milwaukee, Wisconsin 53202"
					(chap1 chap3 packages symbols)
skona%csilvax@hub.ucsb.edu		
					"Skona Brittain
					Microcomputer System Consultants
					P.O. Box 747
					Santa Barbara, California 93102"
					(chap1 chap3 arrays control-structure declarations)
Willc%tekchips.crl@tektronix.tek.com	
					"Will Clinger
					Semantic Microsystems
					4470 SW Hall Blvd., Suite 340
					Beaverton, Oregon 97005"
					(chap1 chap3 chap5 chap6)
rpg@sail.stanford.edu			
					"Dr. Richard Gabriel
					Lucid, Inc.
					707 Laurel St.
					Menlo Park, California 94025"
					(chap1 chap2 chap3 chap5 chap6)
ida%utokyo-relay.csnet@csnet-relay.arpa 
					"Masayuki Ida
					Aoyama Cakuin University
					Computer Science Research Group
					Atsugi, Kanagawa JAPAN 243-01
					(book)
Gregor.pa@xerox.com			
					"Gregor Kiczales
					Xerox PARC
					3333 Coyote Hill Rd.
					Palo Alto, Calif. 94304"
					(chap1 chap3 clos)
barmar@think.com			
					"Barry Margolin
					Thinking Machines
					245 First St
					Cambridge, Mass. 02142"
					(chap1 chap3 structures evaluator)
Masinter.pa@xerox.com			
					"Larry Masinter
					Xerox PARC
					3333 Coyote Hill Rd.
					Palo Alto, Calif. 94304"
					(chap1 chap3 files hashtables io)
mathis@c.isi.edu			          
					"Bob Mathis
					
					9712 Ceralene Dr.
					Fairfax, Virginia 22032-1704"
					(chap1 chap3 numbers)

ohlander@VENERA.ISI.EDU			
					"Ron Ohlander
					USC-ISI
					4676 Admiralty Way
					Marina del Rey, California 90292"
					(chap1 chap3 lists macros)
KMP@SCRC-Stony-Brook.arpa		
					"Kent M. Pitman
					Symbolics, Inc.
					11 Cambridge Center
					Cambridge, Mass. 02142"
					(chap1 chap3 misc errors types)
jar@ai.ai.mit.edu			
					"Jonathan Rees
					MIT
					39 Clarendon St.
					Boston, Mass. 02116"
					(chap1 chap2 chap3 chap5 chap6)
jeffr@aai2.istc.sri.com			
					"Jeff Rininger EK339
					SRI International
					333 Ravenswood Avenue
					Menlo Park, California 94025"
					(chap1 chap3 predicates program-structure)
Rosenking@a.isi.edu			
					"Jeff Rosenking
					Grumman Corporate Research Center
					M/S A01-26
					Bethpage, NY 11714"
					(chap1 chap3 sequences streams)
SKeene@SCRC-Stony-Brook.arpa		
					"Sonya Keene
					Symbolics, Inc.
					11 Cambridge Center
					Cambridge, Mass. 02142"
					(chap1 chap3 strings characters)
gls@THINK.com				
					"Dr. Guy L. Steele Jr.
					Thinking Machines
					245 First St
					Cambridge, Mass. 02142"
					(chap1 chap2 chap3)

∂03-May-88  1251	CL-Editorial-mailer 	EDITORIAL-COMITTEE-STANDARD-REVIEW
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 May 88  12:51:31 PDT
Received: from fafnir.think.com by Think.COM; Tue, 3 May 88 15:49:55 EDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by fafnir.think.com; Tue, 3 May 88 15:49:50 EDT
Date: Tue, 3 May 88 15:51 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: EDITORIAL-COMITTEE-STANDARD-REVIEW
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <8805031818.AA17653@decwrl.dec.com>
Message-Id: <19880503195119.9.BARMAR@OCCAM.THINK.COM>

I don't understand this:

	Function	Keywords		Description
        
	request		hardcopy (t or nil)	The latest copies of all 
			files (list)		sections you are responsible 
						for will be copied to 
 						chapman@hudson.dec.com,
						or mailed to your hardcopy
						address (see list below).

If I request a section, why will it be copied to chapman, rather than
mailed to me?

Actually, I think that transmission of sections should be done using
file transfer if feasible.  Would it be possible for the sections to be
placed on a machine connected to the Arpanet, to which we could get FTP
access?  Email is a very poor mechanism for distribution of large
documents.

	comment		file (string)		The file being reviewed.
			qualifier (string)	Section # or contruct name.
			comment	(string)	The comment.
						A response to the comment is
						sent to the reviewer and
						cl-editorial. The possible
						files are listed below.

I don't like having to enclose the actual comment text in a string.  I
think it would be better to have the list at the beginning of the
message text, and then take the rest of the message as the text of the
comment.  If you want to allow multiple comments in a single message, we
could devise an escape sequence that indicates that another comment
descriptor follows, e.g.

	(comment :file chap3 :qualifier "3.1.1.2")
	Blah, blah, blah.
	Comment, comment, comment.
	-*-End-*-
	(comment :file chap1 :qualifier "1.3")
	More blah, blah, blah.

Requring the comment to be in a string is prone to errors, because we
may forget to slashify doublequotes and slashes when we include them in
the comment (and we will, I guarantee it).  A sequence like the above
"-*-End-*-" is unlikely to appear in a real comment.

	To comment on a chapter or section:

		From: decwrl::"rpg@sail.stanford.edu"
		To: chapman@hudson.dec.com
		Subject: cl-review

	Text:	(comment :chapter chap3 :qualifier "3.1.1.2" :comment
		"Paragraph 2: change wording from 
		function to macro")

The :chapter keyword isn't mentioned in the above description of the
"comment" operation.  Should that be :file?

                                                barmar

∂03-May-88  1302	CL-Editorial-mailer 	re:barmar comments 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 May 88  13:02:21 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA22604; Tue, 3 May 88 13:02:23 PDT
Message-Id: <8805032002.AA22604@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 May 88 16:02
To: cl-editorial@sail.stanford.edu
Subject: re:barmar comments

>Actually, I think that transmission of sections should be done using
>file transfer if feasible.  Would it be possible for the sections to be
>placed on a machine connected to the Arpanet, to which we could get FTP
>access?  Email is a very poor mechanism for distribution of large
>documents.
That's the idea, that's why the files are being copied to a node
that has FTP access, and then you can do the copy. Mail won't work
in this case. I'd like to do the FTP automatically, but can't promise
that right now.
 
No strings for comments, yes it should be :file.

kc

∂05-May-88  2216	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-STANDARD-REVIEW    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 5 May 88  22:16:06 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA04054; Thu, 5 May 88 22:16:11 PDT
Date: Thu, 5 May 88 22:16:11 PDT
Message-Id: <8805060516.AA04054@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN@decwrl.dec.com
Subject: EDITORIAL-COMMITTEE-STANDARD-REVIEW

Issue: EDITORIAL-COMMITTEE-STANDARD-REVIEW
Category: Administrative
Edit History: Version 1, Kathy Chapman, 4/5/88
              Version 2, Kathy Chapman, 5/1/88
              Version 3, Kathy Chapman, 5/6/88

Problem Description: 
	Part 1: Reviewers must receive the parts of the
	standard they are meant to review either electronically or
	by hardcopy.
	Part 2: Reviewers must be able to comment on those sections
	they are reviewing electronically or by hardcopy.
	Part 3: Reviewers' comments must be incorporated, logged, and
	responded to electronically or by hardcopy.
	Part 4: Reviewers must have access to the complete standard and
	to the marked-up CLtL with pointers to the standard.

Proposal: 
	The files containing
	the standard are to be located in TEX format on 
	chapman@hudson.dec.com::sys$sysdevice:[chapman]*.tex.
	This machine has FTP access so that you can copy the
	files you need to your location.

	The review and comment process, if conducted electronically,
	will be handled by a mail monitor. A set of functions will be
	available to each group of reviewers (X3 committee, editorial
	committee, and others) which will facilitate the review process.
	
	If electronic access is not possible, it is possible to request
	a hardcopy in writing or telephonically.

	A summary of the mail monitor functions applicable to the X3
	committee follow: (use `cl-review' as subject)

	Function	Keywords		Description
        
	request		hardcopy (t or nil)	The latest copies of all 
			files (list)		sections you are responsible 
						for will be copied to 
 						chapman@hudson.dec.com,
						or mailed to your hardcopy
						address (see list below).

			
	comment		file (string)		The file being reviewed.
			qualifier (string)	Section # or contruct name.
						A response to the comment is
						sent to the reviewer and
						cl-editorial. The possible
						files are listed below.

	update		update-frequency 	Amount of time (in days) be-
			(integer)		tween copies of the standard
						to hudson.dec.com (initially
						this is every 30 days).

	change		hardcopy-address (string) Use this function to change
			file-list (list)	the information in the data
						base that is part of this
						message. You can only change
						your own information.

	query		all-files (t or nil)	Get a list of possible files
			file-list (list)	to review, your file list,
			update-frequency	current update frequency,
			comment-list		current list of comments.

	In addition, to aid in reviewing, the mapping from the CLtL to
	the standard and visa versa will be located on hudson.dec.com
	in the files cltl-standard.txt and standard-cltl.txt.
	
	Examples:

	To request a hardcopy:

		From: decwrl::"rpg@sail.stanford.edu"
		To: chapman@hudson.dec.com
		Subject: cl-review

	Text:   (request :hardcopy t :files '(all))


	To comment on a chapter or section:

		From: decwrl::"rpg@sail.stanford.edu"
		To: chapman@hudson.dec.com
		Subject: cl-review

	Text:	(comment :file chap3 :qualifier "3.1.1.2")
		Paragraph 2: change wording from 
		function to macro.
			
	Possible files are:
			all (this means all you are responsible for reviewing)
			book (this means the whole standard)
			chap1
			chap2
			chap3
			ARRAYS
			CHARACTERS
			CONTROL-STRUCTURE
			DECLARATIONS
			ERRORS
			EVALUATOR
			FILES
			HASHTABLES
			IO
			LISTS
			MACROS
			MISC
			NUMBERS
			PACKAGES
			PREDICATES
			PROGRAM-STRUCTURE
			SEQUENCES
			STREAMS
			STRINGS
			STRUCTURES
			SYMBOLS
			TYPES
			chap5
			chap6			
			new-additions

Rationale: In order to get the standard done in a timely manner, it
	is necessary that the review process be stream-lined, but
	flexible.                                              

Current Practice: None.

Cost to Implementors: If a reviewer requests a hardcopy, it will be
	sent COD.

Cost to Users: Same as Cost to Implementers.    

Cost of Non-adoption: The review process could, in the best case, become
	unwieldy. In the worst case, reviewers could find that reviewing
	the document and submitting comments is too much trouble, and
	the document would thus not get reviewed.

Benefits: 
	1. Reviewers can review according to when their own schedules
	permit, not just when the document is available.
	2. Comments can be handled and logged automatically.

Discussion: Following are the default data base and the proposed review
	schedule.

	The default data base follows:

Sender					Data

maxiv@mu.edu				"Mary Boelk
					Johnson Controls, MS M67
					507 East Michigan St.
					Milwaukee, Wisconsin 53202"
					(chap1 chap3 packages symbols)
skona%csilvax@hub.ucsb.edu		
					"Skona Brittain
					Microcomputer System Consultants
					P.O. Box 747
					Santa Barbara, California 93102"
					(chap1 chap3 arrays control-structure declarations)
Willc%tekchips.crl@tektronix.tek.com	
					"Will Clinger
					Semantic Microsystems
					4470 SW Hall Blvd., Suite 340
					Beaverton, Oregon 97005"
					(chap1 chap3 chap5 chap6)
rpg@sail.stanford.edu			
					"Dr. Richard Gabriel
					Lucid, Inc.
					707 Laurel St.
					Menlo Park, California 94025"
					(chap1 chap2 chap3 chap5 chap6)
ida%utokyo-relay.csnet@csnet-relay.arpa 
					"Masayuki Ida
					Aoyama Cakuin University
					Computer Science Research Group
					Atsugi, Kanagawa JAPAN 243-01
					(book)
Gregor.pa@xerox.com			
					"Gregor Kiczales
					Xerox PARC
					3333 Coyote Hill Rd.
					Palo Alto, Calif. 94304"
					(chap1 chap3 clos)
barmar@think.com			
					"Barry Margolin
					Thinking Machines
					245 First St
					Cambridge, Mass. 02142"
					(chap1 chap3 structures evaluator)
Masinter.pa@xerox.com			
					"Larry Masinter
					Xerox PARC
					3333 Coyote Hill Rd.
					Palo Alto, Calif. 94304"
					(chap1 chap3 files hashtables io)
mathis@c.isi.edu			          
					"Bob Mathis
					
					9712 Ceralene Dr.
					Fairfax, Virginia 22032-1704"
					(chap1 chap3 numbers)

ander@VENERA.ISI.EDU			"e"
					"Ron Ohlander
					USC-ISI
					4676 Admiralty Way
					Marina del Rey, California 90292"
					(chap1 chap3 lists macros)
KMP@SCRC-Stony-Brook.arpa		
					"Kent M. Pitman
					Symbolics, Inc.
					11 Cambridge Center
					Cambridge, Mass. 02142"
					(chap1 chap3 misc errors types)
jar@ai.ai.mit.edu			
					"Jonathan Rees
					MIT
					39 Clarendon St.
					Boston, Mass. 02116"
					(chap1 chap2 chap3 chap5 chap6)
jeffr@aai2.istc.sri.com			
					"Jeff Rininger EK339
					SRI International
					333 Ravenswood Avenue
					Menlo Park, California 94025"
					(chap1 chap3 predicates program-structure)
Rosenking@a.isi.edu			
					"Jeff Rosenking
					Grumman Corporate Research Center
					M/S A01-26
					Bethpage, NY 11714"
					(chap1 chap3 sequences streams)
SKeene@SCRC-Stony-Brook.arpa		
					"Sonya Keene
					Symbolics, Inc.
					11 Cambridge Center
					Cambridge, Mass. 02142"
					(chap1 chap3 strings characters)
gls@THINK.com				
					"Dr. Guy L. Steele Jr.
					Thinking Machines
					245 First St
					Cambridge, Mass. 02142"
					(chap1 chap2 chap3)

∂06-May-88  0934	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-STANDARD-REVIEW    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 May 88  09:34:02 PDT
Received: from fafnir.think.com by Think.COM; Fri, 6 May 88 12:31:38 EDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by fafnir.think.com; Fri, 6 May 88 12:31:34 EDT
Date: Fri, 6 May 88 12:33 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: EDITORIAL-COMMITTEE-STANDARD-REVIEW
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, CHAPMAN@decwrl.dec.com
In-Reply-To: <8805060516.AA04054@decwrl.dec.com>
Message-Id: <19880506163301.0.BARMAR@OCCAM.THINK.COM>

This database entry doesn't look right:

ander@VENERA.ISI.EDU			"e"
					"Ron Ohlander
					USC-ISI
					4676 Admiralty Way
					Marina del Rey, California 90292"
					(chap1 chap3 lists macros)

What's the "e" for?  All the other entries have a single character
string between the email address and the section list.

                                                barmar

∂26-May-88  0728	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-PROPOSAL-FORMAT    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 May 88  07:28:20 PDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 410625; Thu 26-May-88 10:27:30 EDT
Date: Thu, 26 May 88 10:27 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@SAIL.STANFORD.EDU
In-Reply-To: <8805031358.AA04677@decwrl.dec.com>
Message-ID: <19880526142701.2.SKEENE@JUNCO.SCRC.Symbolics.COM>


I have the same questions Larry raised about the need for a proposal
format.  What kind of proposals do you expect?   I think the two kinds
of communications you're going to have with the X3J13 members are: 

1. suggestions, general comments, ideas, questions, flames
2. reviews of the draft

The first category can be dealt with informally, which would probably
save administrative time on your part.   We used the CLOS mailing list
this way and it worked fine.   If we had kept track of those
communications we would never have finished the spec.   You could save
the communications (without doing any administrative work) by 
archiving the editorial mailing list. 

∂26-May-88  0807	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-STANDARD-REVIEW    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 May 88  08:07:11 PDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 410651; Thu 26-May-88 11:07:19 EDT
Date: Thu, 26 May 88 11:06 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: EDITORIAL-COMMITTEE-STANDARD-REVIEW
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@SAIL.STANFORD.EDU, CHAPMAN@decwrl.dec.com
In-Reply-To: <8805060516.AA04054@decwrl.dec.com>
Message-ID: <19880526150653.3.SKEENE@JUNCO.SCRC.Symbolics.COM>


Personally, when I review documentation, I always do it in hardcopy.  As
a technical writer, I haven't ever found a reviewer who prefers to do it 
online.    I don't know if my experience is representative.   It is 
probably worth asking the group if they see themselves using the
electronic mail tools you proposed.   

When I get copies for Symbolians to review, I'll ftp the files to a
local machine and then print them.   I don't completely understand the
process for doing that.   Do I really have to use a mail monitor program
to copy files?   Also, I would want to copy dvi files, not tex files.
How would I do that?

Is there anything ready for review now?

∂26-May-88  1007	CL-Editorial-mailer 	hard copy
Received: from hub.ucsb.edu by SAIL.Stanford.EDU with TCP; 26 May 88  10:06:35 PDT
Received: from csilvax.ucsb.edu by hub.ucsb.edu (5.59) id AA28368; Thu, 26 May 88 10:07:01 PDT
Received: from  by csilvax.ucsb.CSNET (5.51) id AA16346; Thu, 26 May 88 10:00:33 PDT
Date: Thu, 26 May 88 10:00:33 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 26 May 88 10:00:33 PDT
To: cl-editorial@SAIL.Stanford.edu
Subject: hard copy

I strongly agree with Sonya about reviewing hard copy.  All my experience, 
as a reviewer and a reviewee, says that hard copy is preferable.  At this 
point I think that we should postpone discussing ways to do the work until
we start doing it and then see what tools we need to develop, if any.  Since
this committee is not overwhelming in size, I don't think that that will
cause problems.  Coordinating differences can probably be done by one person.
Mailing hard copy will cost money but I am quite confident that it will save 
a lot of time.  

I also strongly feel that hard copy should be available free to members of
the editorial committee.  I do not understand why this is the only committee
that exacts a monetary price for membership - aren't time, effort, ideas, etc.
enough?  At the March meeting two people told me that they agreed with my
position although they hadn't wanted to say so in front of the whole group.
So I suggest that we at least decide among ourselves how we feel about this
policy before the June meeting.  I joined this committee because I felt that 
it was the one to which I could contribute the most, but if I have to pay to 
do so, I will withdraw from it.  (as far as I know, ftp'ing files is not free 
unless it's a local call, and then they still need to be printed anyway.)  

skona

∂26-May-88  1123	CL-Editorial-mailer 	$$'s for Words
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I am one of the people who suggested that a nomimal fee be paid by folks
who request hardcopy, and the primary targets of this charge are members
of X3J13 who are not in the subcommittee.  If the basic part of the Common
Lisp specification will be about 300 pages long, and CLOS, Loop, and error
signaling are part of it, it will cost $4000 to copy and mail it to the
membership. Every CLOS mailing has cost us about $2000 to send out.  The
reason is to encourage only those who will actually do the work of
reviewing the material.  Another alternative is to raise the membership
fee for X3J13 to cover this cost, so that everyone will pay to get the
hard copies even if they don't want them. It seemed to me better to dun
only those who wanted it rather than everyone.

It's sort of like if you went to a big dinner and you ordered a cheap
meal, but some others ordered expensive ones, and they split the bill
evenly.

			-rpg-

∂26-May-88  1134	CL-Editorial-mailer 	re: Sonya's comments    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 26 May 88  11:32:24 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA29787; Thu, 26 May 88 11:32:36 PDT
Date: Thu, 26 May 88 11:32:36 PDT
Message-Id: <8805261832.AA29787@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu
Subject: re: Sonya's comments

>From:	DECWRL::"skeene@STONY-BROOK.SCRC.Symbolics.COM" "Sonya E. Keene  26-May-88 1106 EDT" 26-MAY-1988 11:03
>To:	aitg::chapman
>Subj:	EDITORIAL-COMMITTEE-STANDARD-REVIEW
>
>Cc: cl-editorial@SAIL.STANFORD.EDU, decwrl::CHAPMAN
 
 
>Personally, when I review documentation, I always do it in hardcopy.  As
>a technical writer, I haven't ever found a reviewer who prefers to do it 
>online.    I don't know if my experience is representative.   It is 
>probably worth asking the group if they see themselves using the
>electronic mail tools you proposed.   
I agree with you, I don't think it's possible to review a document longer
than 1 page from a terminal. The mechanism in the proposal is created
to manage comments and responses to them. It would be helpful to me
if you made comments electronically instead of in your hardcopy, but
even if you don't, that is how they will eventually be tracked. 

>When I get copies for Symbolians to review, I'll ftp the files to a
>local machine and then print them.   I don't completely understand the
>process for doing that.   Do I really have to use a mail monitor program
I don't currently plan to copy my files every day to the FTP machine
(which is not the same as my development machine for security reasons),
only once per month. If you want a more current copy to review, you need
to tell me somehow to copy the file to the FTP machine so you can copy
it.

>to copy files?   Also, I would want to copy dvi files, not tex files.
>How would I do that?
I can provide .dvi files, no problem.

>Is there anything ready for review now?
So glad to see you're anxious to review!
You will be receiving another mail message today that addresses when the
review should begin. 

kc

∂26-May-88  2052	CL-Editorial-mailer 	editorial committee meeting  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 26 May 88  20:52:10 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA24618; Thu, 26 May 88 20:52:22 PDT
Date: Thu, 26 May 88 20:52:22 PDT
Message-Id: <8805270352.AA24618@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, CHAPMAN@decwrl.dec.com
Subject: editorial committee meeting




           May 26, 1988

           Meeting reminder and status of the standard


           There will be a meeting of the editorial subcommittee on June
      14,  1988, at 1:00 in the St.  Croix Conference room at Symbolics.
      Please let me know if you have a problem with the meeting time  or
      place.

           I will be mailing the standard in its current  state  at  the
      end of next week.

           Since the last meeting, I have been collecting information on
      how  a review of a document like the standard should be conducted.
      One outcome of that exercise is the  review  proposal  you  should
      have  received  that  outlines a method for managing the review of
      the standard and the resulting comments.   It  also  became  clear
      that  limiting  the  number of times a reviewer had to look at the
      same document part was important  to  a  thorough  review  of  the
      document.   Therefore  I  suggest  that you consider reviewing the
      document after the completion of each  phase  of  its  life,  i.e.
      after  it  is a standardized version of the CLtL, after it has had
      all the issues, CLOS, and the condition system  incorporated  (and
      whatever  else  is going to be part of the standard), and after it
      has had all your comments included.

           For this meeting, I would like to accomplish the following:

      1.  I would like to get your concurrence  that  the  review  cycle
          proposal  is  adequate,  and  that  I  may  proceed  with  its
          implementation.

      2.  Very shortly after this meeting I would like to  start  making
          the  phase  I  version of the standard (the standardized CLtL)
          available for your review.  For this to be possible, I need to
          make  sure  that  you  think  that  at least some parts of the
          document are ready for review.

      3.  A professional indexer can be available to index the  standard
          if  we contract for her services in the near future.  I'd like
          to close the loop on this issue.

      4.  Check on the progress of the conformance proposal.

      5.  Check on the progress of the evaluation model.

      6.  Report on meetings  with  professional  typesetters  and  book
          designers, as well as the ANSI Editorial tutorial.



Looking forward to seeing you.

kathy chapman

∂10-Jun-88  0909	CL-Editorial-mailer 	standard mailing   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 10 Jun 88  09:09:32 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA00586; Fri, 10 Jun 88 09:08:30 PDT
Message-Id: <8806101608.AA00586@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 10 Jun 88 12:02
To: cl-editorial@sail.stanford.edu, PASQUALE%aitg.DEC@decwrl.dec.com,
        CHAPMAN%aitg.DEC@decwrl.dec.com
Subject: standard mailing

Due to an unavoidable delay, the snapshot of the standard was not mailed 
earlier this week as planned. Therefore, the following has been done:


1. There will be extra copies available at the editorial committee
meeting so that we can all look at it as we talk.

2. You should have a copy waiting for you when you get back home,
so there should be no need or you to waste space in your suitcase
(unless you need some light reading on the plane).

3. Borrow a copy from a local edit comm member? What about that,
Kent and Sonya?

Sorry for the inconvenience,
kc

∂16-Jun-88  1621	CL-Editorial-mailer 	Comments on the snapshot version  
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 16 Jun 88  16:20:50 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa00793; 16 Jun 88 15:50 EDT
Received: from utokyo-relay by RELAY.CS.NET id ay01482; 16 Jun 88 15:41 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
	id AA25593; Thu, 16 Jun 88 22:04:02 JST
Received: by aoyama.cc.aoyama.junet (3.2/6.3Junet-1.0)
	id AA02131; Thu, 16 Jun 88 14:53:45 JST
Date: Thu, 16 Jun 88 14:53:45 JST
From: Masayuki Ida <ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@aoyama.cc.aoyama.junet>
Message-Id: <8806160553.AA02131@aoyama.cc.aoyama.junet>
To: cl-editorial@SAIL.STANFORD.EDU
Subject: Comments on the snapshot version
Cc: ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET

Commonts on Fonts/Characters of the draft:
1) backquote character:
  I have lots of experiences of trouble caused by the font of backquote sign.
Since in japan, we have not so long history to handle backquote character
in computer languages, Users/Novices often forget to take care of
the difference of quote sign; "'" and "`".
(Especially with bad fonts. )
(So, it may be a japan domestic problem,... but) I think
the choice of the font for quote character is important.
The current choice is quite normal but if possible,
more distinctive fonts will help us.
2) With some relations to backquote issue, definition/explanation
of the character set used in the document:
Since I was an official member of JIS Basic committee and
I joined the working team for check ANSI Fortan77 in japan,
I wonder why there is no section describing the character set
used in the draft, say in chapter 1.
I feel a kind of following table might be inserted.

The Character Set used in this Standard
 symbol         meaning
 (               open parenthesis or left parenthesis
 )               close parenthesis or right parenthesis
 +               plus
 ...
 '               quote or single quote
 `               backquote
 ...

 Masayuki Ida


∂05-Jul-88  1129	CL-Editorial-mailer 	Editorial Committee Meetings - June    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 5 Jul 88  11:29:34 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA04673; Tue, 5 Jul 88 11:29:06 PDT
Message-Id: <8807051829.AA04673@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 5 Jul 88 14:27
To: cl-editorial@sail.stanford.edu
Subject: Editorial Committee Meetings - June




                         Editorial Committee Meetings
                   June 14, 1987 and June 16, 1987, Boston

           Attendees (at one or  both  meetings):   Mary  Boelke,  Skona
      Brittain,  Kathy  Chapman,  Linda  deMicheal,  Dick Gabriel, Sonya
      Keene, Barry Margolin,  Bob  Mathis,  Jeff  Piazza,  Kent  Pitman,
      Jonathan Rees, Jeff Rosenking, Guy Steele, Walter van Roggen



      1  SUMMARY OF ACTION ITEMS

           It was agreed that phase 1 of the standard would be ready for
      review  by mid-July.  This version may not contain all the changes
      recommended at the editorial committee meeting and  listed  below.
      However,  those changes will be incorporated before the completion
      of phase 2 if they are not in phase 1.

           It was also agreed that the committee would  try  to  have  a
      completed  phase  1 document by the fall meeting.  This means that
      changes by the section writers will have to be to  the  editor  no
      later  than  October  1,  preferably  sooner.   All  the committee
      members in the  following  list  are  section  writers.   See  the
      responsibilities of a section writer in the next section.


 Person               Responsibilities

 Mary Boelke          Packages, Symbols 

 Skona Brittain       Control Structure, Sequences 

 Kathy Chapman        Editor (see list of responsibilities below)
                      Chapters 1, 3, 5, 7, 8, Glossary 
                      Make up glossary of error terms, get approved by
                      error, edit, and CLOS committees
                      Create a proposal for handling language subsets

 Sonya Keene          Characters, Strings 

 Gregor Kiczales      CLOS 

 Barry Margolin       Arrays, Evaluator, IO, Structures 

 Bob Mathis           Numbers 

 Larry Masinter       Files, Hashtables, Lists, Predicates 

 Jeff Piazza          Declarations 

 Kent Pitman          Chapter 2, Errors, Miscellaneous, Types 

 Jonathan Rees        Chapter 4

 Jeff Rosenking       Macros, Streams 
!
                                                                Page 2



 Walter van Roggen    Program Structure 





      2  SUMMARY OF MEETINGS

      2.1  Meeting 1

      A new outline was proposed and accepted:

          Chapter 1 - Introduction

          Chapter 2 - Objects and Types (the current section 3.1)

          Chapter 3 - Object Syntax (the current section 3.2)

          Chapter 4 - Evaluation and Compilation (the  current  sections
          2.1, 2.2, and 2.4)

          Chapter 5 - Other Topics (the current sections 2.3 and 3.3)

          Chapter 6 - Catalog (the current chapter 4)

          Chapter 7 - Language syntax summary (the current chapter 5)

          Chapter 8 - Language formal semantics (the current chapter 6)

          Glossary

      A method of delegating responsibility was proposed  and  accepted.
      A summary of the method follows.

           The chapters have been EDITED.  That means  that  information
      from  CLtL has been included.  The job of the section writer is to
      take over the responsibility for the assigned sections.  If  there
      is  a  question about a section the writer is responsible for, the
      question goes to the writer.  After the section  has  been  turned
      over  to the writer, both the writer and the editor will be making
      changes, so the changes have to be coordinated and well marked.  A
      summary of section writer and editor responsibilities follows.

           Responsibilities of the section writer.

      1.  Get the most recent copies of the assigned material.

      2.  Find problems, make corrections, mark corrections in original.
          Send  corrections electronically, or mail them hardcopy to the
          editor.

      3.  Refrain from making any changes while the document is  in  the
          editor's control unless they are specifically requested.
!
                                                                Page 3


      4.  Answer questions about the sections.

      5.  Notify the committee as soon as you learn that  you  will  not
          have the time to help on the editorial committee.

      6.  Respond to comments,  incorporate  the  comment,  or  let  the
          commenter  know  why  it wasn't incorporated.  Review response
          with editor before responding.

      7.  Forward comments and your response to the editor so  they  can
          be tracked.

      8.  Receive comments on your section from  the  editor  and  draft
          responses.

      9.  Use the cl-editorial mailing list and other  experts  in  your
          area to resolve technical issues.

     10.  Be prepared to review the entire document after the completion
          of each phase.

      Responsibilities of the editor:

      1.  Make sections available to the writers upon request.

      2.  Refrain from making changes  while  the  document  is  in  the
          writer's control.

      3.  Include X3 issues, CLOS, ...

      4.  Annotate editorial changes in the source file.

      5.  Incorporate changes  made  by  the  writers  into  the  proper
          sections and proliferate those changes through the document if
          necessary.

      6.  Track comments on all sections.

      7.  Forward comments to the appropriate section writer.

      8.  Assist in resolving technical issues.

      9.  Resolve issues of style and format.


           Copies of the snapshot of the standard were  distributed  and
      reviewed  by  small  groups.   Kathy  Chapman will incorporate the
      recommendations suggested by the  groups  except  where  otherwise
      noted.

      1.  Group 1:  current Chapter 2:   Jonathan  Rees,  Dick  Gabriel,
          Jeff Piazza
!
                                                                Page 4


               Recommendations:

          1.  There should be more subsections in this chapter.

          2.  There should be  more  detail  in  the  evaluation  model.
              (Jonathan Rees will guide this effort.)

          3.  There should be a liaison person who tracks  the  compiler
              committee  issues and insures their correct insertion into
              this chapter in the standard.  (Kathy Chapman  is  working
              with Sandra Loosemore to make sure this happens.)


      2.  Group 2:  current Chapter 3:   Barry  Margolin,  Sonya  Keene,
          Walter van Roggen, Linda deMicheal

               Recommendations:

          1.  A list of all `tools' that apply to a certain object is to
              be supplied after the object description.

          2.  There should be more sections and subsections,  also  more
              introductory  material  before  each  section  break.   In
              particular, there should be a separate  section  for  each
              data  type.   Possible headings would be `Type Hierarchy',
              `Type Declarations', data type headings, `Coercion', `Type
              Specifiers'.

          3.  Move paragraphs at the bottom of page 3-3 and the  top  of
              page 3-4 elsewhere?

          4.  Move the discussion on arguments somewhere else?

          5.  Clarify the use of the terms type and data  type,  and  be
              consistent in their usage.

          6.  Define the  distinction  between  an  object  and  a  true
              object.

          7.  Move Figure 3-4 to earlier in the section.

          8.  Move print-read consistency rules.

          9.  Need to distinguish between  an  object  and  the  printed
              representation of an object.  (e.g.  p.  3-31)

         10.  Move  character  ordering  information  to  section  where
              characters as a data type is described.

         11.  Move figure 3-9 to earlier in the chapter.

         12.  Pages  3-35  through  3-39  contain  material  that  needs
              clarification or belongs elsewhere.
!
                                                                Page 5


         13.  Correct all numbering schemes for readability.

         14.  Give an overview of types before giving details.

         15.  Change  the  chapter  names  from   `Object   Syntax'   to
              `Read/write  Syntax'  and  `Objects  and  Types'  to `Data
              Types'.  (This is still under consideration.)


      3.  Group 3:  current Chapters 1  and  4:   Jeff  Rosenking,  Mary
          Boelke, Kent Pitman, Skona Brittain

               Recommendations:

          1.  Separate `Definitions' into `Notational  Conventions'  and
              glossary.

          2.  There is an issue about when function  definitions  should
              be  grouped.   Will the presence of a good index solve the
              problem of finding a  function  the  isn't  alphabetically
              organized?  Listing all functions in the format we are now
              using would mean a great many blank pages.

          3.  Rename `Purpose'  to  `Description'.   This  heading  will
              contain  a  summary  of  the  tool in the first one or two
              sentences.  It will also contain all intended  aspects  of
              the  tool,  but  does  not necessarily have to include all
              fields referenced below it.

          4.  Leave all fields in; decide  on  deletion  of  blank  ones
              before final review.  For example, under Side Effects, the
              word `none' should be entered if  there  are  no  entries,
              whereas,  if  there  are  no  entries under See Also, that
              heading should be deleted.

          5.  In syntax field and in running text, leave out  colons  on
              keywords.

          6.  Rename `Errors Signaled' to `Conditions'.  This field will
              contain all errors.

          7.  Rephrase the definitions of the fields at the beginning of
              Chapter 4.

          8.  Add   `Affected   By:'   heading.     (This    is    under
              consideration.)





      2.2  Meeting 2

           At this meeting, responsibilities for the  various  parts  of
      the standard were designated as follows:
!
                                                                Page 6


          Chapter 1 - Kathy Chapman

          Chapter 2 - Kent Pitman

          Chapter 3 - Kathy Chapman

          Chapter 4 - Jonathan Rees

          Chapter 5 - Kathy Chapman

          Chapter 6 - see below

          Arrays - Barry Margolin

          Characters - Sonya Keene

          Control Structure - Skona Brittain

          Declarations - Jeff Piazza

          Errors - Kent Pitman

          Evaluator - Barry Margolin

          Files - Larry Masinter

          Hashtables - Larry Masinter

          IO - Barry Margolin

          Lists - Larry Masinter

          Macros - Jeff Rosenking

          Miscellaneous - Kent Pitman

          Numbers - Bob Mathis

          Packages - Mary Boelke

          Predicates - Larry Masinter

          Program Structure - Walter van Roggen

          Sequences - Skona Brittain

          Streams - Jeff Rosenking

          Strings - Sonya Keene

          CLOS - Gregor Kiczales

          Structures - Barry Margolin
!
                                                                Page 7


          Symbols - Mary Boelke

          Types - Kent Pitman

          Chapter 7 - Kathy Chapman

          Chapter 8 - Kathy Chapman

∂19-Jul-88  1046	CL-Editorial-mailer 	just to let you know    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 19 Jul 88  10:46:03 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA03748; Tue, 19 Jul 88 10:45:25 PDT
Message-Id: <8807191745.AA03748@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 19 Jul 88 13:42
To: cl-editorial@sail.stanford.edu
Subject: just to let you know

I have having some logistic trouble moving the standard onto the FTP
machine for your to access.

I will let you know when I have succeeded, but it won't be before Friday.

I will be sending you hardcopies of the parts you are responsible for
at the beginning of next week.

Thanks in advance for your help.

kathy chapman

∂26-Jul-88  0613	CL-Editorial-mailer 	standard mailing   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 26 Jul 88  06:13:39 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA17263; Tue, 26 Jul 88 06:13:03 PDT
Message-Id: <8807261313.AA17263@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 26 Jul 88 09:11
To: cl-editorial@sail.stanford.edu
Subject: standard mailing

I am still having problems making the standard available for FTPing.
Your review hardcopies are in the mail.

Sorry for the delay.
kathy chapman

∂06-Aug-88  0325	CL-Editorial-mailer 	mailing list change
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Aug 88  03:25:30 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA01415; Sat, 6 Aug 88 03:24:48 PDT
Message-Id: <8808061024.AA01415@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Aug 88 06:23
To: cl-editorial@sail.stanford.edu
Subject: mailing list change

Please add Ellen Golden to cl-editorial.

ellen@stony-brook.scrc.symbolics.com

∂06-Aug-88  0326	CL-Editorial-mailer 	mailing list change
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Aug 88  03:26:07 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA01426; Sat, 6 Aug 88 03:25:21 PDT
Message-Id: <8808061025.AA01426@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Aug 88 06:24
To: cl-editorial@sail.stanford.edu
Subject: mailing list change

Please remove Sonya Keene from cl-editorial.

∂08-Aug-88  1243	CL-Editorial-mailer 	CL standard   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 8 Aug 88  12:43:09 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA13098; Mon, 8 Aug 88 12:42:23 PDT
Message-Id: <8808081942.AA13098@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 8 Aug 88 15:38
To: cl-editorial@sail.stanford.edu
Subject: CL standard

Finally I have overcome the logistic problems of getting the standard
on a machine from which you can FTP it.

The username is FTP_USER. The password is FTPPLEASEWORK.

The node is hudson.dec.com.

The first file you should copy is named read-me.txt. It tells you
which other files you will need.

Please don't be silent if you have problems.


Also, you may have noticed that you haven't gotten your standard that
was supposedly mailed 2 weeks ago. Don't worry, it's coming.

kc

∂23-Aug-88  0749	CL-Editorial-mailer 	standard 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 23 Aug 88  07:49:26 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA06814; Tue, 23 Aug 88 07:48:27 PDT
Message-Id: <8808231448.AA06814@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 23 Aug 88 10:43
To: cl-editorial@sail.stanford.edu
Subject: standard

Would any of you have a problem with my allowing all of X3J13 to access
the standard files now (before I have incorporated your comments)?

kc

∂23-Aug-88  0907	CL-Editorial-mailer 	standard 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Aug 88  09:07:39 PDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Tue, 23 Aug 88 12:06:18 EDT
Received: by joplin.think.com; Tue, 23 Aug 88 12:06:13 EDT
Date: Tue, 23 Aug 88 12:06:13 EDT
From: gls@Think.COM
Message-Id: <8808231606.AA03828@joplin.think.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 23 Aug 88 10:43 <8808231448.AA06814@decwrl.dec.com>
Subject: standard

   From: chapman%aitg.DEC@decwrl.dec.com
   Date: 23 Aug 88 10:43

   Would any of you have a problem with my allowing all of X3J13 to access
   the standard files now (before I have incorporated your comments)?

   kc


Fine with me.
--Guy

∂30-Aug-88  0858	CL-Editorial-mailer 	questions
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 Aug 88  08:58:25 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA29898; Tue, 30 Aug 88 07:13:36 PDT
Date: Tue, 30 Aug 88 07:13:36 PDT
Message-Id: <8808301413.AA29898@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu
Subject: questions

1. I am changing the wording in section 2.3 of the standard under SYMBOLS
from

"{\datatype Symbols} have the following 
components, the first three of which are user-visible.

\beginlist
\itemitem{--} The property list is a {\datatype list} of zero or more
elements
whose even-numbered components (calling the first component zero) 
are indicators (no duplicates on the same
property list are allowed)
and whose odd-numbered components are {\word objects}.
Any memory cell acceptable to @Macref[setf] can be used.
The property list of a {\datatype symbol}
may be destructively replaced."


to 


"{\datatype Symbols} have the following 
components, the first three of which are user-visible.

\beginlist
\itemitem{--} The property list is a {\datatype list} of zero or more
elements
whose even-numbered components (calling the first component zero) 
**are symbols (no duplicates on the same**
property list are allowed)
and whose odd-numbered components are {\word objects}.
Any memory cell acceptable to @Macref[setf] can be used.
The property list of a {\datatype symbol}
may be destructively replaced."


Does anyone have a problem with this?

2. In case you didn't notice, I have left out any phrases that go like

"other implementation-dependent bookkeeping actions may be taken ....".

Does anyone have a problem with this?


3. Also, I have not included any information about indentation of comments
in the standard. Is there a problem with this?


kc

∂30-Aug-88  1056	CL-Editorial-mailer 	Re: questions 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 Aug 88  10:55:09 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA11616; Tue, 30 Aug 88 10:54:00 PDT
Date: Tue, 30 Aug 88 10:54:00 PDT
Message-Id: <8808301754.AA11616@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: chapman%aitg.DEC@decwrl.dec.com
Subject: Re: questions

1. [defining property list indicators to be symbols]

  page 163 of CLtL does say that "a key (called the indicator), which is
  typically a symbol,..."

  This implies to me that non symbols are allowed as keys, which I believe
  is a good thing.  However, it doesn't seem to say how keys are supposed
  to be compared until you read the description of GET.  But that's information
  that can be moved around for completeness/clarity.

			---Walter

∂30-Aug-88  1350	CL-Editorial-mailer 	questions
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 30 Aug 88  13:50:27 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 30 Aug 88 16:40:16 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 30 Aug 88 16:47:10 EDT
Date: Tue, 30 Aug 88 16:47 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: questions
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <8808301413.AA29898@decwrl.dec.com>
Message-Id: <19880830204720.8.BARMAR@OCCAM.THINK.COM>

    Date: Tue, 30 Aug 88 07:13:36 PDT
    From: chapman%aitg.DEC@decwrl.dec.com

    1. I am changing the wording in section 2.3 of the standard under SYMBOLS
    from

    "{\datatype Symbols} have the following 
    components, the first three of which are user-visible.

    \beginlist
    \itemitem{--} The property list is a {\datatype list} of zero or more
    elements
    whose even-numbered components (calling the first component zero) 
    are indicators (no duplicates on the same
    property list are allowed)
    and whose odd-numbered components are {\word objects}.
    Any memory cell acceptable to @Macref[setf] can be used.
    The property list of a {\datatype symbol}
    may be destructively replaced."


    to 


    "{\datatype Symbols} have the following 
    components, the first three of which are user-visible.

    \beginlist
    \itemitem{--} The property list is a {\datatype list} of zero or more
    elements
    whose even-numbered components (calling the first component zero) 
    **are symbols (no duplicates on the same**
    property list are allowed)
    and whose odd-numbered components are {\word objects}.
    Any memory cell acceptable to @Macref[setf] can be used.
    The property list of a {\datatype symbol}
    may be destructively replaced."


    Does anyone have a problem with this?

I do.  There is NO rule in Common Lisp that says that property list
indicators must be symbols.

Also, the second sentence in both versions should be deleted.  This
section is supposed to be describing symbols, and property lists stored
in arbitrary locations are a completely separate issue (unfortunately,
both CLtL and the Symbolics manuals make this mistake of listing the
functions that operate on arbitrary property lists in the chapter on
symbols).

                                                barmar

∂30-Aug-88  1615	CL-Editorial-mailer 	questions
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 30 Aug 88  16:15:15 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 30 Aug 88 19:05:22 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 30 Aug 88 19:12:25 EDT
Date: Tue, 30 Aug 88 19:12 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: questions
To: jar@zurich.ai.mit.edu
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: <8808302224.AA00792@void>
Message-Id: <19880830231238.4.BARMAR@OCCAM.THINK.COM>

    Date: Tue, 30 Aug 88 18:24:13 edt
    From: jar@void.ai.mit.edu (Jonathan Rees)

    The first argument to GET must be a symbol (see page 164).  Therefore
    the only way to store non-symbol indicators would be with (SETF
    (SYMBOL-PLIST ..) ...), and the only way to get them would be with
    SYMBOL-PLIST.  This is silly, of course.  If you don't accept this
    interpretation that "valid first argument to GET" and "valid
    indicator" mean the same thing, or if you think GET should be changed,
    you should take it up with the cleanup committee.

The indicator is the SECOND argument to GET.  The first argument is the
symbol whose plist is being examined.

                                                barmar

∂31-Aug-88  1459	CL-Editorial-mailer 	questions
Received: from void (VOID.AI.MIT.EDU) by SAIL.Stanford.EDU with TCP; 31 Aug 88  14:59:46 PDT
Received: by VOID.AI.MIT.EDU; Tue, 30 Aug 88 18:24:13 edt
Date: Tue, 30 Aug 88 18:24:13 edt
From: jar@VOID.AI.MIT.EDU (Jonathan Rees)
Message-Id: <8808302224.AA00792@void>
To: barmar@Think.COM
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 30 Aug 88 16:47 EDT <19880830204720.8.BARMAR@OCCAM.THINK.COM>
Subject: questions
Reply-To: jar@zurich.ai.mit.edu

The first argument to GET must be a symbol (see page 164).  Therefore
the only way to store non-symbol indicators would be with (SETF
(SYMBOL-PLIST ..) ...), and the only way to get them would be with
SYMBOL-PLIST.  This is silly, of course.  If you don't accept this
interpretation that "valid first argument to GET" and "valid
indicator" mean the same thing, or if you think GET should be changed,
you should take it up with the cleanup committee.

∂31-Aug-88  1459	CL-Editorial-mailer 	questions
Received: from void (VOID.AI.MIT.EDU) by SAIL.Stanford.EDU with TCP; 31 Aug 88  14:59:23 PDT
Received: by VOID.AI.MIT.EDU; Wed, 31 Aug 88 16:16:17 edt
Date: Wed, 31 Aug 88 16:16:17 edt
From: jar@VOID.AI.MIT.EDU (Jonathan Rees)
Message-Id: <8808312016.AA01328@void>
To: barmar@Think.COM
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 30 Aug 88 19:12 EDT <19880830231238.4.BARMAR@OCCAM.THINK.COM>
Subject: questions
Reply-To: jar@zurich.ai.mit.edu

   Date: Tue, 30 Aug 88 19:12 EDT
   From: Barry Margolin <barmar@Think.COM>

   The indicator is the SECOND argument to GET.  The first argument is the
   symbol whose plist is being examined.

Silly me.  I withdraw my previous message.  An indicator can be anything.

∂02-Sep-88  2136	CL-Editorial-mailer 	wording about Symbols   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88  21:34:28 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 02 SEP 88 21:23:04 PDT
From: masinter.pa@Xerox.COM
Date: 2 Sep 88 21:21:15 PDT
Subject: wording about Symbols
To: chapman%aitg.dec@declwrl.dec.com
cc: cl-editorial@sail.stanford.edu
Message-ID: <880902-212304-7959@Xerox>

There was a discussion a while back that the wording which implied that symbols
had "components" was misleading, especially when thinking of symbols as
"atomic". I think it might be clearer just to say that symbols "have" a property
list, rather than they have it as a component.

-- 

On leaving things out: I don't think as a reviewer I can reasonably detect when
things get left out. I think some of the original comments are informative, and
in a few places (although not in this one) an important part of the semantics of
the language. Could at least some indication of the elisions be left in the
draft?

∂06-Sep-88  1348	CL-Editorial-mailer 	Notation in standard for function argument/value types
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88  13:48:04 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 6 Sep 88 16:47:19 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 6 Sep 88 16:43:20 EDT
Date: Tue, 6 Sep 88 16:43 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Notation in standard for function argument/value types
To: cl-editorial@sail.stanford.edu
Message-Id: <19880906204331.8.BARMAR@OCCAM.THINK.COM>

In reviewing sections of the CL draft, I have not been pleased with the
use of English to describe the types of arguments to and values of
functions.  Common Lisp provides a language for describing the types of
arguments and values: the FUNCTION declaration.  In other language
standards, it is common to use the language-provided function
declaration syntax to describe the library functions, so why not do the
same?  For example, COPY-READTABLE would be described with:

(proclaim (function copy-readtable (&optional (or readtable nil)
					      (or readtable nil))
				   readtable))

We would still have to use English to describe the default values, but
we would at least formalize the type specifications.  Many functions
have complex defaulting rules, so it probably wouldn't be too helpful to
try to formalize them this way.  There may also be a few functions with
strange type dependencies between arguments, which can't be described
using the above notation, but these are pretty rare.

A similar notation could be used for variables:

(proclaim (type (integer 2 36) *read-base*))

I'd be willing to enter these changes for the sections I'm responsible
for.  What do the rest of the people on the subcommittee think?

                                                barmar

∂06-Sep-88  1414	CL-Editorial-mailer 	Notation in standard for function argument/value types
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


Barry suggests using the FUNCTION declaration style for describing the
types of arguments and values of a function.  I think that unless X3J13
adopts a different semantics for the FUNCTION declaration, it would be
unwise to use this notation. You should carefully read the description on
pages 47 and 48 of CLtL to see what I mean.

The problem is that the current definition of FUNCTION type specifiers
is so confusing to average readers that linking this important piece of
information about a function to that confusing model will lead to trouble.

				-rpg-

∂06-Sep-88  1450	CL-Editorial-mailer 	Re: Notation in standard for function argument/value types 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88  14:49:56 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 SEP 88 14:38:14 PDT
Date: 6 Sep 88 14:37 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Notation in standard for function argument/value types
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Tue, 6 Sep 88 16:43
 EDT
To: Barry Margolin <barmar@Think.COM>
cc: cl-editorial@sail.stanford.edu
Message-ID: <880906-143814-11115@Xerox>

The semantics of the FUNCTION type declaration are the subject of a pending
cleanup issue: there is disagreement in theory and in current practice (that is,
people don't agree what they mean and the implementations that pay attention to
them don't agree either.)
 

∂06-Sep-88  2131	CL-Editorial-mailer 	Notation in standard for function argument/value types
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88  21:31:26 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 6 Sep 88 18:04:42 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 6 Sep 88 17:55:25 EDT
Date: Tue, 6 Sep 88 17:55 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Notation in standard for function argument/value types
To: Dick Gabriel <RPG@sail.stanford.edu>
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <czxPZ@SAIL.Stanford.EDU>
Message-Id: <19880906215531.0.BARMAR@OCCAM.THINK.COM>

    Date: 06 Sep 88  1414 PDT
    From: Dick Gabriel <RPG@sail.stanford.edu>

    Barry suggests using the FUNCTION declaration style for describing the
    types of arguments and values of a function.  I think that unless X3J13
    adopts a different semantics for the FUNCTION declaration, it would be
    unwise to use this notation. You should carefully read the description on
    pages 47 and 48 of CLtL to see what I mean.

I think I understand the FUNCTION type specifier, and in fact I believe
that it is just right for this type of thing.  If a particular
implementation compatibly extends the domain of a function it will still
be of the type specified in the CL spec, and the current definition of
the FUNCTION type allows this.  A FUNCTION declaration doesn't restrict
an implementation, it restricts a caller that is in the scope of the
declaration; in our case, it is a restriction on portable CL programs.
However, it places a requirement on implementations to accept at least
the types specified by the declaration; this is precisely what the
English version currently tries to do.

    The problem is that the current definition of FUNCTION type specifiers
    is so confusing to average readers that linking this important piece of
    information about a function to that confusing model will lead to trouble.

The audience of an ANSI language standard is not average readers.  It is
language designers (us), language implementors, and authors of books
intended for average readers.  Anyone who can't understand the FUNCTION
type specifier should not be attempting any of those tasks.  I agree
that the wording in CLtL is not the best, but I hope we can fix that in
the editing process.

                                                barmar

∂06-Sep-88  2346	CL-Editorial-mailer 	Re: Notation in standard for function argument/value types 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88  23:46:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 SEP 88 23:44:53 PDT
Date: 6 Sep 88 23:45 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Notation in standard for function argument/value types
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Tue, 6 Sep 88 16:43
 EDT
To: Barry Margolin <barmar@Think.COM>
cc: cl-editorial@sail.stanford.edu
Message-ID: <880906-234453-12009@Xerox>

Actually, we can accept the main point of Barmar's suggestion, which is to use
CL type specifiers instead of English where possible. The function type may have
problems, but you can just say

copy-readtable
	from-readtable  (or readtable null)
	to-readtable (or readtable null)

returns:
	readtable



without getting into the function-type-argument-type-semantics hair.

∂07-Sep-88  1017	CL-Editorial-mailer 	Audience of the Standard
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


Barry writes the following:

``The audience of an ANSI language standard is not average readers.  It is
language designers (us), language implementors, and authors of books
intended for average readers.  Anyone who can't understand the FUNCTION
type specifier should not be attempting any of those tasks.  I agree
that the wording in CLtL is not the best, but I hope we can fix that in
the editing process.''

I know what he is getting at, and it might be an appropriate comment at
the stage we're in, but I think it's a bad attitude to take. We really
ought to make this as accessible as we can to as many people as we can.
For example, Will Clinger and I were talking about how we could make
a denotational semantics for Lisp more accessible to average Lisp implementors.
Often an implementor will want to turn to the formal semantics to understand
something that is unclear from the other descriptions. We did not say,
well, someone who hasn't an advanced degree in mathematics should not be
attempting to read this, so why bother. Instead, we talked of how to
ease the reading and understanding woes of denotational semantics.

Average readers, as Barry points out, might be reading user's guides and
textbooks. But when the author of one of these smears a point to make the
reading easier, that average reader will want to go to the source. So why
assume that average readers won't see the document? Good writing and
presentation are needed everywhere, and we cannot legislate that away
because we assume only an elite readership.

			-rpg-

∂09-Sep-88  1217	CL-Editorial-mailer 	type specifiers    
Received: from hub.ucsb.edu (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 9 Sep 88  12:17:13 PDT
Received: from csilvax.ucsb.edu
	by hub.ucsb.edu (5.59/UCSB-v2)
	id AA13982; Fri, 9 Sep 88 12:16:33 PDT
Message-Id: <8809091916.AA13982@hub.ucsb.edu>
Received: from  by csilvax.ucsb.CSNET (5.51) id AA07642; Fri, 9 Sep 88 12:16:27 PDT
Date: Fri, 9 Sep 88 12:16:27 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Fri, 9 Sep 88 12:16:27 PDT
To: CL-Editorial@SAIL.Stanford.edu
Subject: type specifiers
Cc: skona%csilvax@hub.ucsb.edu

I think that Barmar's suggestion, as modified by Larry, would be 
a great improvement over the English descriptions.
But if we are going to incorporate it into Phase 1 revisions, we 
better decide quickly.
We probably should pick a precise format/style for it, so Kathy 
can keep the changes consistent among the chapters.
On second thought, I think we should postpone the change until 
Phase 2.  


∂12-Sep-88  0843	CL-Editorial-mailer 	committee
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88  08:42:59 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA25762; Mon, 12 Sep 88 08:41:43 PDT
Message-Id: <8809121541.AA25762@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 11:38
To: cl-editorial@sail.stanford.edu
Subject: committee

I am making plans for an editorial committee meeting on 10/10
beginning at 11:30AM and lasting until 3:30PM. The location
has not been determined. Please let me know if you have problems
with this date or time.

kc

∂12-Sep-88  1037	CL-Editorial-mailer 	Issue: CLOS-:initform-typographical-errors  
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


Issue: CLOS-:initform-typographical-errors
Category: Technical
Edit History: Version 1, Dick Gabriel, 9/12/88

Problem Description: 

     page 1-35 of the CLOS specification (88-002R) has two occurrences of
     the name initform that ought to be :initform:

     \item{\bull} Supplying a default initial value form for a slot.  A
     default initial value form for a slot is defined by using the {\bf
     :initform} slot option to {\bf defclass}.  If no initialization
     argument associated with that slot is given as an argument to {\bf
     make-instance} or is defaulted by {\bf :default-initargs}, this
     default initial value form is evaluated in the lexical environment of
     the {\bf defclass} form that defined it, and the resulting value is
     stored in the slot.  The {\bf initform} form for a local slot may be
     used when creating an instance, when updating an instance to conform
     to a redefined class, or when updating an instance to conform to the
     definition of a different class. The {\bf initform} form for a shared
     slot may be used when defining or re-defining the class.

     page 1-44 of the CLOS specification has one occurrence of
     the name initform that ought to be :initform:

     Methods for {\bf update-instance-for-redefined-class} may be defined
     to specify actions to be taken when an instance is updated.  If only
     {\bf :after} methods for {\bf update-instance-for-redefined-class} are
     defined, they will be run after the system-supplied primary method for
     initialization and therefore will not interfere with the default
     behavior of {\bf update-instance-for-redefined-class}.  Because no
     initialization arguments are passed to {\bf
     update-instance-for-redefined-class} when it is called by the system,
     the {\bf initform} forms for slots that are filled by {\bf :before}
     methods for {\bf update-instance-for-redefined-class} will not be
     evaluated by {\bf shared-initialize}.

     page 1-47 of the CLOS specification has one occurrence of
     the name initform that ought to be :initform:

     Methods for {\bf update-instance-for-different-class} may be defined
     to specify actions to be taken when an instance is updated.  If only
     {\bf :after} methods for {\bf update-instance-for-different-class} are
     defined, they will be run after the system-supplied primary method for
     initialization and will not interfere with the default behavior of
     {\bf update-instance-for-different-class}.  Because no initialization
     arguments are passed to {\bf update-instance-for-different-class} when
     it is called by {\bf change-class}, the {\bf initform} forms for slots
     that are filled by {\bf :before} methods for {\bf
     update-instance-for-different-class} will not be evaluated by {\bf
     shared-initialize}.

Proposal: 

     Insert : as indicated:

     page 1-35

     \item{\bull} Supplying a default initial value form for a slot.  A
     default initial value form for a slot is defined by using the {\bf
     :initform} slot option to {\bf defclass}.  If no initialization
     argument associated with that slot is given as an argument to {\bf
     make-instance} or is defaulted by {\bf :default-initargs}, this
     default initial value form is evaluated in the lexical environment of
     the {\bf defclass} form that defined it, and the resulting value is
     stored in the slot.  The {\bf :initform} form for a local slot may be
     used when creating an instance, when updating an instance to conform
     to a redefined class, or when updating an instance to conform to the
     definition of a different class. The {\bf :initform} form for a shared
     slot may be used when defining or re-defining the class.

     page 1-44

     Methods for {\bf update-instance-for-redefined-class} may be defined
     to specify actions to be taken when an instance is updated.  If only
     {\bf :after} methods for {\bf update-instance-for-redefined-class} are
     defined, they will be run after the system-supplied primary method for
     initialization and therefore will not interfere with the default
     behavior of {\bf update-instance-for-redefined-class}.  Because no
     initialization arguments are passed to {\bf
     update-instance-for-redefined-class} when it is called by the system,
     the {\bf :initform} forms for slots that are filled by {\bf :before}
     methods for {\bf update-instance-for-redefined-class} will not be
     evaluated by {\bf shared-initialize}.

     page 1-47

     Methods for {\bf update-instance-for-different-class} may be defined
     to specify actions to be taken when an instance is updated.  If only
     {\bf :after} methods for {\bf update-instance-for-different-class} are
     defined, they will be run after the system-supplied primary method for
     initialization and will not interfere with the default behavior of
     {\bf update-instance-for-different-class}.  Because no initialization
     arguments are passed to {\bf update-instance-for-different-class} when
     it is called by {\bf change-class}, the {\bf :initform} forms for slots
     that are filled by {\bf :before} methods for {\bf
     update-instance-for-different-class} will not be evaluated by {\bf
     shared-initialize}.

Rationale: Although not strictly necessary, :initform is used everywhere
           else in the document.

Current Practice:

Cost to Implementors: 

Cost to Users:

Cost of Non-adoption: Readers will be confused.

Benefits:  We will be considered more careful editors.

Discussion:  RPG will edit the changes in the original sources before
	     they are handed over to this committee.

∂19-Sep-88  1439	CL-Editorial-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Sep 88  14:38:59 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03479g; Mon, 19 Sep 88 13:37:14 PST
Received: by bhopal id AA14744g; Mon, 19 Sep 88 14:36:41 PDT
Date: Mon, 19 Sep 88 14:36:41 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809192136.AA14744@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU, GLS@Think.com,
        CL-Editorial@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Mon, 12 Sep 88 20:25 EDT <19880913002519.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)

re:    Proposal (HASH-TABLE-KEY-MODIFICATION:SPECIFY):
       . . . 

I fear this is far too vague to be a cleanup proposal, however well-
motivated it may have been.  Indeed, there was a discussion of this topic 
on Common-Lisp@SU-AI about a year ago (as well as a few related msgs quite 
recently), but the upshot of all the discussion was merely to "enlighten" 
more of the community about the techniques of hashing in general.  I think 
we should limit our efforts in this arena at giving advice to editors 
(such as Steele, and Chapman, etc.) on how to explain the consequences of 
some typical hashing techniques.


First, there is no generally agreed-upon notion of what a "component" is;
so the part where you say:

    In EQ and EQL hash tables, components of a key may be freely modified
    with no effect on the table.
    In EQUAL hash tables, it is an error to modify a component of a key.

isn't saying anything usable; or if it is, then it is something already
understood via channels outside this proscription.  Furthermore, it could
bog us down for months if we tried to specify "component" exactly.   For
example, is the bit-field (byte 3 5) of a fixnum X a "component"  of X?


Second, the "rule":

    If implementations define additional acceptable values for the :TEST
    argument to MAKE-HASH-TABLE, the rule is that it is an error to modify
    a component of a key if and only if that component affects the test
    function.  If that component cannot affect the test function, the hash
    table's operation must not be affected by modifying the component.

is completely inadequate.  You might as well say that it is an error to 
modify the components of list elements for any list that is passed to a 
sequence function with a :test argument of EQUAL.  What you probably meant
to say, in the hash-table context, is:

    ... it is an error to modify an object used as key in a hash table
    iff such modification affects either  (1) the outcome of equivalence  
    test used by the hash-table, or (2) the structure of the collision
    chains built up in the hash table [note that SXHASH, or a substitute 
    therefor, may be involved in the structure of collision chains].

[There might have to be a line saying that the :test component of a hash-
table is always an equivalence relation.]   However, CLtL neither specifies
that hash-tables must use some "collision chain" technique -- alists appear
to be a fully conforming implementation (albeit sloooow) -- nor does is even
specify that any such collision tecnhique must be based on the output of 
SXHASH.  About the most it says is that hashing should be "fast".

Unfortunately, nowhere does the discussion of HASH-TABLE-KEY-MODIFICATION
even mention collision chains.


An implementational note *might* be worth mentioning in the document
standard about how the historical intent of EQ/EQL tables was in fact 
to limit the information obtained from an object to merely the pointer 
itself (i.e., it's address), and that this usually meant faster hashing 
(in MacLisp, for example).  But with the spread of copying GC's (stop-
and-copy, generational, etc) this kind of dependency limitation forces 
some very odd behaviour on the memory-management subsystem, such as the 
need for rehashing after GC's, etc.  I really know of cases where an EQL 
table was grossly slower than an EQUAL table, simply because it forced so 
much more attention from the memory-management subsystem.

Typically, only very "introspective" code needs to know whether, say, two 
strings are EQL rather EQUAL; and very often even experienced users make 
the mistake of thinking that EQ means speed and EQUAL means sloth.
Certainly no one using Common Lisp should prefer an EQ/EQL table over
an EQUAL one, unless he is actually concerned with the implementational
identity of objects [such as in system code doing circularity checks,
or "constants" coalescing, or macromemo-izing, etc.].


I think the gist of these last two paragraphs is something that the 
standards editors could try to work into the next chapter on Hash-Tables
(and possibly something about "collision chains" being a frequent part
of hash-tables).  This would be preferable to having the cleanup sub-
committee try to solve the unsolvable problem of anticipating every 
possible consequence of every possible implementation technique for 
hash-tables.



-- JonL --


∂19-Sep-88  1505	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Sep 88  15:05:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 88 15:02:27 PDT
Date: 19 Sep 88 15:02 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Mon, 19 Sep 88 14:36:41
 PDT
To: Jon L White <jonl@lucid.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU,
 GLS@Think.com, CL-Editorial@SAIL.STANFORD.EDU
Message-ID: <880919-150227-2389@Xerox>

My immediate reaction to your message was that it was a hasty disqualification
of an otherwise valid issue for the cleanup committee to address. 

Certainly the issue needs to be addressed. If Kathy things it is reasonable to
do so within the scope of the editorial board, I'm happy to allow it to be
addressed there. 

However, it does seem like an issue that can be well-specified without resorting
to a discussion of copying garbage collectors and collision chains in the
specification.




∂19-Sep-88  1542	CL-Cleanup-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Sep 88  15:41:47 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461963; Mon 19-Sep-88 18:39:45 EDT
Date: Mon, 19 Sep 88 18:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
To: Jon L White <jonl@lucid.com>
cc: CL-Cleanup@SAIL.STANFORD.EDU, GLS@Think.com, CL-Editorial@SAIL.STANFORD.EDU
In-Reply-To: <8809192136.AA14744@bhopal>
Message-ID: <19880919223934.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 19 Sep 88 14:36:41 PDT
    From: Jon L White <jonl@lucid.com>

    ....
    First, there is no generally agreed-upon notion of what a "component" is;
    so the part where you say:

	In EQ and EQL hash tables, components of a key may be freely modified
	with no effect on the table.
	In EQUAL hash tables, it is an error to modify a component of a key.

    isn't saying anything usable; or if it is, then it is something already
    understood via channels outside this proscription.  

It's true that "component" is a vague notion.  As elaborated on later in
the proposal, "component" should be defined in terms of the test function.
Maybe this initial vague language should just be abandoned.

							Furthermore, it could
    bog us down for months if we tried to specify "component" exactly.   For
    example, is the bit-field (byte 3 5) of a fixnum X a "component"  of X?

Who cares, since Common Lisp does not provide any way to modify fixnums.

    Second, the "rule":

	If implementations define additional acceptable values for the :TEST
	argument to MAKE-HASH-TABLE, the rule is that it is an error to modify
	a component of a key if and only if that component affects the test
	function.  If that component cannot affect the test function, the hash
	table's operation must not be affected by modifying the component.

    is completely inadequate.  You might as well say that it is an error to 
    modify the components of list elements for any list that is passed to a 
    sequence function with a :test argument of EQUAL.

That's precisely what I would have said, if sequence functions were
permitted to create auxiliary data structures that encache information
about their arguments from one call to the next.  Since they are not
(although this is only implied by CLtL), there is no need to impose
such a restriction on their callers.

    What you probably meant
    to say, in the hash-table context, is:

	... it is an error to modify an object used as key in a hash table
	iff such modification affects either  (1) the outcome of equivalence  
	test used by the hash-table, or (2) the structure of the collision
	chains built up in the hash table [note that SXHASH, or a substitute 
	therefor, may be involved in the structure of collision chains].

    [There might have to be a line saying that the :test component of a hash-
    table is always an equivalence relation.]   However, CLtL neither specifies
    that hash-tables must use some "collision chain" technique -- alists appear
    to be a fully conforming implementation (albeit sloooow) -- nor does is even
    specify that any such collision tecnhique must be based on the output of 
    SXHASH.  About the most it says is that hashing should be "fast".

    Unfortunately, nowhere does the discussion of HASH-TABLE-KEY-MODIFICATION
    even mention collision chains.

I vehemently disagree with this, and I think you're being completely 
wrong-headed.  The point of the proposal was to state what are the
requirements on Common Lisp programs so that they will be portable
to all implementations of hash tables.  The internal details of hash
tables in some particular implementation are not relevant; furthermore,
discussing them can only mislead users into writing non-portable
programs.  What I meant to say was precisely what I did say.  I agree
that an editor could find more precise language than "affect the
test function" by which I mean "change the answer returned by the
test function."

    An implementational note *might* be worth mentioning in the document
    standard about how the historical intent of EQ/EQL tables was in fact 
    to limit the information obtained from an object to merely the pointer 
    itself (i.e., it's address), and that this usually meant faster hashing 
    (in MacLisp, for example).  But with the spread of copying GC's (stop-
    and-copy, generational, etc) this kind of dependency limitation forces 
    some very odd behaviour on the memory-management subsystem, such as the 
    need for rehashing after GC's, etc.  I really know of cases where an EQL 
    table was grossly slower than an EQUAL table, simply because it forced so 
    much more attention from the memory-management subsystem.

    Typically, only very "introspective" code needs to know whether, say, two 
    strings are EQL rather EQUAL; and very often even experienced users make 
    the mistake of thinking that EQ means speed and EQUAL means sloth.
    Certainly no one using Common Lisp should prefer an EQ/EQL table over
    an EQUAL one, unless he is actually concerned with the implementational
    identity of objects [such as in system code doing circularity checks,
    or "constants" coalescing, or macromemo-izing, etc.].


    I think the gist of these last two paragraphs is something that the 
    standards editors could try to work into the next chapter on Hash-Tables
    (and possibly something about "collision chains" being a frequent part
    of hash-tables).

I agree that it might be interesting to have a book that discusses the
performance tradeoffs in hash tables.  I don't think that has anything to
do with the issue at hand, which is to define what characteristics of hash
tables may or may not be assumed by portable programs.

    This would be preferable to having the cleanup sub-
    committee try to solve the unsolvable problem of anticipating every 
    possible consequence of every possible implementation technique for 
    hash-tables.

If you thought that's what the HASH-TABLE-KEY-MODIFICATION issue was
about, you misunderstood it.  It's about defining whether portable
programs may or may not perform side effects on objects used as
keys of hash tables, and which side-effects can be performed.  I
can see it needs to be written up in a form that is less easy
to misunderstand.  If I have time, which is not too likely, I'll
do that, otherwise I'll just forget it.

∂28-Sep-88  1344	CL-Editorial-mailer 	[Robert S. Boyer <boyer@CLI.COM>: Clean Up] 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88  13:44:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 13:39:55 PDT
Date: 28 Sep 88 13:40 PDT
From: masinter.pa@Xerox.COM
Subject: [Robert S. Boyer <boyer@CLI.COM>: Clean Up]
To: cl-editorial@sail.stanford.edu
Reply-to: boyer@cli.com
Message-ID: <880928-133955-1558@Xerox>

     ----- Begin Forwarded Messages -----

Return-Path: <boyer@CLI.COM>
Received: from CLI.COM ([10.8.0.62]) by Xerox.COM ; 28 SEP 88 13:01:55 PDT
Received: by CLI.COM (4.0/1); Wed, 28 Sep 88 14:59:46 CDT
Date: Wed, 28 Sep 88 14:59:46 CDT
From: Robert S. Boyer <boyer@CLI.COM>
Message-Id: <8809281959.AA13560@CLI.COM>
To: masinter.pa
Subject: Clean Up

Thanks very much!

I hope that the cleanup committee or some other part of the Common
Lisp official definition mechanism will publish a little example
system of several files and packages that exercises the PISERUI stuff,
a template for the rest of us perhaps to follow.  A good example is
sometimes worth as much as a specification, and it is something that
you can show to implementors, if it breaks in their implementation,
and say "You are not doing it right."  Sometimes specifications have
multiple interpretations.

Bob


     ----- End Forwarded Messages -----

∂28-Sep-88  1442	CL-Editorial-mailer 	as if you haven't got enough to review 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 28 Sep 88  14:41:52 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA25606; Wed, 28 Sep 88 14:40:15 PDT
Message-Id: <8809282140.AA25606@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 28 Sep 88 17:31
To: cl-editorial@sail.stanford.edu, POPA%TOWNS.DEC@decwrl.dec.com,
        DJAHANDARI%TOWNS.DEC@decwrl.dec.com, PIAZZA%aitg.DEC@decwrl.dec.com,
        VANROGGEN%aitg.DEC@decwrl.dec.com
Subject: as if you haven't got enough to review

Thanks to all of you who have mailed your comments on the standard. 
I will wait for all comments to come in before making the complete
list of comments and corrections organized by chapter available.

Following is the error terminology I (and others) are proposing 
should be adopted and incorporated into the standard. I would like
to make this available to X3 as a whole, but would rather wait
until you all have had a chance to review and comment. I would like
to have all your comments before the October meeting so we as a 
committee will be able to make a recommendation to X3.

Thanks for your help.

kc




                            Condition Terminology
                               September, 1988
           Edited by Kathy Chapman, Kent Pitman, Walter Van Roggen
!
                                                                Page 2


      1  INTRODUCTION

           Common Lisp  constructs  are  described  in  the  forthcoming
      standard  in  terms of their behavior in "situations" during which
      they  are   intended   to   be   used   (see   "Description"   and
      "Environment/Evaluation"  parts  of each construct specification),
      and  in  all  other  "situations"  (see   "Conditions"   part   of
      specification).

           A "situation" is the evaluation  of  an  expression  in  some
      specific  context.   A  "condition",  represented  by  a condition
      object, is a situation which has been  detected.   Some  types  of
      conditions are predefined by the Common Lisp system, and all types
      of conditions are subtypes  of  type  CONDITION,  i.e.   (typep  c
      'condition)  is  true if and only if C is a condition.  An "error"
      is a condition in which normal program execution may not  continue
      without  some  form  of  intervention (either interactively by the
      user or under some sort of program control).

           "Signalling" is the process by which a situation is announced
      by  a program and SIGNAL is a mechanism by which such announcement
      is done.  ERROR  and  CERROR  are  also  used  to  signal  errors.
      Signalling an error has no side-effect on the condition associated
      with the error, and there is  no  dynamic  state  contained  in  a
      condition  object.   The  interactive  interface for signalling is
      implementation-dependent.

           The  process  of  signalling  involves  the  search  for  and
      invocation  of a handler, which is a function of one argument (the
      condition) that attempts to deal with the situation.  Handlers are
      established  dynamically  using HANDLER-BIND or abstractions built
      on  HANDLER-BIND   such   as   HANDLER-CASE   and   IGNORE-ERRORS.
      IGNORE-ERRORS  is  used  to inhibit entry to the debugger when all
      errors  are  detected,  while  HANDLER-CASE  is  used  to  perform
      specified  actions  when  the  specified  situations  occur.  If a
      handler is found, it may either handle the situation by performing
      some  non-local  transfer  of  control  or "decline" by failing to
      perform a non-local transfer of control.  If  it  declines,  other
      handlers  are  sought.   If  no handler is found and the error was
      signalled by ERROR or CERROR, the  debugger  is  entered  with  no
      context change.

           The  debugger  prints  the  description  of   the   situation
      represented  by  the  error  being signalled along with contextual
      information perhaps including information such as  which  function
      detected  the  error.   The  debugger should prefix all lines in a
      multiline condition message with the character or indentation used
      in  the  first  of  the lines of the message.  The debugger allows
      interactive examination  or  modification  of  the  state  of  the
      program and restarting from the situation.

           The  condition  object  given  to  the  handler  is   created
      explicitly by an operation such as MAKE-CONDITION or implicitly by
      an operation such as SIGNAL.   The  handler  is  executed  in  the
      dynamic  context  of the program which has invoked it, except that
!
                                                                Page 3


      the set of available condition handlers will have been rebound  to
      the  value  that  was active at the time the condition handler was
      made active.



      2  TERMINOLOGY

           Situations  in  which  errors  might,  should,  or  must   be
      signalled  are  referred  to in the standard.  The wording used to
      describe such  situations  is  intended  to  have  precise  formal
      meaning.  The following list is a glossary of those meanings.

       -  A VALID PROGRAM

               is a program whose code adheres to  the  requirements  of
          conforming code listed as follows:

           -  Conforming code shall not use any constructions  that  are
              prohibited by the standard.

           -  Conforming code shall not depend on extensions included in
              an implementation.

           -  Conforming code shall not use any extension included in an
              implementation.


       -  A SAFE SITUATION

               is  a  situation  in  which  interpreted  code,  or  code
          compiled with the safest optimization level is run.

       -  AN UNSAFE SITUATION

               is a situation in which code is  run  with  lower  safety
          levels.

       -  AN ERROR "IS SIGNALLED"

               means that

           -  If this situation occurs, the error will be signalled,  in
              both safe and unsafe situations.

           -  Valid programs may rely on the fact that the error will be
              signalled in both safe and unsafe situations.

           -  Every implementation is required to detect  the  error  in
              both safe and unsafe situations.


               For example, "an `error  is  signalled'  if  UNEXPORT  is
          given a symbol not accessible in the current package."
!
                                                                Page 4


       -  AN ERROR "SHOULD BE SIGNALLED"

               means that

           -  If this situation occurs, the error will be  signalled  in
              safe situations but may not be signalled in unsafe ones.

           -  Valid programs may not rely on the  fact  that  the  error
              will be signalled.

           -  Every implementation is required to detect  the  error  at
              least in safe situations.

           -  When the error is not  signalled,  the  "consequences  are
              undefined" (see below).


               In summary, the situation which has been identified as an
          error   is   illegal   in   all   implementations,   but  some
          implementations do not actually detect the situation.

               For example, "an error `should be signalled' if  ENDP  is
          given a non-list argument."

       -  THE "CONSEQUENCES ARE UNDEFINED"

               means that

           -  If   this   situation   occurs,   the   consequences   are
              unpredictable.   The  consequences may range from harmless
              to fatal.

           -  Implementations are allowed to detect this  situation  and
              signal  an  error,  but  no  implementation is required to
              detect the situation.

           -  No valid  program  may  depend  on  the  effects  of  this
              situation,  and  all  valid programs are required to treat
              the effects of this situation as unpredictable.

           -  In places where the words "must", "must not" or "may  not"
              are  used,  then  "the  consequences are undefined" if the
              stated requirement is not met, and no specific consequence
              is explicitly stated.


               There are two principal reasons why this language permits
          a  situation  to  have  an  undefined  consequence rather than
          requiring an error to be signalled:

           -  Detecting the situation might be  prohibitively  expensive
              in some or all implementations.
!
                                                                Page 5


           -  The situation can be implemented as an extension.


               For example, "the `consequences are undefined'  is  there
          is an attempt to redefine the name of a special form."

       -  THE "RETURN VALUES ARE UNDEFINED"

               means that only the  number  and  nature  of  the  return
          values of a construct are not well defined but any side-effect
          and transfer-of-control behavior is well defined.

               For example, if the return values of some function F  are
          undefined,  then  an expression such as (length (list (F))) is
          still well-defined because it does not rely on any  particular
          aspect of the value or values returned by F.

       -  THE "CONSEQUENCES ARE UNSPECIFIED"

               means that

           -  The consequences of this situation are  not  specified  in
              the  standard,  but  are  will  not,  by themselves, cause
              execution to abnormally terminate.

           -  Implementations are allowed to specify the consequences of
              this situation.

           -  No portable program can depend on the consequences of this
              situation, and all portable programs are required to treat
              the situation as unpredictable but harmless.


               For example, "if the second argument to SHARED-INITIALIZE
          specifies  a  name  that  does  not  correspond  to  any slots
          accessible   in   the   instance,   the   `consequences    are
          unspecified.'"

       -  "IMPLEMENTATIONS MAY BE EXTENDED" TO COVER THIS SITUATION

               means  that  an  implementation  is  free  to  treat  the
          situation in ANY ONE of the following ways.

          1.  When the situation occurs, an error is signalled at  least
              in safe situations,

                   OR

          2.  When  the  situation   occurs,   the   "consequences   are
              undefined",

                   OR
!
                                                                Page 6


          3.  When the situation occurs, the  consequences  are  defined
              and specified.


               Also, no portable program can depend on the  consequences
          of  this  situation, and all portable programs are required to
          treat the consequences of the situation as undefined.

               For example, "`implementations may be extended' to define
          other type specifiers to have a corresponding class."

       -  IMPLEMENTATIONS ARE "FREE TO EXTEND THE SYNTAX"

               means that in this situation

           -  Implementations  are   allowed   to   define   unambiguous
              extensions to the syntax of the construct being described.

           -  No portable program can  depend  on  this  extension,  all
              portable  programs  are  required  to  treat the syntax as
              meaningless.


               The  standard  may  disallow  certain  extensions   while
          allowing others.

               For example, "no `implementation is free  to  extend  the
          syntax' of DEFCLASS."

       -  A "WARNING IS ISSUED"

               means that

           -  If  this  situation  occurs,  a  warning  is  issued,   as
              described in WARN, in both safe and unsafe situations.

           -  Valid programs may rely on the fact that a warning will be
              issued in both safe and unsafe situations.

           -  Every implementation is required to detect this  situation
              in both safe and unsafe situations.


               For example, "a `warning is issued' by the compiler if  a
          declaration specifier is not one of those defined in Chapter 9
          of  CLtL  and  has  not  been  declared   in   a   DECLARATION
          declaration."

       -  A "WARNING SHOULD BE ISSUED"

               means that

           -  If this situation occurs, a  warning  will  be  issued  at
              least in safe situations.
!
                                                                Page 7


           -  Valid programs may not rely on the  fact  that  a  warning
              will be issued.

           -  Every  implementation  is  required  to  detect   such   a
              situation at least in safe situations.


               For example, "a warning `should be issued' by a  compiler
          if a variable declared to be ignored is ever referred to or is
          also declared special, or if  a  variable  is  lexical,  never
          referred  to, and not declared to be ignored." (see Chapter 9,
          CLtL)


∂28-Sep-88  1707	CL-Editorial-mailer 	as if you haven't got enough to review 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88  17:07:13 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 28 Sep 88 20:06:58 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 28 Sep 88 20:03:51 EDT
Date: Wed, 28 Sep 88 20:04 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: as if you haven't got enough to review
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, POPA%TOWNS.DEC@decwrl.dec.com,
        DJAHANDARI%TOWNS.DEC@decwrl.dec.com, PIAZZA%aitg.DEC@decwrl.dec.com,
        VANROGGEN%aitg.DEC@decwrl.dec.com
In-Reply-To: <8809282140.AA25606@decwrl.dec.com>
Message-Id: <19880929000421.5.BARMAR@OCCAM.THINK.COM>

    Date: 28 Sep 88 17:31
    From: chapman%aitg.DEC@decwrl.dec.com

	   -  AN UNSAFE SITUATION
    
		   is a situation in which code is  run  with  lower  safety
	      levels.

This should be "code compiled with lower safety levels is run."

	   -  AN ERROR "SHOULD BE SIGNALLED"

I'm not crazy about this particular terminology.  I prefer something
somewhat less forceful than "should", such as "might" or "may".  But I'm
not adamant about it.

	   -  THE "CONSEQUENCES ARE UNDEFINED"

	       -  In places where the words "must", "must not" or "may  not"
		  are  used,  then  "the  consequences are undefined" if the
		  stated requirement is not met, and no specific consequence
		  is explicitly stated.

I think this should also mention that this includes various implicit
requirements.  For example, where the standard specifies the number and
types of arguments of a function, the "consequences are undefined" if
such specifications are not met (in the absence of more specific
language in a particular case).

		   There are two principal reasons why this language permits
	      a  situation  to  have  an  undefined  consequence rather than
	      requiring an error to be signalled:

	       ...

	       -  The situation can be implemented as an extension.


If this is the case, then what is the difference between "CONSEQUENCES
ARE UNDEFINED" and "IMPLEMENTATIONS MAY BE EXTENDED"?

	   -  THE "CONSEQUENCES ARE UNSPECIFIED"

		   means that

	       -  The consequences of this situation are  not  specified  in
		  the  standard,  but  are  will  not,  by themselves, cause
		  execution to abnormally terminate.

"are will" should be "will".

	       -  Implementations are allowed to specify the consequences of
		  this situation.

	       -  No portable program can depend on the consequences of this
		  situation, and all portable programs are required to treat
		  the situation as unpredictable but harmless.

I also don't care for this particular term.  "Unspecified" and
"undefined" are too similar in meaning.  How about "consequences are
undefined but benign"?

		   The  standard  may  disallow  certain  extensions   while
	      allowing others.

		   For example, "no `implementation is free  to  extend  the
	      syntax' of DEFCLASS."

I maintain that any such prohibition is meaningless, or at least
unenforceable.  How does this differ from "the consequences are
undefined if DEFCLASS is invoked with syntax other than that specified
in the standard"?  In both cases, it means that a portable program may
not depend on the behavior.  What business do we have constraining how
an implementation deals with nonportable programs?

If you want to constrain implementations, it should be done with a
requirement rather than a prohibition.  For instance, "an 'error is
signalled' if DEFCLASS is invoked with syntax not conforming to this
specification".  This prevents syntax extensions because it would break
a portable program that relies on the error being signalled.

	   -  A "WARNING IS ISSUED"

		   means that

	       -  If  this  situation  occurs,  a  warning  is  issued,   as
		  described in WARN, in both safe and unsafe situations.

	       -  Valid programs may rely on the fact that a warning will be
		  issued in both safe and unsafe situations.

	       -  Every implementation is required to detect this  situation
		  in both safe and unsafe situations.

		   For example, "a `warning is issued' by the compiler if  a
	      declaration specifier is not one of those defined in Chapter 9
	      of  CLtL  and  has  not  been  declared   in   a   DECLARATION
	      declaration."

This doesn't say what the results are in such situations.

	   -  A "WARNING SHOULD BE ISSUED"

		   means that

	       -  If this situation occurs, a  warning  will  be  issued  at
		  least in safe situations.

	       -  Valid programs may not rely on the  fact  that  a  warning
		  will be issued.

	       -  Every  implementation  is  required  to  detect   such   a
		  situation at least in safe situations.


		   For example, "a warning `should be issued' by a  compiler
	      if a variable declared to be ignored is ever referred to or is
	      also declared special, or if  a  variable  is  lexical,  never
	      referred  to, and not declared to be ignored." (see Chapter 9,
	      CLtL)

Both "warning" examples only mention warnings issued by the compiler.
In that case, what is the distinction between safe and unsafe
situations?  The definitions of "safe" and "unsafe" specify "when code
is run"; is there any situation in which a warning is/should be issued
at run time?.  At compile time the only code that is run is the compiler
itself (which I would assume is generally compiled with the lowest
safety level before being shipped to customers) and any macros used in
the program (and any implementation-supplied macros will also probably
be compiled with lowest safety, and there is no way for portable,
user-written macros to access the safety level), but I don't think this
section is referring to either of them.

Also, what does it mean for a program to "rely on the fact that a
warning will be issued"?  The only way I know of to even DETECT that a
warning was issued is to redirect *ERROR-OUTPUT* to a file or string and
then see whether it contains anything after the operation.

                                                barmar

∂29-Sep-88  1220	CL-Editorial-mailer 	re: barmar comments on error paper
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 29 Sep 88  12:20:00 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA08007; Thu, 29 Sep 88 12:18:24 PDT
Message-Id: <8809291918.AA08007@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 29 Sep 88 15:16
To: cl-editorial@sail.stanford.edu, DJAHANDARI%TOWNS.DEC@decwrl.dec.com,
        POPA%TOWNS.DEC@decwrl.dec.com, PIAZZA%aitg.DEC@decwrl.dec.com
Subject: re: barmar comments on error paper

>	   -  AN UNSAFE SITUATION
>    
>		   is a situation in which code is  run  with  lower  safety
>	      levels.
> 
>This should be "code compiled with lower safety levels is run."
Done.
 
>	   -  AN ERROR "SHOULD BE SIGNALLED"
> 
>I'm not crazy about this particular terminology.  I prefer something
>somewhat less forceful than "should", such as "might" or "may".  But I'm
>not adamant about it.
My interpretation: `might' or `may' are words a user needs to hear
in this situation; `should' is a word an implementer should see. I know
this isn't an implementation guide, but it's more of that than it is
a user's guide; thus the choice of words makes sense to me.
 
>	   -  THE "CONSEQUENCES ARE UNDEFINED"
> 
>	       -  In places where the words "must", "must not" or "may  not"
>		  are  used,  then  "the  consequences are undefined" if the
>		  stated requirement is not met, and no specific consequence
>		  is explicitly stated.
> 
>I think this should also mention that this includes various implicit
>requirements.  For example, where the standard specifies the number and
>types of arguments of a function, the "consequences are undefined" if
>such specifications are not met (in the absence of more specific
>language in a particular case).
Actually the case you mention will be explicit in the standard, not
implicit. Do you have other examples of implicit requirements?
 
>		   There are two principal reasons why this language permits
>	      a  situation  to  have  an  undefined  consequence rather than
>	      requiring an error to be signalled:
> 
>	       ...
> 
>	       -  The situation can be implemented as an extension.
>
>If this is the case, then what is the difference between "CONSEQUENCES
>ARE UNDEFINED" and "IMPLEMENTATIONS MAY BE EXTENDED"?
The definitions of these two phrases are different, one just happens to
indirectly refer to the other. 
 
>	   -  THE "CONSEQUENCES ARE UNSPECIFIED"
> 
>		   means that
> 
>	       -  The consequences of this situation are  not  specified  in
>		  the  standard,  but  are  will  not,  by themselves, cause
>		  execution to abnormally terminate.
> 
>"are will" should be "will".
Done. 

>	       -  Implementations are allowed to specify the consequences of
>		  this situation.
> 
>	       -  No portable program can depend on the consequences of this
>		  situation, and all portable programs are required to treat
>		  the situation as unpredictable but harmless.
 
>I also don't care for this particular term.  "Unspecified" and
>"undefined" are too similar in meaning.  How about "consequences are
>undefined but benign"?
Instead of "CONSEQUENCES ARE UNSPECIFIED"?
 
>		   The  standard  may  disallow  certain  extensions   while
>	      allowing others.
> 
>		   For example, "no `implementation is free  to  extend  the
>	      syntax' of DEFCLASS."
> 
>I maintain that any such prohibition is meaningless, or at least
>unenforceable.  How does this differ from "the consequences are
>undefined if DEFCLASS is invoked with syntax other than that specified
>in the standard"?  In both cases, it means that a portable program may
>not depend on the behavior.  What business do we have constraining how
>an implementation deals with nonportable programs?
 
>If you want to constrain implementations, it should be done with a
>requirement rather than a prohibition.  For instance, "an 'error is
>signalled' if DEFCLASS is invoked with syntax not conforming to this
>specification".  This prevents syntax extensions because it would break
>a portable program that relies on the error being signalled.
I agree, but would like to hear from the CLOSers about why a prohibition
rather than a requirement was used in this case.

 
>	   -  A "WARNING IS ISSUED"
> 
>		   means that
> 
>	       -  If  this  situation  occurs,  a  warning  is  issued,   as
>		  described in WARN, in both safe and unsafe situations.
> 
>	       -  Valid programs may rely on the fact that a warning will be
>		  issued in both safe and unsafe situations.
> 
>	       -  Every implementation is required to detect this  situation
>		  in both safe and unsafe situations.
> 
>		   For example, "a `warning is issued' by the compiler if  a
>	      declaration specifier is not one of those defined in Chapter 9
>	      of  CLtL  and  has  not  been  declared   in   a   DECLARATION
>	      declaration."
> 
>This doesn't say what the results are in such situations.
Which results? which situation?
> 
>	   -  A "WARNING SHOULD BE ISSUED"
> 
>		   means that
> 
>	       -  If this situation occurs, a  warning  will  be  issued  at
>		  least in safe situations.
> 
>	       -  Valid programs may not rely on the  fact  that  a  warning
>		  will be issued.
> 
>	       -  Every  implementation  is  required  to  detect   such   a
>		  situation at least in safe situations.
> 
> 
>		   For example, "a warning `should be issued' by a  compiler
>	      if a variable declared to be ignored is ever referred to or is
>	      also declared special, or if  a  variable  is  lexical,  never
>	      referred  to, and not declared to be ignored." (see Chapter 9,
>	      CLtL)
> 
>Both "warning" examples only mention warnings issued by the compiler.
>In that case, what is the distinction between safe and unsafe
>situations?  The definitions of "safe" and "unsafe" specify "when code
>is run"; is there any situation in which a warning is/should be issued
>at run time?.  At compile time the only code that is run is the compiler
>itself (which I would assume is generally compiled with the lowest
>safety level before being shipped to customers) and any macros used in
>the program (and any implementation-supplied macros will also probably
>be compiled with lowest safety, and there is no way for portable,
>user-written macros to access the safety level), but I don't think this
>section is referring to either of them.
Currently in CLtL the only time warnings are mentioned is in conjunction
with the compiler (did I miss something?). However, is there a problem 
with generalizing warnings?
 
>Also, what does it mean for a program to "rely on the fact that a
>warning will be issued"?  The only way I know of to even DETECT that a
>warning was issued is to redirect *ERROR-OUTPUT* to a file or string and
>then see whether it contains anything after the operation.
Sounds like you answered your own question. Is there better wording?

kc

∂29-Sep-88  1404	CL-Editorial-mailer 	re: barmar comments on error paper
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Sep 88  14:03:15 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 29 Sep 88 16:55:56 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 29 Sep 88 16:59:54 EDT
Date: Thu, 29 Sep 88 17:00 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: re: barmar comments on error paper
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, DJAHANDARI%TOWNS.DEC@decwrl.dec.com,
        POPA%TOWNS.DEC@decwrl.dec.com, PIAZZA%aitg.DEC@decwrl.dec.com
In-Reply-To: <8809291918.AA08007@decwrl.dec.com>
Message-Id: <19880929210023.4.BARMAR@OCCAM.THINK.COM>

    Date: 29 Sep 88 15:16
    From: chapman%aitg.DEC@decwrl.dec.com

    >	   -  THE "CONSEQUENCES ARE UNDEFINED"
    > 
    >	       -  In places where the words "must", "must not" or "may  not"
    >		  are  used,  then  "the  consequences are undefined" if the
    >		  stated requirement is not met, and no specific consequence
    >		  is explicitly stated.
    > 
    >I think this should also mention that this includes various implicit
    >requirements.  For example, where the standard specifies the number and
    >types of arguments of a function, the "consequences are undefined" if
    >such specifications are not met (in the absence of more specific
    >language in a particular case).
    Actually the case you mention will be explicit in the standard, not
    implicit. Do you have other examples of implicit requirements?
 
If I think of any I'll let you know.

    >		   There are two principal reasons why this language permits
    >	      a  situation  to  have  an  undefined  consequence rather than
    >	      requiring an error to be signalled:
    > 
    >	       ...
    > 
    >	       -  The situation can be implemented as an extension.
    >
    >If this is the case, then what is the difference between "CONSEQUENCES
    >ARE UNDEFINED" and "IMPLEMENTATIONS MAY BE EXTENDED"?
    The definitions of these two phrases are different, one just happens to
    indirectly refer to the other. 
 
Please explain the difference.  Describe a situation where one is true
yet the other isn't.

    >	   -  THE "CONSEQUENCES ARE UNSPECIFIED"
    > 
    >I also don't care for this particular term.  "Unspecified" and
    >"undefined" are too similar in meaning.  How about "consequences are
    >undefined but benign"?
    Instead of "CONSEQUENCES ARE UNSPECIFIED"?
 
Yes.

    >		   The  standard  may  disallow  certain  extensions   while
    >	      allowing others.
    > 
    >		   For example, "no `implementation is free  to  extend  the
    >	      syntax' of DEFCLASS."
    > 
    >I maintain that any such prohibition is meaningless, or at least
    >unenforceable.  How does this differ from "the consequences are
    >undefined if DEFCLASS is invoked with syntax other than that specified
    >in the standard"?  In both cases, it means that a portable program may
    >not depend on the behavior.  What business do we have constraining how
    >an implementation deals with nonportable programs?
 
    >If you want to constrain implementations, it should be done with a
    >requirement rather than a prohibition.  For instance, "an 'error is
    >signalled' if DEFCLASS is invoked with syntax not conforming to this
    >specification".  This prevents syntax extensions because it would break
    >a portable program that relies on the error being signalled.
    I agree, but would like to hear from the CLOSers about why a prohibition
    rather than a requirement was used in this case.

My recollection about this whole issue was that the CLOSers were going
to change this stuff to refer to what an implementation is permitted to
DOCUMENT about its behavior, e.g. "no implementation is free to extend
the syntax of DEFCLASS and document that extension as a feature of the
implementation."
 
    >	   -  A "WARNING IS ISSUED"
    > 
    >		   means that
    > 
    >	       -  If  this  situation  occurs,  a  warning  is  issued,   as
    >		  described in WARN, in both safe and unsafe situations.
    > 
    >	       -  Valid programs may rely on the fact that a warning will be
    >		  issued in both safe and unsafe situations.
    > 
    >	       -  Every implementation is required to detect this  situation
    >		  in both safe and unsafe situations.
    > 
    >		   For example, "a `warning is issued' by the compiler if  a
    >	      declaration specifier is not one of those defined in Chapter 9
    >	      of  CLtL  and  has  not  been  declared   in   a   DECLARATION
    >	      declaration."
    > 
    >This doesn't say what the results are in such situations.
    Which results? which situation?

The results of a form whose evaluation/compilation results in a warning,
e.g.

(defun foo (a)
  (declare (frobnitz a))
  a)

This will result in a compiler warning because of the unrecognized
declaration.  Is the return value well defined?

    > 
    >	   -  A "WARNING SHOULD BE ISSUED"
    > 
    >		   means that
    > 
    >	       -  If this situation occurs, a  warning  will  be  issued  at
    >		  least in safe situations.
    > 
    >	       -  Valid programs may not rely on the  fact  that  a  warning
    >		  will be issued.
    > 
    >	       -  Every  implementation  is  required  to  detect   such   a
    >		  situation at least in safe situations.
    > 
    > 
    >		   For example, "a warning `should be issued' by a  compiler
    >	      if a variable declared to be ignored is ever referred to or is
    >	      also declared special, or if  a  variable  is  lexical,  never
    >	      referred  to, and not declared to be ignored." (see Chapter 9,
    >	      CLtL)
    > 
    >Both "warning" examples only mention warnings issued by the compiler.
    >In that case, what is the distinction between safe and unsafe
    >situations?  The definitions of "safe" and "unsafe" specify "when code
    >is run"; is there any situation in which a warning is/should be issued
    >at run time?.  At compile time the only code that is run is the compiler
    >itself (which I would assume is generally compiled with the lowest
    >safety level before being shipped to customers) and any macros used in
    >the program (and any implementation-supplied macros will also probably
    >be compiled with lowest safety, and there is no way for portable,
    >user-written macros to access the safety level), but I don't think this
    >section is referring to either of them.
    Currently in CLtL the only time warnings are mentioned is in conjunction
    with the compiler (did I miss something?). However, is there a problem 
    with generalizing warnings?

If warnings are only issued by the compiler, then what does the
reference to safe vs unsafe situations mean?

                                                barmar

∂03-Oct-88  1125	CL-Editorial-mailer 	    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Oct 88  11:25:06 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA01582; Mon, 3 Oct 88 11:22:53 PDT
Message-Id: <8810031822.AA01582@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Oct 88 13:57
To: barmar@think.com, cl-editorial@sail.stanford.edu,
        DJAHANDARI%TOWNS.DEC@decwrl.dec.com, POPA%TOWNS.DEC@decwrl.dec.com
Subject: 

 
    >		   There are two principal reasons why this language permits
    >	      a  situation  to  have  an  undefined  consequence rather than
    >	      requiring an error to be signalled:
    > 
    >	       ...
    > 
    >	       -  The situation can be implemented as an extension.
    >
    >If this is the case, then what is the difference between "CONSEQUENCES
    >ARE UNDEFINED" and "IMPLEMENTATIONS MAY BE EXTENDED"?
    The definitions of these two phrases are different, one just happens to
    indirectly refer to the other. 
 
>Please explain the difference.  Describe a situation where one is true
>yet the other isn't.
The way I see it is that one general situation provides examples of both
cases: it is generally true in CL that the consequences are undefined 
if "incorrect" arguments are supplied during a function call. Sometimes
an implementor may wish to extend the implementation so that a wider range
of arguments is accepted than is specified. In other cases that doesn't make
any sense or isn't possible. 
 
    >	   -  THE "CONSEQUENCES ARE UNSPECIFIED"
    > 
    >I also don't care for this particular term.  "Unspecified" and
    >"undefined" are too similar in meaning.  How about "consequences are
    >undefined but benign"?
    Instead of "CONSEQUENCES ARE UNSPECIFIED"?
 
>Yes.
Isn't that basically the way "consequences are unspecified" is defined
in the text that follows it? You want fewer words to have to remember
the meanings of, right? But, as KMP pointed out, the words "benign" 
and "harmless" mean different things to different programs. Therefore
changing the wording in this case to be exact would require the
following phrase each time the "consequences are unspecified":
"consequences are undefined but, by themselves, won't cause abnormal
termination" or something like that.
Would that be better?

    >		   The  standard  may  disallow  certain  extensions   while
    >	      allowing others.
    > 
    >		   For example, "no `implementation is free  to  extend  the
    >	      syntax' of DEFCLASS."
    > 
    >I maintain that any such prohibition is meaningless, or at least
    >unenforceable.  How does this differ from "the consequences are
    >undefined if DEFCLASS is invoked with syntax other than that specified
    >in the standard"?  In both cases, it means that a portable program may
    >not depend on the behavior.  What business do we have constraining how
    >an implementation deals with nonportable programs?
 
    >If you want to constrain implementations, it should be done with a
    >requirement rather than a prohibition.  For instance, "an 'error is
    >signalled' if DEFCLASS is invoked with syntax not conforming to this
    >specification".  This prevents syntax extensions because it would break
    >a portable program that relies on the error being signalled.
    I agree, but would like to hear from the CLOSers about why a prohibition
    rather than a requirement was used in this case.
 
>My recollection about this whole issue was that the CLOSers were going
>to change this stuff to refer to what an implementation is permitted to
>DOCUMENT about its behavior, e.g. "no implementation is free to extend
>the syntax of DEFCLASS and document that extension as a feature of the
>implementation."
That's still a prohibition. How should it be reworded into a requirement?

 
    >	   -  A "WARNING IS ISSUED"
    > 
    >		   means that
    > 
    >	       -  If  this  situation  occurs,  a  warning  is  issued,   as
    >		  described in WARN, in both safe and unsafe situations.
    > 
    >	       -  Valid programs may rely on the fact that a warning will be
    >		  issued in both safe and unsafe situations.
    > 
    >	       -  Every implementation is required to detect this  situation
    >		  in both safe and unsafe situations.
    > 
    >		   For example, "a `warning is issued' by the compiler if  a
    >	      declaration specifier is not one of those defined in Chapter 9
    >	      of  CLtL  and  has  not  been  declared   in   a   DECLARATION
    >	      declaration."
    > 
    >This doesn't say what the results are in such situations.
    Which results? which situation?
 
>The results of a form whose evaluation/compilation results in a warning,
>e.g.
> 
>(defun foo (a)
>  (declare (frobnitz a))
>  a)
> 
>This will result in a compiler warning because of the unrecognized
>declaration.  Is the return value well defined?
What would be the return value if no warning were issued? The presence
or absence of a warning should have no effect on the result, and that
should be stated here. Right?
 
    > 
    >	   -  A "WARNING SHOULD BE ISSUED"
    > 
    >		   means that
    > 
    >	       -  If this situation occurs, a  warning  will  be  issued  at
    >		  least in safe situations.
    > 
    >	       -  Valid programs may not rely on the  fact  that  a  warning
    >		  will be issued.
    > 
    >	       -  Every  implementation  is  required  to  detect   such   a
    >		  situation at least in safe situations.
    > 
    > 
    >		   For example, "a warning `should be issued' by a  compiler
    >	      if a variable declared to be ignored is ever referred to or is
    >	      also declared special, or if  a  variable  is  lexical,  never
    >	      referred  to, and not declared to be ignored." (see Chapter 9,
    >	      CLtL)
    > 
    >Both "warning" examples only mention warnings issued by the compiler.
    >In that case, what is the distinction between safe and unsafe
    >situations?  The definitions of "safe" and "unsafe" specify "when code
    >is run"; is there any situation in which a warning is/should be issued
    >at run time?.  At compile time the only code that is run is the compiler
    >itself (which I would assume is generally compiled with the lowest
    >safety level before being shipped to customers) and any macros used in
    >the program (and any implementation-supplied macros will also probably
    >be compiled with lowest safety, and there is no way for portable,
    >user-written macros to access the safety level), but I don't think this
    >section is referring to either of them.
    Currently in CLtL the only time warnings are mentioned is in conjunction
    with the compiler (did I miss something?). However, is there a problem 
    with generalizing warnings?
 
>If warnings are only issued by the compiler, then what does the
>reference to safe vs unsafe situations mean?
It's not necessarily true forever that warnings are only issued by the
compiler, only for now, in the stage we're in now. If we find, when the
standard is complete, that warnings are only issued by the compiler, then
we'll take the safe/unsafe business out. Right?

kc

∂03-Oct-88  1233	CL-Editorial-mailer 	October agenda
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Oct 88  12:33:12 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA05665; Mon, 3 Oct 88 12:31:38 PDT
Message-Id: <8810031931.AA05665@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Oct 88 14:58
To: @[chapman]editors@decwrl.dec.com
Subject: October agenda




                           Agenda - October Meeting
                             Editorial Committee
                              Fairfax, Virginia

           Following are the proposed  agenda  items  for  the  Virginia
      meeting.   Please feel free to request the addition or deletion of
      items (except lunch).  Speaking  of  lunch,  since  the  editorial
      meeting  begins  as  soon  as  the clean-up meeting completes, Bob
      Mathis has seen to it that we don't starve.  There  will  be  food
      available  close to where we'll be meeting so we can work while we
      eat.

           Agenda:

      1.  Error Terminology plus lunch (15 minutes)

      2.  Conformance (15 minutes)

      3.  Extensions (15 minutes)

      4.  Language subsetting (15 minutes)

      5.  General comments about the review so far (30 minutes)

               We    must    consider    a    new    name    for     the
          Environment/Evaluation section, and a term to replace "tool".

      6.  Break into groups to examine the document (1.5 hours)

               This will involve deciding if there is enough explanatory
          material  in  the  chapter  you  are  reviewing  to  make  the
          specification clear.

           -  Group 1:  Chapters 1 and 3 - Intro and reader

           -  Group 2:  Chapter 2 - Types

           -  Group 3:  Chapter 4 - Evaluation

           -  Group  4:   Chapter  5  -  Errors,  IO,  and   generalized
              reference


      7.  Reconvene and collect comments (1 hour)

∂03-Oct-88  1255	CL-Editorial-mailer 	error definitions  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Oct 88  12:55:18 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 3 Oct 88 15:18:04 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 3 Oct 88 15:49:34 EDT
Date: Mon, 3 Oct 88 15:49 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: error definitions
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, DJAHANDARI%TOWNS.DEC@decwrl.dec.com,
        POPA%TOWNS.DEC@decwrl.dec.com
In-Reply-To: <8810031822.AA01582@decwrl.dec.com>
Message-Id: <19881003194959.0.BARMAR@OCCAM.THINK.COM>

    Date: 3 Oct 88 13:57
    From: chapman%aitg.DEC@decwrl.dec.com

	>If this is the case, then what is the difference between "CONSEQUENCES
	>ARE UNDEFINED" and "IMPLEMENTATIONS MAY BE EXTENDED"?
	The definitions of these two phrases are different, one just happens to
	indirectly refer to the other. 
 
    >Please explain the difference.  Describe a situation where one is true
    >yet the other isn't.
    The way I see it is that one general situation provides examples of both
    cases: it is generally true in CL that the consequences are undefined 
    if "incorrect" arguments are supplied during a function call. Sometimes
    an implementor may wish to extend the implementation so that a wider range
    of arguments is accepted than is specified. In other cases that doesn't make
    any sense or isn't possible. 
 
You're talking about the implementor here.  What is the difference IN
THE STANDARD?  Why would the standard say "undefined" in one place and
"may be extended" in another.  To the implementor, both mean "you can do
what you want"; to the user, both mean "you can't do this in portable
code."

	>	   -  THE "CONSEQUENCES ARE UNSPECIFIED"
	> 
	>I also don't care for this particular term.  "Unspecified" and
	>"undefined" are too similar in meaning.  How about "consequences are
	>undefined but benign"?
	Instead of "CONSEQUENCES ARE UNSPECIFIED"?
 
    >Yes.
    Isn't that basically the way "consequences are unspecified" is defined
    in the text that follows it? You want fewer words to have to remember
    the meanings of, right? But, as KMP pointed out, the words "benign" 
    and "harmless" mean different things to different programs. Therefore
    changing the wording in this case to be exact would require the
    following phrase each time the "consequences are unspecified":
    "consequences are undefined but, by themselves, won't cause abnormal
    termination" or something like that.
    Would that be better?

All I'm asking is that we not use synonyms this way.  If you can come up
with a better phrase than mine, by all means use it.  But "undefined"
and "unspecified" mean the same thing to me, and if I were an
implementor I wouldn't want to have to remember which one is which.

	>		   The  standard  may  disallow  certain  extensions   while
	>	      allowing others.
	> 
	>		   For example, "no `implementation is free  to  extend  the
	>	      syntax' of DEFCLASS."
	> 
	>I maintain that any such prohibition is meaningless, or at least
	>unenforceable.  How does this differ from "the consequences are
	>undefined if DEFCLASS is invoked with syntax other than that specified
	>in the standard"?  In both cases, it means that a portable program may
	>not depend on the behavior.  What business do we have constraining how
	>an implementation deals with nonportable programs?
 
	>If you want to constrain implementations, it should be done with a
	>requirement rather than a prohibition.  For instance, "an 'error is
	>signalled' if DEFCLASS is invoked with syntax not conforming to this
	>specification".  This prevents syntax extensions because it would break
	>a portable program that relies on the error being signalled.
	I agree, but would like to hear from the CLOSers about why a prohibition
	rather than a requirement was used in this case.
 
    >My recollection about this whole issue was that the CLOSers were going
    >to change this stuff to refer to what an implementation is permitted to
    >DOCUMENT about its behavior, e.g. "no implementation is free to extend
    >the syntax of DEFCLASS and document that extension as a feature of the
    >implementation."
    That's still a prohibition. How should it be reworded into a requirement?

In this case, a prohibition works, because it is talking about something
concrete.  You can't prohibit an implementation from defining the
behavior of some construct, because there's no such thing as undefined
behavior in an implementation (it's empirically defined to do whatever
it does when the situation occurs).  You can, however, prohibit the
implementor from publicizing the behavior.  I don't happen to like this,
but at least it makes sense.

We may, however, have to be even more careful in our wording of this
issue.  For example, if an implementation documents that an error will
be signalled if the :FOOBAR keyword is given to DEFCLASS, is that an
extension?  It defines the behavior in a situation not specifically
mentioned in the standard, right?  I imagine we would like to allow this
form of extension, but disallow some others.
 
    >This will result in a compiler warning because of the unrecognized
    >declaration.  Is the return value well defined?
    What would be the return value if no warning were issued? The presence
    or absence of a warning should have no effect on the result, and that
    should be stated here. Right?
 
All I'm asking for is that the standard specifically state that the
warning will have no effect on the actual operation.

    >If warnings are only issued by the compiler, then what does the
    >reference to safe vs unsafe situations mean?
    It's not necessarily true forever that warnings are only issued by the
    compiler, only for now, in the stage we're in now. If we find, when the
    standard is complete, that warnings are only issued by the compiler, then
    we'll take the safe/unsafe business out. Right?

Since the safe/unsafe business doesn't make sense for compiler warnings,
we should decide that all compiler warnings will be "A WARNING WILL BE
ISSUED" rather than "SHOULD BE", since "SHOULD BE" has no meaning for
compiler warnings.  Then your above statement becomes "if we find that
'WARNING SHOULD BE' is never used, then we can take it out."

                                                barmar

∂03-Oct-88  1406	CL-Editorial-mailer 	Error Terminology  
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I'm not following the debate on this, but I see the question raised
about what these two phrases mean:

1. ``consequences are undefined''
2. ``implementations may be extended''

To implementors these say:

	1. you can do whatever you want, but don't waste effort
	   on doing something useful because it will be ignored.

	2. you can do whatever you want, and something useful would be nice.

To users these say:

	1. never use this.

	2. read your vendor's manual to find out about useful behavior,
    	   but don't use this in portable code.

I think these are different in both cases, so both terminologies are
needed.  Why do I think that implementors should be told not to extend
something? Because we have moved into the era when language designers know
more about language design than implementors, at least in some cases.
I think some of the cleanup mail I've seen recently proves it.

			-rpg-

∂03-Oct-88  1429	CL-Editorial-mailer 	Error Terminology  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Oct 88  14:29:12 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 3 Oct 88 16:54:02 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 3 Oct 88 17:26:07 EDT
Date: Mon, 3 Oct 88 17:26 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Error Terminology  
To: Dick Gabriel <RPG@sail.stanford.edu>
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <OlxIJ@SAIL.Stanford.EDU>
Message-Id: <19881003212644.4.BARMAR@OCCAM.THINK.COM>

    Date: 03 Oct 88  1406 PDT
    From: Dick Gabriel <RPG@sail.stanford.edu>


    I'm not following the debate on this, but I see the question raised
    about what these two phrases mean:

    1. ``consequences are undefined''
    2. ``implementations may be extended''

    To implementors these say:

	    1. you can do whatever you want, but don't waste effort
	       on doing something useful because it will be ignored.

	    2. you can do whatever you want, and something useful would be nice.

    To users these say:

	    1. never use this.

	    2. read your vendor's manual to find out about useful behavior,
	       but don't use this in portable code.

    I think these are different in both cases, so both terminologies are
    needed.  Why do I think that implementors should be told not to extend
    something? Because we have moved into the era when language designers know
    more about language design than implementors, at least in some cases.
    I think some of the cleanup mail I've seen recently proves it.

			    -rpg-

If that is what is meant, then the descriptions should be a little more
explicit in this regard.  For example, the description of "may be
extended" should say that implementors are encouraged to experiment with
this situation.

Actually, I don't think these things belong in the main body of the
standard.  Standards generally have annexes for things like rationales
and implementation suggestions.  Suggestions regarding extensions also
belong there, because they don't affect the official, portable language
that is being defined in the body of the standard.  I believe the C
standard has an annex describing common extensions and another one
suggesting possible extensions.  These extensions are likely to become
part of the next version of the standard, and these annexes encourage
experimentation with the features so that there will be enough
experience to codify the practice in a couple of years.

                                                barmar

∂04-Oct-88  0951	CL-Editorial-mailer 	barmar questions about error terms
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 4 Oct 88  09:51:29 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA02128; Tue, 4 Oct 88 09:49:51 PDT
Message-Id: <8810041649.AA02128@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 4 Oct 88 11:42
To: @[chapman]editors@decwrl.dec.com
Subject: barmar questions about error terms

1. CONSEQUENCES ARE UNDEFINED vs IMPLEMENTATIONS MAY BE EXTENDED

RPG's clarifications will be included in the descriptions of these two
categories, the categories will remain distinct. In regard to your comment
that these things don't belong in the standard, you're right that the
actual information about possible extensions doesn't belong in the standard.
But what does belong there are words that cover each situation. If a
situation isn't explicitly addressed, the standard is incomplete.
Do you agree?

2. CONSEQUENCES ARE UNSPECIFIED

How about CONSEQUENCES ARE UNDEFINED BUT NONTERMINAL? 

3. IMPLEMENTATIONS ARE FREE TO EXTEND THE SYNTAX

We should find out from the CLOSers what the final word in the case
of the DEFCLASS prohibition was. Additionally we need to locate any
other prohibitions in the standard and reword them (carefully) accordingly.
Agreed?

4. WARNING IS ISSUED

New item in the description states that the warning has no effect on
the operation.

5. WARNING SHOULD BE ISSUED

Right, if warnings only apply to the compiler, according to this definition,
this category will go away. However, I believe CLtL must have another
definition for warnings since the two ways to get a warning (IS ISSUED,
SHOULD BE ISSUED) are both present in CLtL.
Any historical information?

kc

∂04-Oct-88  1101	CL-Editorial-mailer 	Error Terminology  
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I read:

``We should find out from the CLOSers what the final word in the case
of the DEFCLASS prohibition was. Additionally we need to locate any
other prohibitions in the standard and reword them (carefully) accordingly.''

The main point with DEFCLASS is that we wanted it to be the case that
everyone who dealt with DEFCLASS including codewalkers knew exactly what
the portable syntax was. Also, because every underlying mechanism to build
DEFCLASS and like things is exposed and available to users, there is no
need to allow extensions.

On ``...is undefined'':

Requiring an error or warning to be signaled and prohibiting an extension
are not equivalent, because it might be implementationally expensive to
detect such situations. Hence, the need for prohibitions. 

I might point out that the CLOS committee didn't come up with this
terminology as a joke or in a fit of stupidity. Nor did we accidentally
forget the CLtL terminology. We designed it deliberately and in full
knowledge that it differed from CLtL terminology. Furthermore, we used
that terminology very carefully in the CLOS document.

			-rpg-

∂04-Oct-88  2041	X3J13-mailer 	Re: error definitions
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Oct 88  20:41:24 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 88 19:59:52 PDT
Date: Tue, 4 Oct 88 19:59 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: error definitions
To: Barry Margolin <barmar@Think.COM>, Dick Gabriel
 <RPG@SAIL.Stanford.EDU>, chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@SAIL.Stanford.EDU, x3j13@sail.stanford.edu,
 DJAHANDARI%TOWNS.DEC@decwrl.dec.com, POPA%TOWNS.DEC@decwrl.dec.com
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <19881003194959.0.BARMAR@OCCAM.THINK.COM>,
              <OlxIJ@SAIL.Stanford.EDU>,
              <19881003212644.4.BARMAR@OCCAM.THINK.COM>,
              <8810031951.AA06841@decwrl.dec.com>,
              <km9wo@SAIL.Stanford.EDU>
Message-ID: <19881005025941.6.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: 04 Oct 88 11:01 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    I might point out that the CLOS committee didn't come up with this
    terminology as a joke or in a fit of stupidity. Nor did we accidentally
    forget the CLtL terminology. We designed it deliberately and in full
    knowledge that it differed from CLtL terminology. Furthermore, we used
    that terminology very carefully in the CLOS document.

Right, and more detail about this to follow.

    Date: 03 Oct 88 14:06 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    I'm not following the debate on this, but I see the question raised
    about what these two phrases mean:

    1. ``consequences are undefined''
    2. ``implementations may be extended''

This terminology was introduced after a great deal of thought about how
to prevent the so called "number of arguments to IF" bug.  We believe
that we have restricted the syntactic extensions that can be made to
CLOS, and that that restriction is important for a variety of reasons.

CLOS is a language which provides a great deal of extensibility, and
given that it is a very important concept to be able to restrict that
in places where it is appropriate.


	   -  THE "CONSEQUENCES ARE UNSPECIFIED"

I am not up to speed on this issue, and I am tired, but I believe it is
important that "THE CONSEQUENCES ARE UNSPECIFIED" must not include
"IMPLEMENTATIONS MAY BE EXTENDED" in any way.
-------

∂05-Oct-88  0021	CL-Editorial-mailer 	Re: Error Terminology   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88  00:20:20 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 OCT 88 00:16:16 PDT
Date: 5 Oct 88 00:16 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Error Terminology  
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 04 Oct 88
 11:01 PDT
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: cl-editorial@SAIL.Stanford.EDU
Message-ID: <881005-001616-4504@Xerox>

I think the CL standard actually needs the rather painful work of going
through the standard, finding all of the places that currently say "is an
error" or "signals an error" or "must", and recasting them in the new error
terminology:

I don't know who would volunteer for such a job, since it is difficult and
at risk of being political.


∂14-Oct-88  1149	CL-Editorial-mailer 	proposal for specification of standard features  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Oct 88  11:49:09 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA26080; Fri, 14 Oct 88 12:49:00 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA20446; Fri, 14 Oct 88 12:48:57 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810141848.AA20446@defun.utah.edu>
Date: Fri, 14 Oct 88 12:48:56 MDT
Subject: proposal for specification of standard features
To: cl-editorial@sail.stanford.edu

This message proposes a mechanism for dealing with two related
problems that have been cropping up from time to time:

(1) What to do with functionality that is described in CLtL but that
    some people would now like to remove from the standard language,
    while still allowing implementations to provide that functionality
    as an extension.  (For example, the cleanup issue TEST-NOT-IF-NOT.)

(2) New functionality not described in CLtL that we would like to
    standardize, but that some people would not like to make a required
    part of the language.  (For example, the fancy LOOP macro.)

I'm not really sure if the editorial committee is the right place to send
this, but given that we don't have conformance or subsetting committees
I don't know where else would be more appropriate.

What I'm suggesting is that the language include the concept of
"standard features".  The general idea is that the functionality would
be described in the standard but that implementations would not be
required to support it.  We would assign each feature a standard name
for *FEATURES* so that user programs can identify whether or not the
feature is present in a particular implementation.

A proposal to make something a standard feature should include at least
the following kinds of information:

Feature Name:
	[ A keyword suitable for *FEATURES*.]

Description:
	[ A brief narrative description of the functionality included
		in this feature; it shouldn't need to be more than one
		or two sentences.]

Category:
	[ Either CHANGE, for purpose (1) above, or ADDITION, for
		purpose (2).]

Motivation:
	[ Why should this functionality be optional instead of a required
		part of the language?  Typical reasons would include that
		the feature is now considered obsolete but might be
		provided for compatibility with existing code, or that
		the feature is "large" and might not be used at all by
		many programs.]

Functions/Macros/Variables/Types/etc included:
	[ List all functions that are not present at all if the feature
		is not supported by a particular implementation.]

Functions/Macros/Variables/Types/etc modified:
	[ List all functions that behave differently if the feature is not
		supported by a particular implementation, than when the
		feature is supported.  Be specific about what the
		differences are.]

Packages and Symbols:
	[ Does this feature reside in its own package?  What are all of
		the external symbols used by this feature?]


This last section on packages is kind of sticky.  I suspect that most
CHANGEs would want to continue to reside in the LISP package, which
raises the issue of whether the symbols they use should still appear
as external symbols even when the feature is not present.  Most
ADDITIONs would probably live in their own packages.

It might also be a good idea to try to lay down some general rules
about functions whose behavior is modified by a feature.  For example,
it's important the features that extend existing functions should
guarantee that those extensions are compatible -- any program that's
valid if the feature isn't present should continue to be valid if the
feature is present.  I think it is also a good idea to encourage
"signalling an error" when a feature isn't present instead of just
saying "is an error", particularly when uses of the unsupported
feature are easy to detect.  For example, if the fancy LOOP macro is
adopted as an optional feature, it would be reasonable to require
implementations that don't support it to signal an error if they see
atomic forms in the body of a loop.  For simplicity, we could probably
define a single unsupported-feature error to be used for all
situations instead of each feature defining its own peculiar kind of
errors.

I'd be interested in getting some feedback on this idea.  Not having
seen the draft of the document yet, I have no idea how standard
features would fit in to its overall organization.  Is there anything
else that would have to be included in the writeup format?

Note that I'm not on the cl-editorial mailing list, so please make sure
that further discussion on this is cc'ed to me explicitly.

-Sandra
-------

∂18-Oct-88  0922	CL-Editorial-mailer 	next meeting  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  09:21:54 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA03654; Tue, 18 Oct 88 09:21:45 PDT
Message-Id: <8810181621.AA03654@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 18 Oct 88 12:17
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: next meeting

I'm thinking of requesting a vote of confidence at the next meeting. To do this
I have to get the phase 1 document to the X3J13 committee by Dec. 17 (or
thereabouts). 

What do you think?

kc

∂18-Oct-88  1229	CL-Editorial-mailer 	editorial committee meeting notes 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  12:28:58 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA05255; Tue, 19 Apr 88 20:24:19 PDT
Message-Id: <8804200324.AA05255@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 18 Oct 88 15:25
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu,
        POPA%TOWNS.DEC@decwrl.dec.com, DJAHANDARI%TOWNS.DEC@decwrl.dec.com
Subject: editorial committee meeting notes




                         Editorial Committee Meeting
                     October 10, 1988, Fairfax, Virginia

           Attendees:  Jim Allard, Mary Boelke,  Skona  Brittain,  Kathy
      Chapman,  Dick  Gabriel,  Gregor  Kiczales,  Barry Margolin, Larry
      Masinter, Bob Mathis, Kent Pitman,  Jeff  Rosenking,  Guy  Steele,
      Walter van Roggen

           For  a  short  time  some  compiler  committee  members  were
      present:   Kim Barrett, Steve Havlitch, Sandra Loosemore, and JonL
      White.



      1  SUMMARY OF ACTION ITEMS

           Editor:  correct error  proposal;  include  more  information
      about  conformance  and  extensions  and  send to X3J13 along with
      requests  for  volunteers  to  investigate  subsetting.   Complete
      including  comments  from  section  writers.   Create schedule for
      phase 2 review that includes final reviews by Steele, Gabriel, and
      Moon.

           Section writers:  review my responses to  your  comments  and
      begin  accepting  phase  2  portions  of  the document as they are
      completed by the editor.  Review chapters 1 -  5  for  consistency
      and clarity.

           Larry Masinter:  begin assisting me in incorporating issues.

           New list of section writers:


 Person               Responsibilities

 Jim Allard           Files, Hashtables, Lists, Predicates 

 Mary Boelke          Packages, Symbols 

 Skona Brittain       Control Structure, Sequences 

 Kathy Chapman        Editor (see list of responsibilities below)
                      Chapters 1, 3, 5, 7, 8, Glossary 
                      Make up glossary of error terms, get approved by
                      error, edit, and CLOS committees
                      Create a proposal for handling language subsets

 Bob Kerns            Characters, Strings, Chapter 2

 Gregor Kiczales      CLOS 

 Barry Margolin       Arrays, Evaluator, IO, Structures 

 Larry Masinter       Incorporating clean-up issues

!
                                                                Page 2


 Bob Mathis           Numbers 

 Jeff Piazza          Declarations 

 Kent Pitman          Chapter 2, Errors, Miscellaneous, Types 

 Jonathan Rees        Chapter 4

 Jeff Rosenking       Macros, Streams 

 Walter van Roggen    Program Structure 





      2  SUMMARY OF MEETING

      New order and header definitions for  the  tools  descriptions  in
      Chapter 6 were proposed and accepted:

          Syntax

          Method Signatures

          Arguments -- a list of the arguments required by the function,
          macro,  or  special  form,  and  the  required aspects of each
          argument.

          Values -- a list of the  values  returned  by  each  function,
          macro,  or  special  form,  and  the  required aspects of each
          value.

          Description  --  contains  a  combination   of   the   current
          `Description' and `Environment/Evaluation' sections.

          Examples -- although they must  be  correct,  examples  aren't
          part of the requirements portion of the standard.

          Side Effects

          Affected By

          Conditions

          Notes   --   contains   no   requirements,   only   peripheral
          information.

          See Also -- contains references  only  to  items  that  aren't
          referred to elsewhere.

      A glossary of terms will be composed to be used  to  simplify  the
      process  of  describing  the  arguments  and  values.   Also, when
      feasible, Lisp should be used.  For example:
!
                                                                Page 3


           make-array dimensions ...

           Dimensions -- (or (integer 0 *) list)

           The  error  terminology  paper  was  discussed  and  specific
      suggestions   for   improvement  were  made.   It  is  clear  that
      conformance  and  extensions  can't   be   divorced   from   error
      terminology,  so  those  topics will appear somewhere in detail in
      the revised version of the paper that I will write.  I  will  also
      include  proposed translations from CLtL to the new terminology so
      that reviewers can begin to  understand  the  impact  of  changing
      things.

           The  X3J13  committee  needs  to  decide  what  to  do  about
      deprecation.   Research in this area needs to be done.  Volunteers
      will be requested, but if there are none, I will summarize what  I
      can learn about what other languages have done in this area.

           The X3J13 committee needs to decide what to do about language
      subsets.  Research in this area needs to be done.  Volunteers will
      be requested, but  if  there  are  none,  I  will  summarize  what
      research has been done in this area.

           Gregor  has  agreed  to  work  with  me  to  add   the   CLOS
      specification to the standard.

∂18-Oct-88  1436	CL-Editorial-mailer 	subsetting/features
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 18 Oct 88  14:35:50 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA10826; Tue, 19 Apr 88 22:31:16 PDT
Message-Id: <8804200531.AA10826@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 18 Oct 88 16:47
To: cl-editorial@sail.stanford.edu, sandra@cs.utah.edu
Subject: subsetting/features

Sandra,

I am in the process of trying to locate precedents in other languages 
that pertain to your proposal. I will summarize comments when I have
received them all.
So far the comments have been in the vain of discouraging subsetting.

kc

∂18-Oct-88  1539	CL-Editorial-mailer 	Re: proposal for specification of standard features   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Oct 88  15:39:26 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 18 OCT 88 14:28:51 PDT
Date: 18 Oct 88 14:18 PDT
From: masinter.pa@Xerox.COM
Subject: Re: proposal for specification of standard features
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Fri, 14 Oct 88 12:48:56 MDT
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: cl-editorial@sail.stanford.edu
Message-ID: <881018-142851-5100@Xerox>

I like the idea of separating out features that are OBSOLETE and also of
providing a section in the standard for FUTURE ADDITIONS -- things that
we're not ready to add to the standard but for which experimentation is
encouraged.

I think we'll make more progress on the mechanism once we have a shared
idea of what falls into each category. 
 
For example, I don't like the idea so much of making *FEATURES* the primary
mechanism for determining which are present and which are not in a given
implementation.  *FEATURES* are good for things that are necessarily
different from one implementation to the next, where programmers must find
themselves writting #+ieee-floating-point or #-symbolics. This seems less
useful a way of describing obsolete features, etc.α∂

I'm not even sure we have to dictate the mechanism by which implementations
identify whether they are CLtL Common Lisp or ANSI Common Lisp or ANSI
Common Lisp Without Obsolete Definitions. Do we?





∂18-Oct-88  1611	CL-Editorial-mailer 	Re: proposal for specification of standard features   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 Oct 88  16:11:11 PDT
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.0-cs)
	id AA23010; Tue, 18 Oct 88 17:11:03 MDT
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA23162; Tue, 18 Oct 88 17:11:00 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810182311.AA23162@defun.utah.edu>
Date: Tue, 18 Oct 88 17:10:58 MDT
Subject: Re: proposal for specification of standard features
To: masinter.pa@Xerox.COM
Cc: sandra%defun@cs (Sandra J Loosemore), cl-editorial@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 18 Oct 88 14:18 PDT

I agree that *features* isn't really the best mechanism for handling
this; I don't imagine that programmers would find it very useful to do
things like #+loop-macro, for instance.  It's the best I could come up
with on short notice, though; maybe somebody else can think of a better
mechanism.  That's really the reason why I brought this up now -- to get
people to think about it more seriously, instead of just hand-waving
about how we might make certain things optional "later on".

Also, I should point out that there are a number of issues (some
cleanup proposals as well as the iteration proposals) now pending that
I would vote differently on if we had a mechanism like this in place.

-Sandra
-------

∂28-Oct-88  0346	CL-Editorial-mailer 	mailing list update
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 28 Oct 88  03:46:46 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA22919; Fri, 28 Oct 88 03:46:27 PDT
Message-Id: <8810281046.AA22919@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 28 Oct 88 06:43
To: cl-editorial@sail.stanford.edu
Subject: mailing list update

Please remove Ron Ohlander from cl-editorial.

∂28-Oct-88  1613	CL-Editorial-mailer 	A Note on Examples For Standard   
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 27 Oct 88  07:02:25 PDT
Date: 27 Oct 1988 10:01-EDT
Sender: ROSENKING@A.ISI.EDU
Subject: A Note on Examples For Standard
From: ROSENKING@A.ISI.EDU
To: cl-editorial@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]27-Oct-88 10:01:17.ROSENKING>


I just thought I'd pass on a note of good advice which Dave Moon gave to me
after I suggested a modification to an example in the draft standard:


We need to be careful of putting examples in documentation that
imply that the language specification is more restrictive than
it was intended to be.

∂07-Nov-88  1742	CL-Editorial-mailer 	"arguments to a @i(form)"    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Nov 88  17:41:47 PST
Return-Path: <@occam.think.com:barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 7 Nov 88 15:19:31 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 7 Nov 88 15:38:12 EST
Date: Mon, 7 Nov 88 15:39 EST
From: Barry Margolin <barmar@Think.COM>
Subject: "arguments to a @i(form)"
To: cl-editorial@sail.stanford.edu
Message-Id: <19881107203905.4.BARMAR@OCCAM.THINK.COM>

The phrase "arguments to a @i(form)" appears frequently in the draft
standard, but I don't really like it.  Forms don't get arguments,
functions do.  A form that is a function call has subforms that are
evaluated to produce arguments for the function.  I believe that the
above phrase should generally be "arguments to a @i(function)".

Kathy, is there some reason the current terminology was used?
Currently, the Definitions section of the standard is nearly empty, so
perhaps you intended some other definition of "form" than the one
commonly used in the Lisp community?

Comments?

                                                barmar

∂20-Nov-88  0416	CL-Editorial-mailer 	conformance, subsetting...   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Nov 88  04:16:47 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for sandra%defun@cs.utah.edu; id AA25413; Sun, 20 Nov 88 03:49:52 PST
Message-Id: <8811201149.AA25413@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Nov 88 06:46
To: cl-editorial@sail.stanford.edu, sandra%defun@cs.utah.edu
Subject: conformance, subsetting...




        Conformance, Subsetting, Deprecation, and Language Extensions
                                Kathy Chapman



      1  CONFORMANCE REQUIREMENTS

           Two ways of define conformance are in terms of  a  conforming
      program   and   a   conforming   implementation.   Pascal  defines
      conformance in terms of both, PL/I defines conformance in terms of
      conforming  programs  only.  Fortran and Ada say that a conforming
      implementation correctly processes conforming programs.  Ada  goes
      on to say other specific things about a conforming implementation,
      Fortran does not at this  time  but  probably  will  in  its  next
      standard.   The  ISO  conformance guidelines, and the draft of the
      SPARC proposal discuss both programs and implementations.

           For our standard, I believe we should define  conformance  in
      terms   of   a   conforming   program,   and   perhaps  conforming
      documentation.  Of course,  within  the  standard  itself  certain
      requirements  will  be levied on the implementation.  However, the
      bottom line should not be that the implementation conforms to  the
      letter  of  the standard, but that a program written to the letter
      of the standard  will  run  in  all  "conforming"  implementations
      (defined as ones that run conforming programs).



      2  DEPRECATION

           Fortran successfully deprecated  one  constant.   However,  a
      proposal  submitted  during its latest standardization effort that
      suggested deleting old features in favor of new ones  was  opposed
      vehemently.    The   Pascal  committee  is  currently  opposed  to
      deprecation, and the  SPARC  proposal  suggests  that  deprecation
      should be dictated by the marketplace.

           For our standard, I believe we should confine deprecation  to
      a  small  set of functions that are related to character handling.
      I don't think it's unreasonable for a language the size of Lisp to
      get  rid  of  the never-used tools.  But we don't want to generate
      years of  discussion  over  a  relatively  minor  issue  when  the
      standard goes for public review.



      3  EXTENSIONS

           I couldn't find any information that  pertained  to  language
      extensions as we know them.

           For our standard, it seems that extensions can be covered  in
      the clauses concerning conforming documentation.  Maybe some extra
      statements about what conforming programs do in  the  presence  of
      extensions would be useful, but I see them as rather redundant.
!
                                                                Page 2


      4  SUBSETS

           Pascal has two levels of conforming implementations --  level
      1  contains  level 0 and conformant arrays.  This was a compromise
      necessary to achieve international agreement.  The 1981  PL/I  was
      subsetted  and the results were a range of implementations between
      the subset and the full language; nobody wanted to use the  subset
      so  vendors  were forced to implement the full language eventually
      anyway.  Cobol had multiple levels of subsets.  However, the  only
      two  levels  that  were  important were the minimum subset and the
      full language.  The middle levels  were  seldom  used  other  than
      transient points to the full language.  Fortran was subsetted.  It
      was felt that subsetting encouraged vendors to  implement  Fortran
      and  therefore proliferate its usage, but users were quite annoyed
      that one Fortran was considerably different from another.  The new
      Fortran language standards committee is banning subsetting.  SPARC
      feels that subsets aren't good for facilitating  interchange,  but
      serve  the  purpose  of  allowing  timely  implementation  of  the
      standard.

           A  suggestion  that  was  made  by  most  language  committee
      representatives  was to group subsetted parts meaningfully, and to
      minimize the number of levels.

           For our standard, I believe we should subset only if  there's
      a  chance we could achieve international agreement on the standard
      by doing so.  However,  if  certain  vendors  feel  strongly  that
      subsetting  is  necessary,  it seems that three or four levels are
      called for:  the full language  without  the  environmental  tools
      (ed,  ..),  the  full  language  without  CLOS,  the full language
      without the environmental tools or CLOS, and the full language.  I
      do not personally believe that CLOS can be subsetted out.



      5  INTERSECTING ERROR TERMINOLOGY WITH LANGUAGE CONFORMANCE

           Pascal  breaks  errors   into   3   categories.    Conforming
      implementations  are required to detect, encouraged to detect, ...
      the different categories.

           For our standard, if conformance, subsetting, and  extensions
      are  well-defined,  the  error  terminology  should  be  a natural
      extension,  not  much  different  from  the  terminology  I   have
      previously presented.

∂06-Dec-88  1153	CL-Editorial-mailer 	second request for comments  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Dec 88  11:53:37 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA18733; Tue, 6 Dec 88 11:52:44 PST
Message-Id: <8812061952.AA18733@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Dec 88 14:50
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: second request for comments

I haven't heard from anyone about the following document. I want to send it to
X3J13 within the week so I can proceed on the error terminology.

Thanks for your help.

kc




        Conformance, Subsetting, Deprecation, and Language Extensions
                                Kathy Chapman



      1  CONFORMANCE REQUIREMENTS

           Two ways of define conformance are in terms of  a  conforming
      program   and   a   conforming   implementation.   Pascal  defines
      conformance in terms of both, PL/I defines conformance in terms of
      conforming  programs  only.  Fortran and Ada say that a conforming
      implementation correctly processes conforming programs.  Ada  goes
      on to say other specific things about a conforming implementation,
      Fortran does not at this  time  but  probably  will  in  its  next
      standard.   The  ISO  conformance guidelines, and the draft of the
      SPARC proposal discuss both programs and implementations.

           For our standard, I believe we should define  conformance  in
      terms   of   a   conforming   program,   and   perhaps  conforming
      documentation.  Of course,  within  the  standard  itself  certain
      requirements  will  be levied on the implementation.  However, the
      bottom line should not be that the implementation conforms to  the
      letter  of  the standard, but that a program written to the letter
      of the standard  will  run  in  all  "conforming"  implementations
      (defined as ones that run conforming programs).



      2  DEPRECATION

           Fortran successfully deprecated  one  constant.   However,  a
      proposal  submitted  during its latest standardization effort that
      suggested deleting old features in favor of new ones  was  opposed
      vehemently.    The   Pascal  committee  is  currently  opposed  to
      deprecation, and the  SPARC  proposal  suggests  that  deprecation
      should be dictated by the marketplace.

           For our standard, I believe we should confine deprecation  to
      a  small  set of functions that are related to character handling.
      I don't think it's unreasonable for a language the size of Lisp to
      get  rid  of  the never-used tools.  But we don't want to generate
      years of  discussion  over  a  relatively  minor  issue  when  the
      standard goes for public review.



      3  EXTENSIONS

           I couldn't find any information that  pertained  to  language
      extensions as we know them.

           For our standard, it seems that extensions can be covered  in
      the clauses concerning conforming documentation.  Maybe some extra
      statements about what conforming programs do in  the  presence  of
      extensions would be useful, but I see them as rather redundant.
!
                                                                Page 2


      4  SUBSETS

           Pascal has two levels of conforming implementations --  level
      1  contains  level 0 and conformant arrays.  This was a compromise
      necessary to achieve international agreement.  The 1981  PL/I  was
      subsetted  and the results were a range of implementations between
      the subset and the full language; nobody wanted to use the  subset
      so  vendors  were forced to implement the full language eventually
      anyway.  Cobol had multiple levels of subsets.  However, the  only
      two  levels  that  were  important were the minimum subset and the
      full language.  The middle levels  were  seldom  used  other  than
      transient points to the full language.  Fortran was subsetted.  It
      was felt that subsetting encouraged vendors to  implement  Fortran
      and  therefore proliferate its usage, but users were quite annoyed
      that one Fortran was considerably different from another.  The new
      Fortran language standards committee is banning subsetting.  SPARC
      feels that subsets aren't good for facilitating  interchange,  but
      serve  the  purpose  of  allowing  timely  implementation  of  the
      standard.

           A  suggestion  that  was  made  by  most  language  committee
      representatives  was to group subsetted parts meaningfully, and to
      minimize the number of levels.

           For our standard, I believe we should subset only if  there's
      a  chance we could achieve international agreement on the standard
      by doing so.  However,  if  certain  vendors  feel  strongly  that
      subsetting  is  necessary,  it seems that three or four levels are
      called for:  the full language  without  the  environmental  tools
      (ed,  ..),  the  full  language  without  CLOS,  the full language
      without the environmental tools or CLOS, and the full language.  I
      do not personally believe that CLOS can be subsetted out.



      5  INTERSECTING ERROR TERMINOLOGY WITH LANGUAGE CONFORMANCE

           Pascal  breaks  errors   into   3   categories.    Conforming
      implementations  are required to detect, encouraged to detect, ...
      the different categories.

           For our standard, if conformance, subsetting, and  extensions
      are  well-defined,  the  error  terminology  should  be  a natural
      extension,  not  much  different  from  the  terminology  I   have
      previously presented.

∂15-Dec-88  0124	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 Dec 88  01:24:38 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA05315; Thu, 15 Dec 88 01:23:42 PST
Message-Id: <8812150923.AA05315@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 Dec 88 04:22
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu,
        sandra%cdr@cs.utah.edu
Subject: Issue: CONFORMANCE-POSITION

Issue:        CONFORMANCE-POSITION
References:   Chapter 1, Section 1.5, Working draft of standard
Category:     Clarification
Edit history: 12-DEC-88, Version 1 by Chapman


Problem Description:

Two ways of defining conformance are in terms of a conforming program
and in terms of a conforming implementation. How should our standard
define conformance?


Proposal (CONFORMANCE-POSITION:PROGRAM)

For our standard, conformance should be defined in terms
of a conforming program, and perhaps conforming documentation.
Of course, within the standard itself certain requirements will be
levied on the implementation. However, the bottom line should not
be that the implementation conforms to the letter of the standard,
but that a program written to the letter of the standard will run
in all "conforming" implementations (defined as ones that run conforming
programs).


Rationale:

The standard must contain information about conformance. Including 
requirements which would be placed on implementations, however, leaves
the possiblity open that something would be overlooked, and so 
implementations may well conform without processing correctly
conforming programs.

Current Practice:

Pascal defines 
conformance in terms of both, PL/I defines conformance in terms of 
conforming programs only.
Fortran and Ada say that a conforming implementation correctly processes
conforming programs. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both programs and implementations.

Adoption Cost:

None.

Benefits:

This definition will give readers and validators a basis on which to read
the standard.

Conversion Cost:

None.

Aesthetics:

None.

Discussion:

∂15-Dec-88  0125	CL-Editorial-mailer 	Issue: DEPRECATION-POSITION  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 Dec 88  01:24:59 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA05319; Thu, 15 Dec 88 01:24:04 PST
Message-Id: <8812150924.AA05319@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 Dec 88 04:23
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu,
        sandra%cdr@cs.utah.edu
Subject: Issue: DEPRECATION-POSITION

Issue:        DEPRECATION-POSITION
References:   X3J13 committee and sub-committee meetings
Category:     Policy
Edit history: 12-DEC-88, Version 1 by Chapman


Problem Description:

When features of a language become outdated due to technology advances,
or unnecessary due to the addition of better features, should the old
features be deleted from the language or should support continue for
the features in order to insure that old programs don't break with
new implementations?


Proposal (DEPRECATION-POSITION:LIMITED)

For our standard, deprecation should be confined to a small
set of functions that are related to character handling. It's not
unreasonable for a language the size of Lisp to get rid of the
never-used tools, but we don't want to generate years of discussion
over a relatively minor issue when the standard goes for public review.


Rationale:

The standard should contain information about deprecation since
the topic has been mentioned more than once in X3J13, and since
Common Lisp is such a large language.

Current Practice:

Fortran successfully deprecated one constant. However, a proposal 
submitted during its latest standardization effort that 
suggested deleting old features in favor of new ones was
opposed vehemently. The Pascal committee is currently opposed
to deprecation, and the SPARC proposal suggests that 
deprecation should be dictated by the marketplace.


Adoption Cost:

None.

Benefits:

This policy will provide a basis for future X3J13 decisions.

Conversion Cost:

None.

Aesthetics:

None.

Discussion:

∂15-Dec-88  0125	CL-Editorial-mailer 	Issue: EXTENSIONS-POSITION   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 Dec 88  01:25:38 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA05329; Thu, 15 Dec 88 01:24:41 PST
Message-Id: <8812150924.AA05329@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 Dec 88 04:24
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu,
        sandra%cdr@cs.utah.edu
Subject: Issue: EXTENSIONS-POSITION

Issue:        EXTENSIONS-POSITION
References:   Chapter 1, Working draft of standard
Category:     Clarification
Edit history: 12-DEC-88, Version 1 by Chapman


Problem Description:

What is the definition of a language extension in Common Lisp? What
affect does an extension have on a conforming program? What obligation
does an implementation have to warn the user that an extension is 
being used?

Proposal (EXTENSIONS-POSITION:DOCUMENTATION)

For our standard, extensions can be covered in the
clauses concerning conforming documentation. Some extra 
statements about what conforming programs do in the presence
of extensions would be useful, but these statements will
be redundant considering that a conforming program uses 
only the facilities documented in the standard.



Rationale:

The standard should contain information about language extensions
since most implementations have extended the language to a certain
extent.

Current Practice:

?

Adoption Cost:

None.

Benefits:

This definition will provide a basis for proper understanding of 
the error terminology used in the standard.

Conversion Cost:

None.

Aesthetics:

None.

Discussion:

∂15-Dec-88  0126	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 Dec 88  01:26:00 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA05340; Thu, 15 Dec 88 01:25:06 PST
Message-Id: <8812150925.AA05340@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 Dec 88 04:24
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu,
        sandra%cdr@cs.utah.edu
Subject: Issue: SUBSETTING-POSITION

Issue:        SUBSETTING-POSITION
References:   X3J13 committee and sub-committee meetings
Category:     Policy
Edit history: 12-DEC-88, Version 1 by Chapman


Problem Description:

Should the CL standard be partitioned such that an implementation
could chose a subset of all the CL facilities to implement and 
still be a conforming implementation?

Proposal (SUBSETTING-POSITION:TWO-LEVELS)

For our standard, we should subset only if there's a chance
we could achieve international agreement on the standard by doing so.
If we do subset, there should be two levels: the full
language without whatever we can't agree on internationally,
and the full language. 


Rationale:


Current Practice:

Pascal has two levels of conforming implementations -- level 1 contains
level 0 and conformant arrays. This was a compromise necessary to achieve
international agreement. The 1981 PL/I was subsetted and the 
results were a range of implementations between the
subset and the full language; nobody wanted to use the subset so vendors
were forced to implement the full language eventually anyway.
Cobol had multiple levels of subsets. However, 
the only two levels that were important were the minimum 
subset and the full language. The middle levels were
seldom used other than transient points to the full language.
Fortran was subsetted. It was felt that subsetting encouraged
vendors to implement Fortran and therefore proliferate its usage,
but users were quite annoyed that one Fortran was considerably
different from another. 
The new Fortran language standards committee is
banning subsetting.
SPARC feels that 
subsets aren't good for facilitating interchange, but serve the
purpose of allowing
timely implementation of the standard.

A suggestion that was made by most language committee representatives
was to group subsetted parts meaningfully, and to minimize the number
of levels.

Adoption Cost:

None.

Benefits:

This policy will provide a basis for making decisions in X3J13.

Conversion Cost:

None.

Aesthetics:

None.

Discussion:

∂15-Dec-88  1132	CL-Editorial-mailer 	Issues: CONFORMANCE-POSITION, EXTENSIONS-POSITION
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Dec 88  11:31:52 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 15 Dec 88 13:36:17 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 15 Dec 88 14:24:38 EST
Date: Thu, 15 Dec 88 14:24 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issues: CONFORMANCE-POSITION, EXTENSIONS-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu,
        sandra%cdr@cs.utah.edu
In-Reply-To: <8812150923.AA05315@decwrl.dec.com>,
             <8812150924.AA05329@decwrl.dec.com>
Message-Id: <19881215192445.1.BARMAR@OCCAM.THINK.COM>

I think these two issues should refer to each other in their Related
Issues fields.  How we deal with extensions is closely related to how we
specify conformance.

    Issue:        CONFORMANCE-POSITION
    References:   Chapter 1, Section 1.5, Working draft of standard
    Category:     Clarification
    Edit history: 12-DEC-88, Version 1 by Chapman

    Proposal (CONFORMANCE-POSITION:PROGRAM)

    Current Practice:

CLtL generally describes things in terms of what a correct program can
expect.

I think dpANS C is also in terms of programs.  They have further defined
both "conforming" and "strictly conforming" programs; I think the
difference has something to do with how the program deals with features
that the standard says are implementation-defined.

    Issue:        EXTENSIONS-POSITION
    References:   Chapter 1, Working draft of standard
    Category:     Clarification
    Edit history: 12-DEC-88, Version 1 by Chapman


    Problem Description:

    What is the definition of a language extension in Common Lisp? What
    affect does an extension have on a conforming program? What obligation
    does an implementation have to warn the user that an extension is 
    being used?

    Proposal (EXTENSIONS-POSITION:DOCUMENTATION)

    For our standard, extensions can be covered in the
    clauses concerning conforming documentation. Some extra 
    statements about what conforming programs do in the presence
    of extensions would be useful, but these statements will
    be redundant considering that a conforming program uses 
    only the facilities documented in the standard.

This doesn't really answer the questions in the Problem Description.

I don't think that most language standards that are in terms of
conforming programs say much about extensions, since they don't usually
affect conforming programs.  Lisp is unique, however, in that it is
common to write programs that examine other programs.  Macros are simple
forms of such programs.  It is possible for a conforming program to be
given as data a non-conforming program, and the question of how this
should be handled arises.  Many people feel that it is unacceptable (or
at least unfortunate) that the language isn't specified carefully enough
that this can cause problems.  For example (the canonical IF example):

(defun translate-if-to-cond (form)
  (if (and (consp form) (eq (first form) 'if))
      (let ((predicate (second form))
	    (then (third form))
	    (else (fourth form)))
	`(cond (,predicate ,then)
	       (t ,else)))
      form))

This function works perfectly when given a conforming form, but it will
do the wrong thing when given an IF form that has multiple else-clauses,
as some implementations permit.  Of course it could check for that, but
the questions remains of whether it should need to.  Suppose the author
of the above code documents that it should only be used on programs that
are debugged and known not to have syntax errors; he would then be
somewhat justified in leaving syntax checking out of his program, since
that is the job of the compiler.

The most commonly proposed solution to this kind of problem is to
require the implementation to have a way to disable its extensions, so
that a programmer can be told when he is using a feature that might
affect his program's portability.  Whether this should be the default
mode is up for debate; I think most other standards that do this don't
require it to be the default.

    Current Practice:

    ?

CLtL allows any extension, provided that it doesn't alter the behavior
of a program that only uses what is specified in CLtL.  In particular,
any situation that "is an error" (either explicitly or implicitly) is a
potential area for extension.


    Adoption Cost:

    None.

No, there is a cost:  Vendors will have to improve their documentation
to list all their extensions.  Vendors will have to go through their
implementation and determine what is or isn't an extension (once we
decide what the definition is).  If the proposal about requiring a
non-extended mode is adopted, vendors must implement this feature.

∂15-Dec-88  1137	CL-Editorial-mailer 	Issue: DEPRECATION-POSITION  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Dec 88  11:37:06 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 15 Dec 88 13:44:08 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 15 Dec 88 14:33:41 EST
Date: Thu, 15 Dec 88 14:33 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: DEPRECATION-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu,
        sandra%cdr@cs.utah.edu
In-Reply-To: <8812150924.AA05319@decwrl.dec.com>
Message-Id: <19881215193357.2.BARMAR@OCCAM.THINK.COM>

    Date: 15 Dec 88 04:23
    From: chapman%aitg.DEC@decwrl.dec.com

    Issue:        DEPRECATION-POSITION
    References:   X3J13 committee and sub-committee meetings
    Category:     Policy
    Edit history: 12-DEC-88, Version 1 by Chapman


    Problem Description:

    When features of a language become outdated due to technology advances,
    or unnecessary due to the addition of better features, should the old
    features be deleted from the language or should support continue for
    the features in order to insure that old programs don't break with
    new implementations?

Are you talking about deprecation or deletion?  The definition of
deprecation is that the feature remains in the language, and it must be
fully supported by vendors, but programmers are being warned that it
will probably be deleted in the NEXT version of the standard, so they
should not use it in new programs, and should remove it from existing
programs if they plan on keeping them portable for several years.
Implementation writers might also generate warnings to help the
programmers exorcise use of the feature from their programs, but they
can't fail to execute the program properly because of it.

                                                barmar

∂16-Dec-88  0932	CL-Editorial-mailer 	Re: Issue: DEPRECATION-POSITION   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Dec 88  09:32:18 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA10578; Fri, 16 Dec 88 10:31:19 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA05747; Fri, 16 Dec 88 10:31:14 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8812161731.AA05747@defun.utah.edu>
Date: Fri, 16 Dec 88 10:31:13 MST
Subject: Re: Issue: DEPRECATION-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu,
        sandra%cdr@cs.utah.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com, 15 Dec 88 04:23

I don't think it's appropriate for the editorial committee to state
that the only features that should be deprecated are some of the
character functions.  For example, cl-cleanup is now proposing to
remove PROVIDE and REQUIRE from the language, cl-compiler is proposing
to remove #, and COMPILER-LET, and there may be other odds and ends as
well. 

I personally would argue for not including "deprecated" features in
the standard at all, because including them now will make it harder to
remove them later.  My perception is that ANSI Common Lisp is turning
out to be a much different language than what is described in CLtL,
particularly if CLOS becomes a required part of the language.  If,
with the benefit of hindsight and experience, we now realize that some
"features" described in CLtL were really "bugs", the time to remove
them is *before* they become cast in stone as part of ANSI Common
Lisp.  I suspect that most implementors will continue to provide these
features as extensions anyway, as long as a substantial number of
their customers are still using them. 

-Sandra
-------

∂20-Dec-88  0850	CL-Editorial-mailer 	file names    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Dec 88  08:50:00 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA18715; Tue, 20 Dec 88 08:48:53 PST
Message-Id: <8812201648.AA18715@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Dec 88 11:39
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: file names


F001.STAR
f002.starvar
F003.STARSTAR
F004.STARSTARSTAR
F005.PLUS
F006.PLUSVAR
F007.PLUSPLUS
F008.PLUSPLUSPLUS
F009.MINUS
F010.MINUSVAR
F011.SLASH
F012.SLASHVAR
F013.SLASHSLASH
F014.SLASHSLASHSLASH
F015.SLASHEQSIGN
F016.1PLUS
F017.1MINUS
F018.LESSTHAN
F019.LESSTHANEQSIGN
F020.EQSIGN
F021.GTRTHAN
F022.GTRTHANEQSIGN
F023.ABS
F024.ACONS
F025.ACOSH
F026.ACOS
F027.ADJOIN
F028.ADJUST-ARRAY
F029.ADJUSTABLE-ARRAY-P
F030.ALPHA-CHAR-P
F031.ALPHANUMERICP
F032.AND
F033.APPEND
F034.APPLY
F035.APPLYHOOK
F036.APPLYHOOKVAR
F037.APROPOS
F038.APROPOS-LIST
F039.AREF
F040.ARRAY-DIMENSION-LIMIT
F041.ARRAY-DIMENSION
F042.ARRAY-DIMENSIONS
F043.ARRAY-ELEMENT-TYPE
F044.ARRAY-HAS-FILL-POINTER-P
F045.ARRAY-IN-BOUNDS-P
F046.ARRAY-RANK
F047.ARRAY-RANK-LIMIT
F048.ARRAY-ROW-MAJOR-INDEX
F049.ARRAY-TOTAL-SIZE
F050.ARRAY-TOTAL-SIZE-LIMIT
F051.ARRAYP
F052.ASH
F053.ASIN
F054.ASINH
F055.ASSERT
F056.ASSOC
F057.ASSOC-IF
F058.ASSOC-IF-NOT
F059.ATAN
F060.ATANH
F061.ATOM
F062.BIT
F063.BIT-AND
F064.BIT-ANDC1
F065.BIT-ANDC2
F066.BIT-EQV
F067.BIT-IOR
F068.BIT-NAND
F069.BIT-NOR
F070.BIT-NOT
F071.BIT-ORC1
F072.BIT-ORC2
F073.BIT-VECTOR-P
F074.BIT-XOR
F075.BLOCK
F076.BOOLE
F077.BOOLE-1
F078.BOOLE-2
F079.BOOLE-AND
F080.BOOLE-ANDC1
F081.BOOLE-ANDC2
F082.BOOLE-C1
F083.BOOLE-C2
F084.BOOLE-CLR
F085.BOOLE-EQV
F086.BOOLE-IOR
F087.BOOLE-NAND
F088.BOOLE-NOR
F089.BOOLE-ORC1
F090.BOOLE-ORC2
F091.BOOLE-SET
F092.BOOLE-XOR
F093.BOTH-CASE-P
F094.BOUNDP
F095.BREAK
F096.BREAK-ON-WARNINGS
F097.BUTLAST
F098.BYTE
F099.BYTE-POSITION
F100.BYTE-SIZE
F101.CAAAAR
F102.CAAADR
F103.CAAAR
F104.CAADAR
F105.CAADDR
F106.CAADR
F107.CAAR
F108.CADAAR
F109.CADADR
F110.CADAR
F111.CADDAR
F112.CADDDR
F113.CADDR
F114.CADR
F115.CALL-ARGUMENTS-LIMIT
F116.CAR
F117.CASE
F118.CATCH
F119.CCASE
F120.CDAAAR
F121.CDAADR
F122.CDAAR
F123.CDADAR
F124.CDADDR
F125.CDADR
F126.CDAR
F127.CDDAAR
F128.CDDADR
F129.CDDAR
F130.CDDDAR
F131.CDDDDR
F132.CDDDR
F133.CDDR
F134.CDR
F135.CEILING
F136.CERROR
F137.CHAR
F138.CHAR-BIT
F139.CHAR-BITS-LIMIT
F140.CHAR-BITS
F141.CHAR-CODE
F142.CHAR-CODE-LIMIT
F143.CHAR-CONTROL-BIT
F144.CHAR-DOWNCASE
F145.CHAR-EQUAL
F146.CHAR-FONT
F147.CHAR-FONT-LIMIT
F148.CHAR-GREATERP
F149.CHAR-HYPER-BIT
F150.CHAR-INT
F151.CHAR-LESSP
F152.CHAR-META-BIT
F153.CHAR-NAME
F154.CHAR-NOT-EQUAL
F155.CHAR-NOT-GREATERP
F156.CHAR-NOT-LESSP
F157.CHAR-SUPER-BIT
F158.CHAR-UPCASE
F159.CHARSLASHEQSIGN
F160.CHARLESSTHAN
F161.CHARLESSTHANEQSIGN
F162.CHAREQSIGN
F163.CHARGTRTHAN
F164.CHARGTRTHANEQSIGN
F165.CHARACTERP
F166.CHARACTER
F167.CHECK-TYPE
F168.CIS
F169.CLEAR-INPUT
F170.CLEAR-OUTPUT
F171.CLOSE
F172.CLRHASH
F173.CODE-CHAR
F174.COERCE
F175.COMMONP
F176.COMPILE
F177.COMPILE-FILE
F178.COMPILED-FUNCTION-P
F179.COMPILER-LET
F180.COMPLEXP
F181.COMPLEX
F182.CONCATENATE
F183.COND
F184.CONJUGATE
F185.CONS
F186.CONSP
F187.CONSTANTP
F188.COPY-ALIST
F189.COPY-LIST
F190.COPY-READTABLE
F191.COPY-SEQ
F192.COPY-SYMBOL
F193.COPY-TREE
F194.COS
F195.COSH
F196.COUNT
F197.COUNT-IF
F198.COUNT-IF-NOT
F199.CTYPECASE
F200.DEBUG-IO
F201.DECF
F202.DECLARE
F203.DECODE-FLOAT
F204.DECODE-UNIVERSAL-TIME
F205.DEFAULT-PATHNAME-DEFAULTS
F206.DEFCONSTANT
F207.DEFINE-MODIFY-MACRO
F208.DEFINE-SETF-METHOD
F209.DEFMACRO
F210.DEFPARAMETER
F211.DEFSETF
F212.DEFSTRUCT
F213.DEFTYPE
F214.DEFUN
F215.DEFVAR
F216.DELETE
F217.DELETE-DUPLICATES
F218.DELETE-FILE
F219.DELETE-IF
F220.DELETE-IF-NOT
F221.DENOMINATOR
F222.DEPOSIT-FIELD
F223.DESCRIBE
F224.DIGIT-CHAR
F225.DIGIT-CHAR-P
F226.DIRECTORY
F227.DIRECTORY-NAMESTRING
F228.DISASSEMBLE
F229.DO-DOSTAR
F230.DO-ALL-SYMBOLS
F231.DO-EXTERNAL-SYMBOLS
F232.DO-SYMBOLS
F233.DOCUMENTATION
F234.DOLIST
F235.DOTIMES
F236.DOUBLE-FLOAT-EPSILON
F237.DOUBLE-FLOAT-NEGATIVE-EPSILON
F238.DPB
F239.DRIBBLE
F240.ECASE
F241.ED
F242.EIGHTH
F243.ELT
F244.ENCODE-UNIVERSAL-TIME
F245.ENDP
F246.ENOUGH-NAMESTRING
F247.EQ
F248.EQL
F249.EQUALP
F250.EQUAL
F251.ERROR
F252.ERROR-OUTPUT
F253.ETYPECASE
F254.EVAL
F255.EVAL-WHEN
F256.EVALHOOKVAR
F257.EVALHOOK
F258.EVENP
F259.EVERY
F260.EXP
F261.EXPORT
F262.EXPT
F263.FBOUNDP
F264.FCEILING
F265.FEATURES
F266.FFLOOR
F267.FIFTH
F268.FILE-AUTHOR
F269.FILE-LENGTH
F270.FILE-NAMESTRING
F271.FILE-POSITION
F272.FILE-WRITE-DATE
F273.FILL
F274.FILL-POINTER
F275.FIND
F276.FIND-ALL-SYMBOLS
F277.FIND-IF
F278.FIND-IF-NOT
F279.FIND-PACKAGE
F280.FIND-SYMBOL
F281.FINISH-OUTPUT
F282.FIRST
F283.FLET
F284.FLOAT
F285.FLOAT-DIGITS
F286.FLOAT-PRECISION
F287.FLOAT-RADIX
F288.FLOAT-SIGN
F289.FLOATP
F290.FLOOR
F291.FMAKUNBOUND
F292.FORCE-OUTPUT
F293.FORMAT
F294.FOURTH
F295.FRESH-LINE
F296.FROUND
F297.FTRUNCATE
F298.FUNCALL
F299.FUNCTION
F300.FUNCTIONP
F301.GCD
F302.GENSYM
F303.GENTEMP
F304.GET
F305.GET-DECODED-TIME
F306.GET-DISPATCH-MACRO-CHARACTER
F307.GET-INTERNAL-REAL-TIME
F308.GET-INTERNAL-RUN-TIME
F309.GET-MACRO-CHARACTER
F310.GET-OUTPUT-STREAM-STRING
F311.GET-PROPERTIES
F312.GET-SETF-METHOD-MULTIPLE-VALUE
F313.GET-SETF-METHOD
F314.GET-UNIVERSAL-TIME
F315.GETF
F316.GETHASH
F317.GO
F318.GRAPHIC-CHAR-P
F319.HASH-TABLE-COUNT
F320.HASH-TABLE-P
F321.HOST-NAMESTRING
F322.IDENTITY
F323.IF
F324.IMAGPART
F325.IMPORT
F326.IN-PACKAGE
F327.INCF
F328.INPUT-STREAM-P
F329.INSPECT
F330.INT-CHAR
F331.INTEGER-DECODE-FLOAT
F332.INTEGER-LENGTH
F333.INTEGERP
F334.INTERNAL-TIME-UNITS-PER-SECOND
F335.INTERN
F336.INTERSECTION
F337.ISQRT
F338.KEYWORDP
F339.LABELS
F340.LAMBDA-LIST-KEYWORDS
F341.LAMBDA-PARAMETERS-LIMIT
F342.LAST
F343.LCM
F344.LDB
F345.LDB-TEST
F346.LDIFF
F347.LEAST-NEGATIVE-DOUBLE-FLOAT
F348.LEAST-NEGATIVE-LONG-FLOAT
F349.LEAST-NEGATIVE-SHORT-FLOAT
F350.LEAST-NEGATIVE-SINGLE-FLOAT
F351.LEAST-POSITIVE-DOUBLE-FLOAT
F352.LEAST-POSITIVE-LONG-FLOAT
F353.LEAST-POSITIVE-SHORT-FLOAT
F354.LEAST-POSITIVE-SINGLE-FLOAT
F355.LENGTH
F356.LET-LETSTAR
F357.LISP-IMPLEMENTATION-TYPE
F358.LISP-IMPLEMENTATION-VERSION
F359.LIST-LISTSTAR
F360.LIST-ALL-PACKAGES
F361.LIST-LENGTH
F362.LISTEN
F363.LISTP
F364.LOAD
F365.LOAD-VERBOSE
F366.LOCALLY
F367.LOG
F368.LOGANDC1
F369.LOGANDC2
F370.LOGAND
F371.LOGBITP
F372.LOGCOUNT
F373.LOGEQV
F374.LOGIOR
F375.LOGNAND
F376.LOGNOR
F377.LOGNOT
F378.LOGORC1
F379.LOGORC2
F380.LOGTEST
F381.LOGXOR
F382.LONG-FLOAT-EPSILON
F383.LONG-FLOAT-NEGATIVE-EPSILON
F384.LONG-SITE-NAME
F385.LOOP
F386.LOWER-CASE-P
F387.MACHINE-INSTANCE
F388.MACHINE-TYPE
F389.MACHINE-VERSION
F390.MACRO-FUNCTION
F391.MACROEXPAND
F392.MACROEXPAND-1
F393.MACROEXPAND-HOOK
F394.MACROLET
F395.MAKE-ARRAY
F396.MAKE-BROADCAST-STREAM
F397.MAKE-CHAR
F398.MAKE-CONCATENATED-STREAM
F399.MAKE-DISPATCH-MACRO-CHARACTER
F400.MAKE-ECHO-STREAM
F401.MAKE-HASH-TABLE
F402.MAKE-LIST
F403.MAKE-PACKAGE
F404.MAKE-PATHNAME
F405.MAKE-RANDOM-STATE
F406.MAKE-SEQUENCE
F407.MAKE-STRING-INPUT-STREAM
F408.MAKE-STRING-OUTPUT-STREAM
F409.MAKE-STRING
F410.MAKE-SYMBOL
F411.MAKE-SYNONYM-STREAM
F412.MAKE-TWO-WAY-STREAM
F413.MAKUNBOUND
F414.MAP
F415.MAPC
F416.MAPCAN
F417.MAPCAR
F418.MAPCON
F419.MAPHASH
F420.MAPL
F421.MAPLIST
F422.MASK-FIELD
F423.MAX
F424.MEMBER
F425.MEMBER-IF
F426.MEMBER-IF-NOT
F427.MERGE
F428.MERGE-PATHNAMES
F429.MIN
F430.MINUSP
F431.MISMATCH
F432.MOD
F433.MODULES
F434.MOST-NEGATIVE-DOUBLE-FLOAT
F435.MOST-NEGATIVE-FIXNUM
F436.MOST-NEGATIVE-LONG-FLOAT
F437.MOST-NEGATIVE-SHORT-FLOAT
F438.MOST-NEGATIVE-SINGLE-FLOAT
F439.MOST-POSITIVE-DOUBLE-FLOAT
F440.MOST-POSITIVE-FIXNUM
F441.MOST-POSITIVE-LONG-FLOAT
F442.MOST-POSITIVE-SHORT-FLOAT
F443.MOST-POSITIVE-SINGLE-FLOAT
F444.MULTIPLE-VALUE-BIND
F445.MULTIPLE-VALUE-CALL
F446.MULTIPLE-VALUE-LIST
F447.MULTIPLE-VALUE-PROG1
F448.MULTIPLE-VALUE-SETQ
F449.MULTIPLE-VALUES-LIMIT
F450.NAME-CHAR
F451.NAMESTRING
F452.NBUTLAST
F453.NCONC
F454.NIL
F455.NINTERSECTION
F456.NINTH
F457.NOT
F458.NOTANY
F459.NOTEVERY
F460.NRECONC
F461.NREVERSE
F462.NSET-DIFFERENCE
F463.NSET-EXCLUSIVE-OR
F464.NSTRING-CAPITALIZE
F465.NSTRING-DOWNCASE
F466.NSTRING-UPCASE
F467.NSUBLIS
F468.NSUBST
F469.NSUBST-IF
F470.NSUBST-IF-NOT
F471.NSUBSTITUTE
F472.NSUBSTITUTE-IF
F473.NSUBSTITUTE-IF-NOT
F474.NTH
F475.NTHCDR
F476.NULL
F477.NUMBERP
F478.NUMERATOR
F479.NUNION
F480.ODDP
F481.OPEN
F482.OR
F483.OUTPUT-STREAM-P
F484.PACKAGE
F485.PACKAGE-NAME
F486.PACKAGE-NICKNAMES
F487.PACKAGE-SHADOWING-SYMBOLS
F488.PACKAGE-USE-LIST
F489.PACKAGE-USED-BY-LIST
F490.PACKAGEP
F491.PAIRLIS
F492.PARSE-INTEGER
F493.PARSE-NAMESTRING
F494.PATHNAME
F495.PATHNAME-DEVICE
F496.PATHNAME-DIRECTORY
F497.PATHNAME-HOST
F498.PATHNAME-NAME
F499.PATHNAME-TYPE
F500.PATHNAME-VERSION
F501.PATHNAMEP
F502.PEEK-CHAR
F503.PHASE
F504.PI
F505.PLUSP
F506.POP
F507.POSITION
F508.POSITION-IF
F509.POSITION-IF-NOT
F510.PPRINT
F511.PRIN1
F512.PRIN1-TO-STRING
F513.PRINC
F514.PRINC-TO-STRING
F515.PRINT
F516.PRINT-ARRAY
F517.PRINT-BASE
F518.PRINT-CASE
F519.PRINT-CIRCLE
F520.PRINT-ESCAPE
F521.PRINT-GENSYM
F522.PRINT-LENGTH
F523.PRINT-LEVEL
F524.PRINT-PRETTY
F525.PRINT-RADIX
F526.PROBE-FILE
F527.PROCLAIM
F528.PROG
F529.PROGSTAR
F530.PROG1
F531.PROG2
F532.PROGN
F533.PROGV
F534.PROVIDE
F535.PSETF
F536.PSETQ
F537.PUSH
F538.PUSHNEW
F539.QUERY-IO
F540.QUOTE
F541.RANDOM
F542.RANDOM-STATE
F543.RANDOM-STATE-P
F544.RASSOC
F545.RASSOC-IF
F546.RASSOC-IF-NOT
F547.RATIONAL
F548.RATIONALIZE
F549.RATIONALP
F550.READ
F551.READ-BASE
F552.READ-BYTE
F553.READ-CHAR-NO-HANG
F554.READ-CHAR
F555.READ-DEFAULT-FLOAT-FORMAT
F556.READ-DELIMITED-LIST
F557.READ-FROM-STRING
F558.READ-LINE
F559.READ-PRESERVING-WHITESPACE
F560.READ-SUPPRESS
F561.READTABLE
F562.READTABLEP
F563.REALPART
F564.REDUCE
F565.REM
F566.REMF
F567.REMHASH
F568.REMOVE
F569.REMOVE-DUPLICATES
F570.REMOVE-IF
F571.REMOVE-IF-NOT
F572.REMPROP
F573.RENAME-FILE
F574.RENAME-PACKAGE
F575.REPLACE
F576.REQUIRE
F577.REST
F578.RETURN
F579.RETURN-FROM
F580.REVAPPEND
F581.REVERSE
F582.ROOM
F583.ROTATEF
F584.ROUND
F585.RPLACA
F586.RPLACD
F587.SBIT
F588.SCALE-FLOAT
F589.SCHAR
F590.SEARCH
F591.SECOND
F592.SET
F593.SET-CHAR-BIT
F594.SET-DIFFERENCE
F595.SET-DISPATCH-MACRO-CHARACTER
F596.SET-EXCLUSIVE-OR
F597.SET-MACRO-CHARACTER
F598.SET-SYNTAX-FROM-CHAR
F599.SETF
F600.SETQ
F601.SEVENTH
F602.SHADOW
F603.SHADOWING-IMPORT
F604.SHIFTF
F605.SHORT-FLOAT-EPSILON
F606.SHORT-FLOAT-NEGATIVE-EPSILON
F607.SHORT-SITE-NAME
F608.SIGNUM
F609.SIMPLE-BIT-VECTOR-P
F610.SIMPLE-STRING-P
F611.SIMPLE-VECTOR-P
F612.SIN
F613.SINGLE-FLOAT-EPSILON
F614.SINGLE-FLOAT-NEGATIVE-EPSILON
F615.SINH
F616.SIXTH
F617.SLEEP
F618.SOFTWARE-TYPE
F619.SOFTWARE-VERSION
F620.SOME
F621.SORT
F622.SPECIAL-FORM-P
F623.SQRT
F624.STABLE-SORT
F625.STANDARD-CHAR-P
F626.STANDARD-INPUT
F627.STANDARD-OUTPUT
F628.STEP
F629.STREAM-ELEMENT-TYPE
F630.STREAMP
F631.STRING
F632.STRING-CAPITALIZE
F633.STRING-CHAR-P
F634.STRING-DOWNCASE
F635.STRING-EQUAL
F636.STRING-GREATERP
F637.STRING-LEFT-TRIM
F638.STRING-LESSP
F639.STRING-NOT-EQUAL
F640.STRING-NOT-GREATERP
F641.STRING-NOT-LESSP
F642.STRING-RIGHT-TRIM
F643.STRING-TRIM
F644.STRING-UPCASE
F645.STRINGSLASHEQSIGN
F646.STRINGLESSTHANEQSIGN
F647.STRINGLESSTHAN
F648.STRINGEQSIGN
F649.STRINGGTRTHANEQSIGN
F650.STRINGGTRTHAN
F651.STRINGP
F652.SUBLIS
F653.SUBSEQ
F654.SUBSETP
F655.SUBST
F656.SUBST-IF
F657.SUBST-IF-NOT
F658.SUBSTITUTE
F659.SUBSTITUTE-IF
F660.SUBSTITUTE-IF-NOT
F661.SUBTYPEP
F662.SVREF
F663.SXHASH
F664.SYMBOL-FUNCTION
F665.SYMBOL-NAME
F666.SYMBOL-PACKAGE
F667.SYMBOL-PLIST
F668.SYMBOL-VALUE
F669.SYMBOLP
F670.T
F671.TAGBODY
F672.TAILP
F673.TANH
F674.TAN
F675.TENTH
F676.TERMINAL-IO
F677.TERPRI
F678.THE
F679.THIRD
F680.THROW
F681.TIME
F682.TRACE
F683.TRACE-OUTPUT
F684.TREE-EQUAL
F685.TRUENAME
F686.TRUNCATE
F687.TYPE-OF
F688.TYPECASE
F689.TYPEP
F690.UNEXPORT
F691.UNINTERN
F692.UNION
F693.UNLESS
F694.UNREAD-CHAR
F695.UNTRACE
F696.UNUSE-PACKAGE
F697.UNWIND-PROTECT
F698.UPPER-CASE-P
F699.USE-PACKAGE
F700.USER-HOMEDIR-PATHNAME
F701.VALUES4
F702.VALUES-LIST
F703.VECTOR
F704.VECTOR-POP
F705.VECTOR-PUSH
F706.VECTOR-PUSH-EXTEND
F707.VECTORP
F708.WARN
F709.WHEN
F710.WITH-INPUT-FROM-STRING
F711.WITH-OPEN-FILE
F712.WITH-OPEN-STREAM
F713.WITH-OUTPUT-TO-STRING
F714.WRITE
F715.WRITE-BYTE
F716.WRITE-CHAR
F717.WRITE-LINE
F718.WRITE-STRING
F719.WRITE-TO-STRING
F720.Y-OR-N-P
F721.YES-OR-NO-P
F722.ZEROP
F750.ROW-MAJOR-AREF
F800.ABORT
F801.ARITHMETIC-ERROR-OPERANDS
F802.ARITHMETIC-ERROR-OPERATION
F803.ASSERT
F804.BREAK
F805.BREAK-ON-SIGNALS
F806.BREAK-ON-WARNINGS
F807.CCASE
F808.CELL-ERROR-NAME
F809.CERROR
F810.CHECK-TYPE
F811.COMPUTE-RESTARTS
F812.CONTINUE
F813.CTYPECASE
F814.DEBUGGER-HOOK
F815.DEFINE-CONDITION
F816.ECASE
F817.ERROR
F818.ETYPECASE
F819.FILE-ERROR-PATHNAME
F820.FIND-RESTART
F821.HANDLER-BIND
F822.HANDLER-CASE
F823.IGNORE-ERRORS
F824.INVOKE-DEBUGGER
F825.INVOKE-RESTART-INTERACTIVELY
F826.INVOKE-RESTART
F827.MAKE-CONDITION
F828.MUFFLE-WARNING
F829.PACKAGE-ERROR-PACKAGE
F830.RESTART-BIND
F831.RESTART-CASE
F832.RESTART-NAME
F833.SIGNAL
F834.SIMPLE-CONDITION-FORMAT-ARGUMENTS
F835.SIMPLE-CONDITION-FORMAT-STRING
F836.STORE-VALUE
F837.STREAM-ERROR-STREAM
F838.TYPE-ERROR-DATUM
F839.TYPE-ERROR-EXPECTED-TYPE
F840.USE-VALUE
F841.WARN
F842.WITH-SIMPLE-RESTART
F900.ADD-METHOD
F901.CALL-METHOD
F902.CALL-NEXT-METHOD
F903.CHANGE-CLASS
F904.CLASS-NAME
F905.CLASS-OF
F906.COMPUTE-APPLICABLE-METHODS
F907.DEFCLASS
F908.DEFGENERIC
F909.DEFINE-METHOD-COMBINATION
F910.DEFMETHOD
F911.DESCRIBE
F912.DOCUMENTATION-SETF-DOCUMENTATION
F913.ENSURE-GENERIC-FUNCTION
F914.FIND-CLASS
F915.FIND-METHOD
F916.FUNCTION-KEYWORDS
F917.GENERIC-FLET
F918.GENERIC-FUNCTION
F919.GENERIC-LABELS
F920.INITIALIZE-INSTANCE
F921.INVALID-METHOD-ERROR
F922.MAKE-INSTANCE
F923.MAKE-INSTANCES-OBSOLETE
F924.METHOD-COMBINATION-ERROR
F925.METHOD-QUALIFIERS
F926.NEXT-METHOD-P
F927.NO-APPLICABLE-METHOD
F928.NO-NEXT-METHOD
F929.PRINT-OBJECT
F930.REINITIALIZE-INSTANCE
F931.REMOVE-METHOD
F932.SHARED-INITIALIZE
F933.SLOT-BOUNDP
F934.SLOT-EXISTS-P
F935.SLOT-MAKUNBOUND
F936.SLOT-MISSING
F937.SLOT-UNBOUND
F938.SLOT-VALUE
F939.SYMBOL-MACROLET
F940.UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
F941.UPDATE-INSTANCE-FOR-REDEFINED-CLASS
F942.WITH-ACCESSORS
F943.WITH-ADDED-METHODS
F944.WITH-SLOTS
F945.SETF-CLASS-NAME
F946.SETF-DOCUMENTATION

∂20-Dec-88  0858	CL-Editorial-mailer 	functions changed by X3J13 issues 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Dec 88  08:58:15 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA19791; Tue, 20 Dec 88 08:57:15 PST
Message-Id: <8812201657.AA19791@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Dec 88 11:20
To: cl-editorial@sail.stanford.edu
Subject: functions changed by X3J13 issues

As you know, the approved X3J13 issues will be included in the standard. 
So far I have included all but two of the approved issues, and have 
generated a list of tools that have been changed so far by the issues.
Following is that list for your review. Please note if any of the tools
for which you are responsible have been changed.
kc

adjust-array
append
assoc
count
decf
declare
defconstant
define-modify-macro
define-setf-method
defmacro
defparameter
defsetf
defstruct
deftype
defvar
delete
delete-file
disassemble
do-symbols
dribble
*features*
fill
find
flet
format
get-setf-method
getf
import
incf
last
ldb
macro-function
merge-pathnames
mismatch
namestring
nconc
open
parse-integer
parse-namestring
pathname
pathname-host
pop
position
proclaim
psetf
push
pushnew
rassoc
read-from-string
reduce
remf
remove
remove-duplicates
rename-file
replace
search
setf
shadow
shiftf
string-upcase
stringeqsign
subseq
substitute
truename
with-input-from-string
with-open-file
write
write-string
row-major-aref
assert
ccase
check-type

∂20-Dec-88  1253	CL-Editorial-mailer 	Hawaii   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Dec 88  12:52:39 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA04417; Tue, 20 Dec 88 12:51:40 PST
Message-Id: <8812202051.AA04417@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Dec 88 14:46
To: cl-editorial@sail.stanford.edu
Subject: Hawaii

I haven't heard for sure, but I don't believe there will be any subcommittee
meetings at the Hawaii meeting. If I find out differently, I'll send you
a proposed agenda.

I'd like to get together anyway, though, unless we can do this through mail,
to discuss the "*-position" issues I've sent you. I'd like to bring them
to vote so we can move on, but I haven't received much comment from you.
The next mail messages you receive should be those issues, plus another,
with the changes from the comments I have received so far. Please indicate
whether or not you believe these issues require a vote. If so, please
indicate what it will take the make the issues ones you would vote for.

After the holidays (but maybe sooner), I will be sending the error terms
to you in the form of an issue that I'd also like to bring to vote. I
realize that we haven't met the voting guidelines, but I'd like to try
to resolve these issues anyway.

Thanks for your help.
kc

∂20-Dec-88  1319	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Dec 88  13:19:43 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA06187; Tue, 20 Dec 88 13:18:42 PST
Message-Id: <8812202118.AA06187@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Dec 88 16:17
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: SUBSETTING-POSITION

Issue:        SUBSETTING-POSITION
References:   X3J13 committee and sub-committee meetings
Category:     Policy
Edit history: 12-DEC-88, Version 1 by Chapman
 
 
Problem Description:
 
Should the CL standard be partitioned such that an implementation
could chose a subset of all the CL facilities to implement and 
still be a conforming implementation?
 
Proposal (SUBSETTING-POSITION:TWO-LEVELS)
 
For our standard, we should subset only if there's a chance
we could achieve international agreement on the standard by doing so.
If we do subset, there should be two levels: the full
language without whatever we can't agree on internationally,
and the full language. 
 
 
Rationale:
 
 
Current Practice:
 
Pascal has two levels of conforming implementations -- level 1 contains
level 0 and conformant arrays. This was a compromise necessary to achieve
international agreement. The 1981 PL/I was subsetted and the 
results were a range of implementations between the
subset and the full language; nobody wanted to use the subset so vendors
were forced to implement the full language eventually anyway.
Cobol had multiple levels of subsets. However, 
the only two levels that were important were the minimum 
subset and the full language. The middle levels were
seldom used other than transient points to the full language.
Fortran was subsetted. It was felt that subsetting encouraged
vendors to implement Fortran and therefore proliferate its usage,
but users were quite annoyed that one Fortran was considerably
different from another. 
The new Fortran language standards committee is
banning subsetting.
SPARC feels that 
subsets aren't good for facilitating interchange, but serve the
purpose of allowing
timely implementation of the standard.
 
A suggestion that was made by most language committee representatives
was to group subsetted parts meaningfully, and to minimize the number
of levels.
 
Adoption Cost:
 
None.
 
Benefits:
 
This policy will provide a basis for making decisions in X3J13.
 
Conversion Cost:
 
None.
 
Aesthetics:
 
None.
 
Discussion:

∂20-Dec-88  1348	CL-Editorial-mailer 	Issue: EXTENSIONS-POSITION   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Dec 88  13:48:30 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA07723; Tue, 20 Dec 88 13:47:24 PST
Message-Id: <8812202147.AA07723@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Dec 88 16:16
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTENSIONS-POSITION

Issue:        EXTENSIONS-POSITION
References:   Chapter 1, Working draft of standard
Category:     Clarification
Related Issue:CONFORMANCE-POSITION
Edit history: 12-DEC-88, Version 1 by Chapman
              20-DEC-88, Version 2 by Chapman
 
Problem Description:
 
What is the definition of a language extension?
What effect does a language extension have on a conforming program? 
What obligation does an implementation have to warn the user that an 
extension is being used?
 
Proposal (EXTENSIONS-POSITION:DOCUMENTATION)
 
The standard document should define a language extension to be
any implementation-supplied tool that isn't explicitly defined
in the standard. This includes facilities added to tools defined
in the standard.
The standard document should levy the following requirement on a 
conforming implementation's documentation:
The documentation that accompanies a conforming implementation should clearly
state which parts of the implementation are extensions.  

Rationale:
 
The standard should contain information about language extensions
since most implementations have extended the language.
 
Current Practice:

CLtL allows any extension, provided that it doesn't alter the behavior
of a program that only uses what is specified in CLtL.  In particular,
any situation that "is an error" (either explicitly or implicitly) is a
potential area for extension.
 
 
Adoption Cost:
 
Vendors will have to improve their documentation
to list all their extensions.  Vendors will have to go through their
implementation and determine what is or isn't an extension.
 
 
Benefits:
 
This definition will provide a basis for proper understanding of 
the error terminology used in the standard. The implementation
documentation requirement will aid the user in producing portable code.
 
Conversion Cost:
 
None.
 
Aesthetics:
 
None.
 
Discussion:
 
Comments:
"The most commonly proposed solution to this kind of problem is to
require the implementation to have a way to disable its extensions, so
that a programmer can be told when he is using a feature that might
affect his program's portability.  Whether this should be the default
mode is up for debate; I think most other standards that do this don't
require it to be the default."

Response:
Requiring an implementation to be able to disable extensions seems like
a more costly alternative than requiring an implementation to document
its extensions as extensions if it is to be conforming, since presumably
an implementation will document user-visible extension anyway.

∂20-Dec-88  1423	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Dec 88  14:22:57 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA10364; Tue, 20 Dec 88 14:21:53 PST
Message-Id: <8812202221.AA10364@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Dec 88 16:17
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: CONFORMANCE-POSITION

Issue:        CONFORMANCE-POSITION
References:   Chapter 1, Section 1.5, Working draft of standard
Category:     Clarification
Related Issue:EXTENSIONS-POSITION
Edit history: 12-DEC-88, Version 1 by Chapman
              20-DEC-88, Version 2 by Chapman 
 
Problem Description:
 
Two ways of defining conformance are in terms of a conforming program
and in terms of a conforming implementation. How should our standard
define conformance?
 
 
Proposal (CONFORMANCE-POSITION:PROGRAM)
 
For our standard, conformance should be defined in terms
of a conforming program, and perhaps conforming documentation.
Of course, within the standard itself certain requirements will be
levied on the implementation. However, the bottom line should not
be that the implementation conforms to the letter of the standard,
but that a program written to the letter of the standard will run
in all "conforming" implementations (defined as ones that run conforming
programs).
 
 
Rationale:
 
The standard must contain information about conformance. Including 
requirements which would be placed on implementations, however, leaves
the possiblity open that something would be overlooked, and so 
implementations may well conform without processing correctly
conforming programs.
 
Current Practice:

CLtL generally describes things in terms of what a correct program can
expect.
 
I think dpANS C is also in terms of programs.  They have further defined
both "conforming" and "strictly conforming" programs; I think the
difference has something to do with how the program deals with features
that the standard says are implementation-defined.
 
Pascal defines 
conformance in terms of both, PL/I defines conformance in terms of 
conforming programs only.
Fortran and Ada say that a conforming implementation correctly processes
conforming programs. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both programs and implementations.
 
Adoption Cost:
 
None.
 
Benefits:
 
This definition will give readers and validators a basis on which to read
the standard.
 
Conversion Cost:
 
None.
 
Aesthetics:
 
None.
 
Discussion:

∂20-Dec-88  1423	CL-Editorial-mailer 	Issue: DEPRECATION-POSITION  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Dec 88  14:23:43 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA10413; Tue, 20 Dec 88 14:22:45 PST
Message-Id: <8812202222.AA10413@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Dec 88 16:16
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: DEPRECATION-POSITION

Issue:        DEPRECATION-POSITION
References:   X3J13 committee and sub-committee meetings
Category:     Policy
Edit history: 12-DEC-88, Version 1 by Chapman
              20-DEC-88, Version 2 by Chapman
 
Problem Description:
 
When features of a language become outdated due to technology advances,
or unnecessary due to the addition of better features, should the old
features be deprecated from the language, or deleted outright?
 
Since there has never been a Common Lisp standard before, deprecation
is against a de-facto standard, which may or may not be appropriate.
Deletion, on the other hand, is cleaner, but may generate never-ending
discussion when the standard goes for public review (and even in the
X3J13 meeting).
 
Proposal (DEPRECATION-POSITION:LIMITED)
 
Since Common Lisp has been used industrially, it is reasonable to 
assume that any deletion by the X3J13 committee will be a cause for
at least some controversy. Therefore, this proposal suggests that
X3J13 deprecate (versus delete) a very small set of functions. 
The members of that set will be determined on a case-by-case basis by 
the X3J13 committee.
 
Rationale:
 
The standard should contain information about deprecation since
the topic has been mentioned more than once in X3J13, and since
Common Lisp is such a large language.

It's not
unreasonable for a language the size of Lisp to get rid of the
never-used tools, but we don't want to generate years of discussion
over a relatively minor issue when the standard goes for public review.
 
Current Practice:
 
Fortran successfully deprecated one constant. However, a proposal 
submitted during its latest standardization effort that 
suggested deleting old features in favor of new ones was
opposed vehemently. The Pascal committee is currently opposed
to deprecation, and the SPARC proposal suggests that 
deprecation should be dictated by the marketplace.
 
 
Adoption Cost:
 
None.
 
Benefits:
 
This policy will provide a basis for future X3J13 decisions.
 
Conversion Cost:
 
None.
 
Aesthetics:
 
None.
 
Discussion:
 
Comment:
"I personally would argue for not including "deprecated" features in
the standard at all, because including them now will make it harder to
remove them later.  My perception is that ANSI Common Lisp is turning
out to be a much different language than what is described in CLtL,
particularly if CLOS becomes a required part of the language.  If,
with the benefit of hindsight and experience, we now realize that some
"features" described in CLtL were really "bugs", the time to remove
them is *before* they become cast in stone as part of ANSI Common
Lisp.  I suspect that most implementors will continue to provide these
features as extensions anyway, as long as a substantial number of
their customers are still using them."

Response:
Perhaps most implementors will continue to provide the deleted features,
but they will do that also if they are deprecated. Since the only real
difference between the two is the amount of discussion one will generate
over the other (I think that worrying about future difficulty of getting
rid of the features is not a "real" difference yet), it seems that choosing
the route of least resistance in this case is the wisest course.
 

∂20-Dec-88  1427	CL-Editorial-mailer 	Issue: CUT-OFF-DATES    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Dec 88  14:27:31 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA10458; Tue, 20 Dec 88 14:26:33 PST
Message-Id: <8812202226.AA10458@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Dec 88 16:18
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: CUT-OFF-DATES

Issue:        CUT-OFF-DATES
References:   Working draft of the standard
Category:     Policy
Edit history: 20-DEC-88, Version 1 by Chapman
 
 
Problem Description:

The X3J13 committee has informally agreed that a 12/89 standard is 
a doable goal. However, the standard has to be reviewed by a large
number of people outside the X3J13 committee. We must allow plenty 
of time for these reviews, and should therefore plan our internal
reviews and "document freeze" accordingly.

Proposal (CUT-OFF-DATES:ESTABLISH)
 
Item						Cut-off date for changes
________________________________________________(First day of the month)____
Format of tool descriptions				11/88
Meaning of each item in each tool description           11/88
Fonts                                                   2/89
Changes to existing functions                           4/89
Additional functions                                    4/89
Compliance                                              2/89
Error terms						2/89
Contents of Chapter 6 tool descriptions:
 - Syntax section                                       2/89
 - Arguments section                                    5/89
 - Values section                                       5/89
 - Description section                                  5/89
 - Examples section                                     2/89
 - Side Effects section                                 3/89
 - Affected By section                                  3/89
 - Conditions section                                   4/89
 - See Also section                                     2/89
 - Notes section                                        5/89
Changes to TOC						2/89
Contents of sections:                                   4/89
 - 1.1                                                  4/89
 - 1.2                                                  4/89
 - 1.3                                                  4/89
 - 1.4                                                  4/89
 - 1.5                                                  4/89
 - 1.6                                                  4/89
 - 1.7                                                  4/89
 - 1.8                                                  4/89
 - 2.1                                                  5/89
 - 2.2                                                  5/89
 - 2.3                                                  5/89
 - 2.4                                                  5/89
 - 2.5                                                  5/89
 - 3.1                                                  5/89
 - 3.2                                                  5/89
 - 4.1                                                  6/89
 - 4.2                                                  6/89
 - 5.1                                                  6/89
 - 5.2                                                  6/89
 - 5.3                                                  6/89
 - 5.4                                                  6/89
 
The way this breaks down is as follows:

Things that have already frozen: format of Chapter 6 tool descriptions,
Meaning of each tool description category.

Things that will be frozen after the 1/88 meeting: fonts, compliance,
error terms, syntax section, examples section, see also section,
side effects section, affected by section, table of contents, and
this schedule of cut-off dates.

Things that will be frozen after the 3/88 meeting:
Contents of Chapters 1, 2, and 3, New issues that change existing functions
or add new functions, values section, arguments section, description
section, notes section, and conditions section.

Things that will be frozen by 6/1/89:
Chapters 4 and 5.

All comments received according to this schedule will be incorporated
by 6/30/89. Any comments received after the dates listed above will 
only be considered if they are of an extreme nature, if they impact
the correctness of the document. Otherwise the comments will be filed
and reserved for the next standard.

Rationale:

In order to complete this standard and move on to the next version,
we need to establish dates after which changes will not be allowed.
 
Current Practice:
None.

Adoption Cost:
 
None.
 
Benefits:

Establishing cut-off dates will encourage reviewers to complete
a thorough review in a timely manner.
 
Conversion Cost:

None. 

Aesthetics:
 
None.
 
Discussion:
 

∂23-Dec-88  1235	CL-Editorial-mailer 	Error terminology  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Dec 88  12:35:45 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 511979; Fri 23-Dec-88 14:23:49 EST
Date: Fri, 23 Dec 88 14:23 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Error terminology
To: jonl@lucid.com, chapman%aitg.DEC@decwrl.dec.com
cc: CL-Editorial@SAIL.Stanford.EDU
In-Reply-To: <8812220606.AA10159@bhopal>
Message-ID: <881223142335.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Wed, 21 Dec 88 22:06:00 PST
    From: Jon L White <jonl@lucid.com>

    re:       -  THE "CONSEQUENCES ARE UNSPECIFIED"
		   means that
		   . . . 
	       - ... and all portable programs are required to treat
		  the situation as unpredictable but harmless.

    It looks like to me that "harmless" has the same lack of specificity
    as Barry's word "benign".  Taken in context of the rest of your message,
    it could only mean "not fatal".  Is that good enough?

I think all of these terms are equally useless. I cited to Kathy privately
an example like
 (IF (EQUAL (UNSPECIFIED-BUT-HARMLESS) (UNSPECIFIED-BUT-HARMLESS))
     (LAUNCH-MISSILE))
which has potential effects that are far from harmless.

One may wish to talk about the first order or direct effects (if they define
such terms).

One may also wish to make specific statements about things that will not
happen. eg, we might want to say that the integrity of the machine's
store (i.e., stack, heap, etc.) will not be disrupted wholesale
[although this is weak because some of these things may set individual
variables or modify individual conses, so whether it's harmless depends
on whether you were depending on those specific variables, etc. being
constant], the flow of control will not be modified [although this is
misleading because if any consing is permitted (for example), then it
has to be permissible to enter the debugger due to out-of-storage and
then it has to be permissible that you never get to the statement
following and so on.

Probably the description should be done by admitting that the difference is
subjective and indicating that the intent is that "UNDEFINED" really means
that awful first-order effects can occur, citing examples like "halt the
running lisp (and/or the machine in cases where that's the same thing)",
"leave the file system in an inconsistent state", etc. More commonly "undefined"
might mean "directly enters the debugger" or "accidentally violates the
integrity of a user data structure" or some such more contained thing, but
it isn't limited in scope to such effects.

By contrast, then, "unspecified" can be said to potentially lead to bad
effects since subsequent control flow may depend on the unspecified data
flow. Further, "unspecified" does not mean "unconditional debugger
entry", but since the debugger might be entered at any time due to an
exceptional situation, debugger entry is not ruled out (any more than it
would be for most other functions). Specifically, "unspecified" means that
the "normal situation" is that the debugger is not entered.

I didn't work hard on the wording of the above -- it's mostly just food for
thought. Hopefully something along those lines would be enough to suffice,
though.

    [By the bye, was this msg really intended for x3j13 distribution? or 
     should it have been cl-editorial?]

[Removed X3J13; Added CL-Editorial.]

∂28-Dec-88  0630	CL-Editorial-mailer 	please respond if you receive this message  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 28 Dec 88  06:30:31 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA09351; Wed, 28 Dec 88 06:29:31 PST
Message-Id: <8812281429.AA09351@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 28 Dec 88 09:29
To: cl-editorial@sail.stanford.edu
Subject: please respond if you receive this message


∂28-Dec-88  0927	CL-Editorial-mailer 	please respond if you receive this message  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 28 Dec 88  09:27:25 PST
Received: from fafnir.think.com by Think.COM; Wed, 28 Dec 88 12:19:28 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 28 Dec 88 12:25:00 EST
Received: by verdi.think.com; Wed, 28 Dec 88 12:23:23 EST
Date: Wed, 28 Dec 88 12:23:23 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8812281723.AA07756@verdi.think.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 28 Dec 88 09:29 <8812281429.AA09351@decwrl.dec.com>
Subject: please respond if you receive this message

   From: chapman%aitg.DEC@decwrl.dec.com
   Date: 28 Dec 88 09:29



Snurf.

∂29-Dec-88  0546	CL-Editorial-mailer 	Re: please respond if you receive this message   
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 29 Dec 88  05:46:39 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa12600; 29 Dec 88 8:31 EST
Received: from utokyo-relay by RELAY.CS.NET id aa19326; 29 Dec 88 8:23 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
	id AA00793; Thu, 29 Dec 88 21:58:23 JST
Date: Thu, 29 Dec 88 21:18:19 JST
From: Masayuki Ida <ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@cc.aoyama.junet>
Message-Id: <8812291218.AA20247@kepa.cc.aoyama.junet>
To: chapman%aitg.DEC@DECWRL.DEC.COM, cl-editorial@SAIL.STANFORD.EDU
Subject: Re: please respond if you receive this message


>From: chapman%aitg.DEC@decwrl.dec.com
>Date: 28 Dec 88 09:29
>To: cl-editorial@sail.stanford.edu
>Subject: please respond if you receive this message
>
>

Hi, I am here.



∂30-Dec-88  0125	CL-Editorial-mailer 	[cperdue@Sun.COM: Re:  Error terminology]   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Dec 88  01:25:49 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01486g; Fri, 30 Dec 88 01:22:22 PST
Received: by bhopal id AA13467g; Fri, 30 Dec 88 01:24:32 PST
Date: Fri, 30 Dec 88 01:24:32 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812300924.AA13467@bhopal>
To: cl-editorial@sail.stanford.edu
Subject: [cperdue@Sun.COM: Re:  Error terminology]

Date: Thu, 29 Dec 88 12:47:18 PST
From: cperdue@Sun.COM (Cris Perdue)
To: chapman%aitg.DEC@decwrl.dec.com, jonl@lucid.com
Subject: Re:  Error terminology

> re:       -  THE "CONSEQUENCES ARE UNSPECIFIED"
>                means that
>                . . . 
>            - ... and all portable programs are required to treat
>               the situation as unpredictable but harmless.
> 
> It looks like to me that "harmless" has the same lack of specificity
> as Barry's word "benign".  Taken in context of the rest of your message,
> it could only mean "not fatal".  Is that good enough?

As I have noted previously, I have been concerned about this
phrase also.  My concern is that it makes sense for a form
or function to return an unpredictable value, but I don't
think that it makes sense to talk about "unpredictable but
harmless" side effects.  It makes sense to specify that certain
kinds of side effects may or may not occur, but there must be
a definite constraint on what side effects are permitted.

∂30-Dec-88  0829	CL-Editorial-mailer 	[cperdue@Sun.COM: Re:  Error terminology]   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 30 Dec 88  08:28:51 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 30 Dec 88 11:17:30 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 30 Dec 88 11:26:43 EST
Date: Fri, 30 Dec 88 11:26 EST
From: Barry Margolin <barmar@Think.COM>
Subject: [cperdue@Sun.COM: Re:  Error terminology]
To: Jon L White <jonl@lucid.com>
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <8812300924.AA13467@bhopal>
Message-Id: <19881230162644.8.BARMAR@OCCAM.THINK.COM>

    Date: Fri, 30 Dec 88 01:24:32 PST
    From: Jon L White <jonl@lucid.com>

    Date: Thu, 29 Dec 88 12:47:18 PST
    From: cperdue@Sun.COM (Cris Perdue)
    To: chapman%aitg.DEC@decwrl.dec.com, jonl@lucid.com
    Subject: Re:  Error terminology

    > re:       -  THE "CONSEQUENCES ARE UNSPECIFIED"
    >                means that
    >                . . . 
    >            - ... and all portable programs are required to treat
    >               the situation as unpredictable but harmless.
    > 
    > It looks like to me that "harmless" has the same lack of specificity
    > as Barry's word "benign".  Taken in context of the rest of your message,
    > it could only mean "not fatal".  Is that good enough?

    As I have noted previously, I have been concerned about this
    phrase also.  My concern is that it makes sense for a form
    or function to return an unpredictable value, but I don't
    think that it makes sense to talk about "unpredictable but
    harmless" side effects.  It makes sense to specify that certain
    kinds of side effects may or may not occur, but there must be
    a definite constraint on what side effects are permitted.

I've been thinking about this a little.  One thought I had about this
was that it means that the result in an "unspecified" situation is
equivalent to some unspecified *but valid* CL program.  A "valid
program" is one that does not do anything whose consequences are
undefined.

But I'm not sure that this is really a useful definition, either.  For
instance, it allows any variable to be set to any value that satisfies
its type declaration.  But I don't know how to constrain it further,
since many unspecified situations will want to have some side effects.
I think that further constraints on any particular unspecified situation
would have to be provided in the description of that situation.

DEFPACKAGE is a good example of this.  The description of the effect of
executing a DEFPACKAGE for an existing package says "at most, the
existing package will be modified to reflect the new definition".  This
constrains the effect of this situation.

I think that anything beyond this simple definition of "unspecified" is
impossible.  It's just supposed to convey the difference between this
class of situations and things like RPLACAing a non-cons.  An
unspecified situation won't affect the integrity of the Lisp runtime
system, but an undefined situation may.  But I don't think the standard
can generalize it to specify that it won't affect the integrity of the
application program, since an application program can depend on too much
(for example, an application program might depend on the setting of
*READ-BASE* for its proper functioning, but the standard implies that
changing *READ-BASE* is OK).

                                                barmar

∂30-Dec-88  1347	CL-Editorial-mailer 	Unpredictable but Harmless   
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


Since I invented this phrase, maybe I should comment on it.

The exact context of the phrase is as follows:

           -  No portable program can depend on the consequences of this
              situation, and all portable programs are required to treat
              the situation as unpredictable but harmless.

Let's leave the intent aside for a moment. The problem with using very
specific terms like ``the integrity of the machine's store will not be
disrupted wholesale'' is that the degree of specificity implies that the
small range of effects cited is the full range. Also, such specific terms
tend to imply certain implementation technology or at least implementation
vocabulary.  In many areas when you try to precisely define a boundary
condition, you find that you are more confused rather than less.  The
beauty of a phrase like the one I suggested is that it gives the right
idea to people who approach it objectively and is also subject to common
sense interpretation in a wide range of implementations.

The intent is well expressed, I think. Since no portable programs can
depend on the consequences, such examples as the following are not
good portable programs:

 (IF (EQUAL (UNSPECIFIED-BUT-HARMLESS) (UNSPECIFIED-BUT-HARMLESS))
     (LAUNCH-MISSILE))

Since all portable programs are required to treat such situations as
unpredictable but harmless a reasonable program will not depend on the results,
nor will prudent programmers be required to test for the situation to avoid
disaster. There might be side effects, but they will be harmless, which means
they might alter some state, but again prudent programmers will not need to
worry about these side effects.

I think the wording clearly implies that programs whose behavior does not
depend on the consequences of the unspecified behavior will be fine. Saying
any more about it muddles the explanation, and saying any less probably results
in anarchy.

One reason to use the term ``harmless'' rather than ``not fatal'' is that
some side effects like printing are not fatal but are harmful. That is,
the intent is that programmers need not worry about guarding against the
situation. You would have to guard against output going into a file
by accident, though the result would not be fatal. Additional CONSing
causing a GC that prints is an effect that the programmer must already guard
against, and there is a mechanism to direct this output elsewhere.

I feel that I would have to hear much more compelling arguments to change my
mind on this, but I am open to listening to proposed arguments.

			-rpg-

∂01-Jan-89  2011	CL-Editorial-mailer 	[cperdue@Sun.COM: Re:  Error terminology]   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Jan 89  20:09:42 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02532g; Sun, 1 Jan 89 20:06:03 PST
Received: by bhopal id AA21277g; Sun, 1 Jan 89 20:08:11 PST
Date: Sun, 1 Jan 89 20:08:11 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901020408.AA21277@bhopal>
To: barmar@Think.COM
Cc: cl-editorial@sail.stanford.edu, jonl@lucid.com
In-Reply-To: Barry Margolin's message of Fri, 30 Dec 88 11:26 EST <19881230162644.8.BARMAR@OCCAM.THINK.COM>
Subject: [cperdue@Sun.COM: Re:  Error terminology]

re: since many unspecified situations will want to have some side effects.
    I think that further constraints on any particular unspecified situation
    would have to be provided in the description of that situation.
    . . . 
    DEFPACKAGE is a good example of this.  The description of the effect of
    executing a DEFPACKAGE for an existing package says "at most, the
    existing package will be modified to reflect the new definition".  This
    constrains the effect of this situation.

Discussion after the release of the DEFPACKAGE issue made it clear that
the phrase "at most" simply means "does not alter the name-to-package 
mapping".  This was particularly releveant in the DEFPACKAGE issue since 
most definers *only* alter name-to-object mappings, to point to a newly-
created object [but some CLOS definers also don't alter the mappings].  
This point was, unfortunately, the only one on which we could get some 
kind of consensus now; I think we all want a specification  for package 
redefinition (since it will occur frequently during debugging) but just 
didn't get agreement on it in time.


-- JonL --

∂03-Jan-89  0856	CL-Editorial-mailer 	Please review and comment ASAP    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  08:56:07 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA11628; Tue, 3 Jan 89 08:54:42 PST
Message-Id: <8901031654.AA11628@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Jan 89 10:53
To: @mydis@decwrl.dec.com
Subject: Please review and comment ASAP

Issue:        CONFORMANCE-POSITION
References:   Chapter 1, Section 1.5, Working draft of standard
Category:     Clarification
Related Issue:EXTENSIONS-POSITION
Edit history: 12-DEC-88, Version 1 by Chapman
              20-DEC-88, Version 2 by Chapman 
 
Problem Description:
 
Two ways of defining conformance are in terms of a conforming program
and in terms of a conforming implementation. How should our standard
define conformance?
 
 
Proposal (CONFORMANCE-POSITION:PROGRAM)
 
For our standard, conformance should be defined in terms
of a conforming program, and perhaps conforming documentation.
Of course, within the standard itself certain requirements will be
levied on the implementation. However, the bottom line should not
be that the implementation conforms to the letter of the standard,
but that a program written to the letter of the standard will run
in all "conforming" implementations (defined as ones that run conforming
programs).
 
 
Rationale:
 
The standard must contain information about conformance. Including 
requirements which would be placed on implementations, however, leaves
the possiblity open that something would be overlooked, and so 
implementations may well conform without processing correctly
conforming programs.
 
Current Practice:

CLtL generally describes things in terms of what a correct program can
expect.
 
I think dpANS C is also in terms of programs.  They have further defined
both "conforming" and "strictly conforming" programs; I think the
difference has something to do with how the program deals with features
that the standard says are implementation-defined.
 
Pascal defines 
conformance in terms of both, PL/I defines conformance in terms of 
conforming programs only.
Fortran and Ada say that a conforming implementation correctly processes
conforming programs. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both programs and implementations.
 
Adoption Cost:
 
None.
 
Benefits:
 
This definition will give readers and validators a basis on which to read
the standard.
 
Conversion Cost:
 
None.
 
Aesthetics:
 
None.
 
Discussion:

∂03-Jan-89  0859	CL-Editorial-mailer 	Please review and comment ASAP    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  08:59:30 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA11927; Tue, 3 Jan 89 08:58:08 PST
Message-Id: <8901031658.AA11927@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Jan 89 10:56
To: @mydis@decwrl.dec.com
Subject: Please review and comment ASAP

Issue:        SUBSETTING-POSITION
References:   X3J13 committee and sub-committee meetings
Category:     Policy
Edit history: 12-DEC-88, Version 1 by Chapman
 
 
Problem Description:
 
Should the CL standard be partitioned such that an implementation
could chose a subset of all the CL facilities to implement and 
still be a conforming implementation?
 
Proposal (SUBSETTING-POSITION:TWO-LEVELS)
 
For our standard, we should subset only if there's a chance
we could achieve international agreement on the standard by doing so.
If we do subset, there should be two levels: the full
language without whatever we can't agree on internationally,
and the full language. 
 
 
Rationale:
 
 
Current Practice:
 
Pascal has two levels of conforming implementations -- level 1 contains
level 0 and conformant arrays. This was a compromise necessary to achieve
international agreement. The 1981 PL/I was subsetted and the 
results were a range of implementations between the
subset and the full language; nobody wanted to use the subset so vendors
were forced to implement the full language eventually anyway.
Cobol had multiple levels of subsets. However, 
the only two levels that were important were the minimum 
subset and the full language. The middle levels were
seldom used other than transient points to the full language.
Fortran was subsetted. It was felt that subsetting encouraged
vendors to implement Fortran and therefore proliferate its usage,
but users were quite annoyed that one Fortran was considerably
different from another. 
The new Fortran language standards committee is
banning subsetting.
SPARC feels that 
subsets aren't good for facilitating interchange, but serve the
purpose of allowing
timely implementation of the standard.
 
A suggestion that was made by most language committee representatives
was to group subsetted parts meaningfully, and to minimize the number
of levels.
 
Adoption Cost:
 
None.
 
Benefits:
 
This policy will provide a basis for making decisions in X3J13.
 
Conversion Cost:
 
None.
 
Aesthetics:
 
None.
 
Discussion:

∂03-Jan-89  0901	CL-Editorial-mailer 	Please review and comment ASAP    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  09:01:39 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA12058; Tue, 3 Jan 89 09:00:18 PST
Message-Id: <8901031700.AA12058@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Jan 89 10:57
To: @mydis@decwrl.dec.com
Subject: Please review and comment ASAP

Issue:        CUT-OFF-DATES
References:   Working draft of the standard
Category:     Policy
Edit history: 20-DEC-88, Version 1 by Chapman
 
 
Problem Description:

The X3J13 committee has informally agreed that a 12/89 standard is 
a doable goal. However, the standard has to be reviewed by a large
number of people outside the X3J13 committee. We must allow plenty 
of time for these reviews, and should therefore plan our internal
reviews and "document freeze" accordingly.

Proposal (CUT-OFF-DATES:ESTABLISH)
 
Item						Cut-off date for changes
________________________________________________(First day of the month)____
Format of tool descriptions				11/88
Meaning of each item in each tool description           11/88
Fonts                                                   2/89
Changes to existing functions                           4/89
Additional functions                                    4/89
Compliance                                              2/89
Error terms						2/89
Contents of Chapter 6 tool descriptions:
 - Syntax section                                       2/89
 - Arguments section                                    5/89
 - Values section                                       5/89
 - Description section                                  5/89
 - Examples section                                     2/89
 - Side Effects section                                 3/89
 - Affected By section                                  3/89
 - Conditions section                                   4/89
 - See Also section                                     2/89
 - Notes section                                        5/89
Changes to TOC						2/89
Contents of sections:                                   4/89
 - 1.1                                                  4/89
 - 1.2                                                  4/89
 - 1.3                                                  4/89
 - 1.4                                                  4/89
 - 1.5                                                  4/89
 - 1.6                                                  4/89
 - 1.7                                                  4/89
 - 1.8                                                  4/89
 - 2.1                                                  5/89
 - 2.2                                                  5/89
 - 2.3                                                  5/89
 - 2.4                                                  5/89
 - 2.5                                                  5/89
 - 3.1                                                  5/89
 - 3.2                                                  5/89
 - 4.1                                                  6/89
 - 4.2                                                  6/89
 - 5.1                                                  6/89
 - 5.2                                                  6/89
 - 5.3                                                  6/89
 - 5.4                                                  6/89
 
The way this breaks down is as follows:

Things that have already frozen: format of Chapter 6 tool descriptions,
Meaning of each tool description category.

Things that will be frozen after the 1/88 meeting: fonts, compliance,
error terms, syntax section, examples section, see also section,
side effects section, affected by section, table of contents, and
this schedule of cut-off dates.

Things that will be frozen after the 3/88 meeting:
Contents of Chapters 1, 2, and 3, New issues that change existing functions
or add new functions, values section, arguments section, description
section, notes section, and conditions section.

Things that will be frozen by 6/1/89:
Chapters 4 and 5.

All comments received according to this schedule will be incorporated
by 6/30/89. Any comments received after the dates listed above will 
only be considered if they are of an extreme nature, if they impact
the correctness of the document. Otherwise the comments will be filed
and reserved for the next standard.

Rationale:

In order to complete this standard and move on to the next version,
we need to establish dates after which changes will not be allowed.
 
Current Practice:
None.

Adoption Cost:
 
None.
 
Benefits:

Establishing cut-off dates will encourage reviewers to complete
a thorough review in a timely manner.
 
Conversion Cost:

None. 

Aesthetics:
 
None.
 
Discussion:
 

∂03-Jan-89  0927	CL-Editorial-mailer 	Please review and comment ASAP    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  09:27:03 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA13865; Tue, 3 Jan 89 09:25:39 PST
Message-Id: <8901031725.AA13865@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Jan 89 10:54
To: @mydis@decwrl.dec.com
Subject: Please review and comment ASAP

Issue:        EXTENSIONS-POSITION
References:   Chapter 1, Working draft of standard
Category:     Clarification
Related Issue:CONFORMANCE-POSITION
Edit history: 12-DEC-88, Version 1 by Chapman
              20-DEC-88, Version 2 by Chapman
 
Problem Description:
 
What is the definition of a language extension?
What effect does a language extension have on a conforming program? 
What obligation does an implementation have to warn the user that an 
extension is being used?
 
Proposal (EXTENSIONS-POSITION:DOCUMENTATION)
 
The standard document should define a language extension to be
any implementation-supplied tool that isn't explicitly defined
in the standard. This includes facilities added to tools defined
in the standard.
The standard document should levy the following requirement on a 
conforming implementation's documentation:
The documentation that accompanies a conforming implementation should clearly
state which parts of the implementation are extensions.  

Rationale:
 
The standard should contain information about language extensions
since most implementations have extended the language.
 
Current Practice:

CLtL allows any extension, provided that it doesn't alter the behavior
of a program that only uses what is specified in CLtL.  In particular,
any situation that "is an error" (either explicitly or implicitly) is a
potential area for extension.
 
 
Adoption Cost:
 
Vendors will have to improve their documentation
to list all their extensions.  Vendors will have to go through their
implementation and determine what is or isn't an extension.
 
 
Benefits:
 
This definition will provide a basis for proper understanding of 
the error terminology used in the standard. The implementation
documentation requirement will aid the user in producing portable code.
 
Conversion Cost:
 
None.
 
Aesthetics:
 
None.
 
Discussion:
 
Comments:
"The most commonly proposed solution to this kind of problem is to
require the implementation to have a way to disable its extensions, so
that a programmer can be told when he is using a feature that might
affect his program's portability.  Whether this should be the default
mode is up for debate; I think most other standards that do this don't
require it to be the default."

Response:
Requiring an implementation to be able to disable extensions seems like
a more costly alternative than requiring an implementation to document
its extensions as extensions if it is to be conforming, since presumably
an implementation will document user-visible extension anyway.

∂03-Jan-89  0957	CL-Editorial-mailer 	Please review and comment ASAP    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  09:57:05 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA16102; Tue, 3 Jan 89 09:55:41 PST
Message-Id: <8901031755.AA16102@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Jan 89 10:55
To: @mydis@decwrl.dec.com
Subject: Please review and comment ASAP

Issue:        DEPRECATION-POSITION
References:   X3J13 committee and sub-committee meetings
Category:     Policy
Edit history: 12-DEC-88, Version 1 by Chapman
              20-DEC-88, Version 2 by Chapman
 
Problem Description:
 
When features of a language become outdated due to technology advances,
or unnecessary due to the addition of better features, should the old
features be deprecated from the language, or deleted outright?
 
Since there has never been a Common Lisp standard before, deprecation
is against a de-facto standard, which may or may not be appropriate.
Deletion, on the other hand, is cleaner, but may generate never-ending
discussion when the standard goes for public review (and even in the
X3J13 meeting).
 
Proposal (DEPRECATION-POSITION:LIMITED)
 
Since Common Lisp has been used industrially, it is reasonable to 
assume that any deletion by the X3J13 committee will be a cause for
at least some controversy. Therefore, this proposal suggests that
X3J13 deprecate (versus delete) a very small set of functions. 
The members of that set will be determined on a case-by-case basis by 
the X3J13 committee.
 
Rationale:
 
The standard should contain information about deprecation since
the topic has been mentioned more than once in X3J13, and since
Common Lisp is such a large language.

It's not
unreasonable for a language the size of Lisp to get rid of the
never-used tools, but we don't want to generate years of discussion
over a relatively minor issue when the standard goes for public review.
 
Current Practice:
 
Fortran successfully deprecated one constant. However, a proposal 
submitted during its latest standardization effort that 
suggested deleting old features in favor of new ones was
opposed vehemently. The Pascal committee is currently opposed
to deprecation, and the SPARC proposal suggests that 
deprecation should be dictated by the marketplace.
 
 
Adoption Cost:
 
None.
 
Benefits:
 
This policy will provide a basis for future X3J13 decisions.
 
Conversion Cost:
 
None.
 
Aesthetics:
 
None.
 
Discussion:
 
Comment:
"I personally would argue for not including "deprecated" features in
the standard at all, because including them now will make it harder to
remove them later.  My perception is that ANSI Common Lisp is turning
out to be a much different language than what is described in CLtL,
particularly if CLOS becomes a required part of the language.  If,
with the benefit of hindsight and experience, we now realize that some
"features" described in CLtL were really "bugs", the time to remove
them is *before* they become cast in stone as part of ANSI Common
Lisp.  I suspect that most implementors will continue to provide these
features as extensions anyway, as long as a substantial number of
their customers are still using them."

Response:
Perhaps most implementors will continue to provide the deleted features,
but they will do that also if they are deprecated. Since the only real
difference between the two is the amount of discussion one will generate
over the other (I think that worrying about future difficulty of getting
rid of the features is not a "real" difference yet), it seems that choosing
the route of least resistance in this case is the wisest course.
 

∂03-Jan-89  1435	CL-Editorial-mailer 	info about issues in a 2-part message  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  14:35:33 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA05703; Tue, 3 Jan 89 14:34:06 PST
Message-Id: <8901032234.AA05703@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 3 Jan 89 17:31
To: @mydis@decwrl.dec.com
Subject: info about issues in a 2-part message

This is part 1 of a two part message. It was too long to send as
one message. This goes with the information I mailed you before
Christmas about your tools that have been modified by the X3J13
issues.
 
Now that you have identified the list of your tools that were modified, 
following is a list of the tools which have examples that include the
tools that were changed by the issues. Please check that examples that
contain tools for which you are responsible to make sure the application
of the issue to the tool hasn't invalidated the example in any way.
 
To do this, you will need to do the following:
 
1. Understand your changed tool.
2. Understand the issue or issues that changed it.
To do this it may help if you have a copy of the tool description
now that it has been changed. The easiest way to get these individual
files is via FTP, although I can mail them to you if necessary.
The next message you get (if you get these in order!) will be a list
of file names that are associated with each tool. If you want me to mail
you a copy of your tool, please let me know. In the tool description
I have marked each change that is associated with an issue. I assume you
have copies of the approved issues, but if you don't let me know.
3. Find the examples that have your tool as part of them, and try them
out to make sure they work. You will need copies of the files that have
the examples you need. Again, let me know if you need them mailed to
you, or copy them via FTP.
4. Let me know what changes need to be made so I can make them.
 
The other possible way to do this is for you check the following list
and make sure the tools you are responsible for contain correct examples.
This could potentially require that you understand the implications of
more than just a few issues. If some of you think this is a better approach,
please let me know so I can redirect the rest of you.
 
Thanks for your help, and Merry Christmas!!!
kc
 
******************************
DUA1:[CHAPMAN.STANDARD]F028.ADJUST-ARRAY;21
 
 (adjust-array A ...)
 (adjust-array A ... :displaced-to C)
 (adjust-array A ... :displaced-to B)
 (adjust-array A ... :displaced-to C)
 (adjust-array A ... :displaced-to B)
 (adjust-array A ... :displaced-to nil)
  (setq ada (adjust-array
 (adjust-array beta '(4 6) :displaced-to ada) @EV 
 (adjust-array m '(3 5) :initial-element 'baz)
 
******************************
DUA1:[CHAPMAN.STANDARD]F033.APPEND;13
 
 (append '(a b c . d) '()) @EV (a b c)	
 (append '(a b . c) '() 3) @EV (a b . 3)	
 (append '() 17)  @EV 17	
 (append '(a b c) '(d e f) '() '(g)) @EV (A B C D E F G)
 (append '(a b c) 'd) @EV (A B C . D)
 (append lst '(d)) @EV (A B C D)
 (append) @EV NIL
 
******************************
DUA1:[CHAPMAN.STANDARD]F136.CERROR;11
 
	   (setq vals (append vals (subseq '(0 0 0) nvals 3))))
 
 
******************************
DUA1:[CHAPMAN.STANDARD]F283.FLET;15
 
          (setq l (append l (list x)))))
 
******************************
DUA1:[CHAPMAN.STANDARD]F313.GET-SETF-METHOD;15
 
                    (append vars stores)
                    (append vals (list value)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F414.MAP;10
 
 (mapc \#'(lambda (&rest x) (setq dummy (append dummy x)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F580.REVAPPEND;7
 
@f[(revappend @i[x] @i[y])] @EQ\ @f[(append (reverse @i[x]) @i[y])]\rm.
 
 
******************************
DUA1:[CHAPMAN.STANDARD]S1400.DEFINITIONS;23
 
(append '() '() @EV\ ()               ;Emphasize use of empty lists
 
******************************
DUA1:[CHAPMAN.STANDARD]S3100.CHARACTER-READER;48
 
 (append @lbracket\ x1@rbracket @lbracket\ x2@rbracket @lbracket\ x3@rbracket ... @lbracket\ xn@rbracket (quote atom))
 (append @lbracket\ x1@rbracket @lbracket\ x2@rbracket @lbracket\ x3@rbracket ... @lbracket\ xn@rbracket form)
 (append (list (append (list a) (list 'b) '@nil)) (list c) d '@nil)
 (append (list (append (list a) (list 'b))) (list c) d)
 (append (list (append (list a) '(b))) (list c) d)
 (append (list (cons a '(b))) (list c) d)
 
******************************
DUA1:[CHAPMAN.STANDARD]F055.ASSERT;12
 
(assert (valve-closed-p v1))
(assert (valve-closed-p v1) () "Live steam is escaping!")
(assert (valve-closed-p v1)
(assert (<= minbase base maxbase)
(assert (= (array-dimension a 1) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F602.SHADOW;9
 
 (assert (not (null (member 'test-1::test (package-shadowing-symbols
 
******************************
DUA1:[CHAPMAN.STANDARD]F803.ASSERT;9
 
     (assert (and (= (array-rank a) (array-rank b) 2)
 (defun assert-example (x) (assert (numberp x) (x)) (+ x x))
 (assert-example t)
Original code: (NAMED-LAMBDA ASSERT-EXAMPLE (X) (BLOCK ASSERT-EXAMPLE (ASSERT # #) (+ X X)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F024.ACONS;14
 
 (assoc 1 alist) @EV\ (1 . "one")
 (assoc 1 alist) @EV\ (1 . "uno")
 
******************************
DUA1:[CHAPMAN.STANDARD]F056.ASSOC;18
 
 (assoc 'y values) @EV (Y . 200)
 (rplacd (assoc 'y values) 201) @EV (Y . 201)
 (assoc 'y values) @EV (Y . 201)
 (assoc 2 alist) @EV (2 . "two")
 (assoc-if #'evenp alist) @EV (2 . "two")
 (assoc-if-not #'(lambda(x) (< x 3)) alist) @EV (3 . "three")
 (assoc "one" alist) @EV NIL
 (assoc "one" alist :test #'equalp) @EV ("one" . 1)
 (assoc "two" alist :key #'(lambda(x) (char x 2))) @EV NIL 
 (assoc \#@bsl\ o alist :key #'(lambda(x) (char x 2))) @EV ("two" . 2)
 (assoc 'r '((a . b) (c . d) (r . x) (s . y) (r . z))) @EV  (r . x)
 (assoc 'goo '((foo . bar) (zoo . goo))) @EV @false
 (assoc '2 '((1 a b c) (2 b c d) (-7 x y z))) @EV (2 b c d)
 (assoc-if #'zerop pathnames :key #'pathname-version)
 (assoc item list :test fn)
 
******************************
DUA1:[CHAPMAN.STANDARD]F188.COPY-ALIST;9
 
 (setf (cdr (assoc 2 calist)) "deux") @EV\ "deux"
 (setf (cdr (assoc 1 clist)) "uno") @EV\ "uno"
 
******************************
DUA1:[CHAPMAN.STANDARD]F240.ECASE;12
 
 (ccase k
 
******************************
DUA1:[CHAPMAN.STANDARD]F167.CHECK-TYPE;12
 
(check-type aardvarks (vector integer))
(check-type naards (integer 0 *) "a positive integer")
 
******************************
DUA1:[CHAPMAN.STANDARD]F342.LAST;8
 
   (check-type n (integer 0))
 
******************************
DUA1:[CHAPMAN.STANDARD]F810.CHECK-TYPE;8
 
 (check-type aardvarks (array * (3)))
 (check-type aardvark-count (integer 0 *) "a positive integer")
 (defun checker (a) (check-type a integer) (+ a a))
(CHECK-TYPE A INTEGER) (+ A A)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F836.STORE-VALUE;5
 
   (check-type symbol symbol)
Original code: (NAMED-LAMBDA SAFE-BUT-DESTRUCTIVE-SYMBOL-VALUE (SYMBOL) (BLOCK SAFE-BUT-DESTRUCTIVE-SYMBOL-VALUE (CHECK-TYPE SYMBOL SYMBOL) (RESTART-CASE # #) (SYMBOL-VALUE SYMBOL)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F840.USE-VALUE;5
 
   (check-type symbol symbol)
Original code: (NAMED-LAMBDA SAFE-SYMBOL-VALUE (SYMBOL) (BLOCK SAFE-SYMBOL-VALUE (CHECK-TYPE SYMBOL SYMBOL) (RESTART-CASE # #)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F196.COUNT;20
 
 (count \#@bsl\ a "how many A's are there in here?") @EV 2
 (count-if-not #'oddp '((1) (2) (3) (4)) :key #'car) @EV 2
 (count-if #'upper-case-p "The Crying of Lot 49" :start 4) @EV 2 
 
******************************
DUA1:[CHAPMAN.STANDARD]F209.DEFMACRO;21
 
          ((f1 (count-scales f1)) (f2 (count-scales f2)))
length1 & (count-scales f1) \cr
length2 & (count-scales f2) \cr
          ((f1) (f2 (count-scales f2)))
          ((f1 (count-scales f1)) (f2 (count-scales f2)))
          ((f1 (count-scales f1)) (f2 (count-scales f2)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F828.MUFFLE-WARNING;6
 
   (do ((counter x (1- counter)))
 (count-down 3)
     (count-down x)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F032.AND;11
 
 (decf temp3) @EV\ 1 
 (and (decf temp1) (decf temp2)  @EV\ (eq 'temp 'nil) (decf temp3)) NIL 
 
******************************
DUA1:[CHAPMAN.STANDARD]F327.INCF;12
 
 (decf (car a) 2) @EV 0
 (decf n 3) @EV -2   and now n @EV -2
 (decf n -5) @EV 3   and now n @EV 3
 (decf n) @EV 2      and now n @EV 2
 
******************************
DUA1:[CHAPMAN.STANDARD]F697.UNWIND-PROTECT;8
 
   (decf *access-count*))
 
******************************
DUA1:[CHAPMAN.STANDARD]S5200.INPUT-OUTPUT;14
 
\+&&{\tt (declare (ignore char))} \cr
\+&&{\tt (declare (ignore char))} \cr
 
******************************
DUA1:[CHAPMAN.STANDARD]F202.DECLARE;27
 
   (declare (type float x)) ...
 (defun foo (x y) (declare (notinline floor)) ...)
   (declare (special *mod*))  ; *mod* is visible to hack1,
   (declare (special *mod*))  ;Declare references to *mod*
 (declare (ftype (function (integer list) t) nth)
 (declare (function nth (integer list) t)
   (declare (optimize (safety 2)))
     (declare (optimize speed))
     (declare (fixnum i))
    (declare (special y))
            (locally (declare (special y)) y)))) ;this y refers to the
 (declare-eg nil) @EV (T NIL) 
   (declare (special @var[print-circle]))
     (declare (inline foo) (special x z))
 
******************************
DUA1:[CHAPMAN.STANDARD]F209.DEFMACRO;21
 
   (declare (ignore environment))
 
******************************
DUA1:[CHAPMAN.STANDARD]F214.DEFUN;12
 
  (declare (number a b c))
 
******************************
DUA1:[CHAPMAN.STANDARD]F255.EVAL-WHEN;14
 
			       (declare (ignore char))
 
******************************
DUA1:[CHAPMAN.STANDARD]F283.FLET;15
 
   (declare (integer n))         
   (declare (type (integer 0 *) k))
            (declare (integer x a) (type (integer 0 *) k))
            (declare (integer x a) (type (integer 0 *) k))
     (declare (inline attach))
 
******************************
DUA1:[CHAPMAN.STANDARD]F313.GET-SETF-METHOD;15
 
     (declare (ignore access-form))
 
******************************
DUA1:[CHAPMAN.STANDARD]F356.LET-LETSTAR;13
 
    (declare (special a))
   (declare (integer x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F366.LOCALLY;10
 
   (declare (special y))                                
           (locally (declare (special y)) y)))) ;this y refers to the
 (declare-eg nil) @EV\ (T NIL) 
 (locally (declare (inline floor) (notinline car cdr))
 	 (declare (optimize space))
 
******************************
DUA1:[CHAPMAN.STANDARD]F527.PROCLAIM;12
 
 (defun foo (x y) (declare (notinline floor)) ...)
   (declare (author "Harry Tweeker"))
   (declare (special y))
     (print (+ y (locally (declare (special y)) y)))
     (let ((y 4)) (declare (special y)) (foo x))))
 
******************************
DUA1:[CHAPMAN.STANDARD]F550.READ;13
 
   (declare (ignore char))
 
******************************
DUA1:[CHAPMAN.STANDARD]F556.READ-DELIMITED-LIST;12
 
   (declare (ignore char arg))
 
******************************
DUA1:[CHAPMAN.STANDARD]F595.SET-DISPATCH-MACRO-CHARACTER;14
 
   (declare (ignore subchar arg))
 
******************************
DUA1:[CHAPMAN.STANDARD]F597.SET-MACRO-CHARACTER;10
 
   (declare (ignore char))
   (declare (ignore char))
 
******************************
DUA1:[CHAPMAN.STANDARD]F678.THE;8
 
    (declare (fixnum i))
 
******************************
DUA1:[CHAPMAN.STANDARD]F815.DEFINE-CONDITION;6
 
  (declare (ignore condition))
 
******************************
DUA1:[CHAPMAN.STANDARD]F822.HANDLER-CASE;6
 
(type (var) (declare (ignore var)) form)
            (declare (ignore symbol))
 
******************************
DUA1:[CHAPMAN.STANDARD]F187.CONSTANTP;9
 
 (defconstant this-is-a-constant 'never-changing) @EV THIS-IS-A-CONSTANT 
 
******************************
DUA1:[CHAPMAN.STANDARD]F206.DEFCONSTANT;13
 
 (defconstant this-is-a-constant 'never-changing "for a test") @EV THIS-IS-A-CONSTANT
 
******************************
DUA1:[CHAPMAN.STANDARD]F207.DEFINE-MODIFY-MACRO;16
 
 (define-modify-macro appendf (&rest args) 
 (define-modify-macro incf (&optional (delta 1)) +)
 (define-modify-macro unionf (other-set &rest keywords) union)
 
******************************
DUA1:[CHAPMAN.STANDARD]F208.DEFINE-SETF-METHOD;17
 
 (define-setf-method lastguy (x)
 (define-setf-method ldb (bytespec int)
 
******************************
DUA1:[CHAPMAN.STANDARD]F313.GET-SETF-METHOD;15
 
 (define-setf-method multivalue (x)
 
******************************
DUA1:[CHAPMAN.STANDARD]S5100.ERRORS;39
 
 (defmacro without-arithmetic-errors (&body forms)
 
******************************
DUA1:[CHAPMAN.STANDARD]S5400.GENERALIZED-REFERENCE;19
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F179.COMPILER-LET;12
 
 (defmacro with-collecting (&body body)
 
******************************
DUA1:[CHAPMAN.STANDARD]F207.DEFINE-MODIFY-MACRO;16
 
 (defmacro name (reference . lambda-list)
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F208.DEFINE-SETF-METHOD;17
 
 (defmacro xpop (place &environment env)
 
******************************
DUA1:[CHAPMAN.STANDARD]F209.DEFMACRO;21
 
 (defmacro mac1 (a b) "Mac1 multiplies and adds" 
 (defmacro mac2 (&optional (a 2 b) (c 3 d) &rest x) `'(,a ,b ,c ,d ,x)) @EV MAC2 
 (defmacro mac3 (&whole r a &optional (b 3) &rest x &key c (d a))
% (defmacro mac4
 (defmacro dolist ((var listform @optional resultform)
 (defmacro dolist ((var listform \&optional resultform)
 (defmacro halibut ((mouth eye1 eye2)
 (defmacro halibut ((@whole head mouth eye1 eye2)
 (defmacro arithmetic-if (test neg-form zero-form pos-form)
 (defmacro arithmetic-if (test neg-form @optional zero-form pos-form)
 (defmacro loser (x @optional (a b @rest c) @rest z)
 (defmacro loser (x @optional ((a b @rest c)) @rest z)
 (defmacro loser (x @optional ((a b @rest c) '(nil nil)) @rest z)
 (defmacro loser (x @optional ((@optional a b @rest c)) @rest z)
 
******************************
DUA1:[CHAPMAN.STANDARD]F283.FLET;15
 
 (defmacro mlets (x &environment env) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F313.GET-SETF-METHOD;15
 
 (defmacro setf (reference value)
 
******************************
DUA1:[CHAPMAN.STANDARD]F315.GETF;15
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F327.INCF;12
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F390.MACRO-FUNCTION;13
 
 (defmacro macfun (x) '(macro-function 'macfun)) @EV MACFUN 
 
******************************
DUA1:[CHAPMAN.STANDARD]F391.MACROEXPAND;11
 
 (defmacro outer (x y) `(inner ,x ,y)) @EV\ OUTER
 (defmacro inner (x y) `(aa ,x ,y)) @EV\ INNER
 (defmacro env-sens (x y &environment e) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F393.MACROEXPAND-HOOK;13
 
 (defmacro machook (x y) `(/ (+ ,x ,y) 2)) @EV MACHOOK 
 
******************************
DUA1:[CHAPMAN.STANDARD]F506.POP;12
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F537.PUSH;12
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F538.PUSHNEW;13
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F566.REMF;11
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F583.ROTATEF;9
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F599.SETF;25
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F604.SHIFTF;12
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F807.CCASE;6
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F810.CHECK-TYPE;8
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F813.CTYPECASE;8
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F842.WITH-SIMPLE-RESTART;8
 
 (defmacro with-simple-restart ((restart-name format-string
 

∂03-Jan-89  1819	CL-Editorial-mailer 	Issue: CUT-OFF-DATES (Version 1)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89  18:18:53 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 JAN 89 13:14:16 PST
Date: 3 Jan 89 12:37 PST
From: masinter.pa@Xerox.COM
Subject: Issue: CUT-OFF-DATES (Version 1)
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 3 Jan 89 10:57
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu
Message-ID: <890103-131416-186@Xerox>

(I presume @mydis@decwrl.dec.com means cl-editorial?)

There are a couple of areas where I expect some further work that might
impact these dates:

a) pathname functions
I'm still hoping to get some cleanup of many of the pathname issues

b) errors signalled, by name
I'm still hoping that we can get at least a partial listing, for each
function, of the possible errors signalled, under what circumstances. 

c) pending cleanups
There will probably be 10-15 cleanup issues dealing with ambiguities that
will drag out beyond 3/89. I hope not, but I'm trying to be realistic;
there are just too many "open" issues left.

I don't think you should change your dates, but I'm warning about some
exceptions. Exceptions aren't unreasonable if there aren't too many of
them.

I'd propose that we adopt a policy of a 2/3 vote of the editorial committee
or a majority vote of X3J13 for exceptions to the cut-off-dates.


∂03-Jan-89  1820	CL-Editorial-mailer 	Re: Issue: DEPRECATION-POSITION   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89  18:19:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 JAN 89 13:53:41 PST
Date: 3 Jan 89 13:53 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEPRECATION-POSITION
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 15 Dec 88 04:23
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu,
 sandra%cdr@cs.utah.edu
Message-ID: <890103-135341-198@Xerox>

There are two levels:

1) features in CLtL that are not present in ANSI Common Lisp 1989
2) features in ANSI Common Lisp 1989 that will likely not be present in
future standards

The issues are:

a) what features fit into which category
b) how should implementations deal with such features? how can programs be
written to avoid problems with such features?

For the most part, X3J13 hasn't been able to deal with (a) until (b) has
been resolved. In particular, there are a number of features that we didn't
want to remove from ANSI Common Lisp 1989 if it would be awkward for
implementations to continue to support them or programs to continue to use
them, but wanted to at least declare them "obsolete". There's been some
debate on whether CHAR-FONT, for example , should be at level (1) or level
(2).
 
As for issue (b) Common Lisp, unlike Fortran or Pascal, has a couple of
different mechanisms to deal with conditional presence of differing
features, namely:

packages: obsolete features could be kept in a separate package
	the "new" language could be in a different package from the 
	  "old" language, even though the packages shared most symbols

features: #+, #- might be used by programs to work around the differences
	between different versions

require/provide: (unless removed by REQUIRE-PATHNAME-DEFAULTS issue), users
might explictly be expected to "require" obsolete features.

These mechanisms are also reasonable ways of dealing with subsets and
extensions.  

I personally would like to avoid using #+/#- for dealing with features, and
resorting to packages as the primary mechanism.



∂03-Jan-89  1819	CL-Editorial-mailer 	Re: Please review and comment ASAP
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89  18:19:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 JAN 89 13:19:50 PST
Date: 3 Jan 89 13:07 PST
From: masinter.pa@Xerox.COM
Subject: Re: Please review and comment ASAP
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 3 Jan 89 10:54
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu
Message-ID: <890103-131950-188@Xerox>

There are several classes of extensions, and I think the standard could
constrain conforming implementations to only provide certain kinds of
extensions. 

The "cleanup" issue IF-BODY really contained a proposal for a policy on
syntactic extensions, namely, that syntactic extensions, even if lexically
determinable, should be outlawed. That's an extreme position, and it
probably needs a vote in the X3J13 body.

Extensions that are associated with symbols that are external in the LISP
package are reasonable; I'm not sure what other constraints we should place
on the package environment of extensions. Extensions to existing functions
as far as additional optional or keyword arguments might be disallowed,
except where explicitly allowed. Extensions to existing functions as far as
data types or arguments allowed might be disallowed, except where
explicitly allowed.

It seems to be a constraint on "documentation" rather than "implementation"
if you turn the accidental behavior of (CAR T) into a "feature" of your
implementation. We might want to disallow such an extension as "conforming
to the standard". An implementation which had such an extension might
conform, even if the extension did not conform.

If the standard says that "the results are unspecified", and an
implementation specifies the results, is this an extension? It is, in the
sense that if the correct behavior of a program depends on the results,
only implementations with the same extension will execute the program
correctly.


∂03-Jan-89  1819	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89  18:18:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 JAN 89 13:17:25 PST
Date: 3 Jan 89 12:59 PST
From: masinter.pa@Xerox.COM
Subject: Issue: CONFORMANCE-POSITION (Version 2)
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 3 Jan 89 10:53
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu
Message-ID: <890103-131725-188@Xerox>

I think it might be possible that statements about conforming programs and
conforming implemenations are "dual", i.e., that you might define a
conforming program in terms of conforming implementations and conforming
implementations in terms of conforming programs. However, the current
practice is that the standard is in terms of what conforming
*implementations* will provide. Your wording "CLtL generally describes
things in terms of what a correct program can expect." I think is telling.
A program doesn't "expect" anything. A programming might expect something
when the programmer writes a program, but the resulting program is just a
bunch of characters. I believe that the requirements are that:

conforming programs use the described syntax
conforming programs are written using the described functions, macros,
special forms, variables, constants
conforming implementations provide the described functions, macros, special
forms, variables, constants, and that they behave in ways that conform to
the descriptions of them

For example, there are two cleanup issues, LISP-SYMBOL-REDEFINITION and
PACKAGE-CLUTTER, the first of which defines a constraint on conforming
programs (namely, that they don't redefine symbols in the LISP pckage) and
the second of which defines a constraint on conforming implementations
(namely, that they don't put extra external symbols in the LISP package.)

It might be possible to turn a constraint on conforming implementations
into a constraint on conforming programs, but it would be awkward to do so
and not particularly useful.

It would be useful to say that a conforming program used only the
functions, variables, constants, macros, etc. either defined in the
standard or defined by the program.

It might be useful to say that a conforming implementation satisfies all of
the constraints in the standard that say that "implementations must".

Some constraints are on "documentation". 

∂03-Jan-89  1818	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION (Version 1) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89  18:18:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 JAN 89 13:11:54 PST
Date: 3 Jan 89 12:29 PST
From: masinter.pa@Xerox.COM
Subject: Issue: SUBSETTING-POSITION (Version 1)
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 3 Jan 89 10:56
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu
Message-ID: <890103-131154-186@Xerox>

(Since you said ASAP I'll skip over the other 600 messages in my inbox.)

I think we can be making a mistake paying too much attention to other
languages, because they differ so much from Lisp.

First of all, we should review the possible kinds of subsets one might
have: subsets might omit syntax, functions, admissable values or arguments
to functions, or data types. For example, a subset might disallow SPECIAL
declarations (a syntactic subset), might omit the COS, SIN, ATAN functions,
might disallow the :TEST keyword to MAKE-HASH-TABLE, might restrict TAILP
to work on proper lists, or might omit complex numbers. Each of these is a
"subset" in the sense that a subset of correct programs for the "full"
language would be correct for the "subset" language.

Subsets can have various levels of "determinability" for programs. The
issue is: how easy is it to tell whether a program written in the "full"
language would run in a "subset" implementation?  Except for the
(non-trivial) issue of macro expansions, some subsets are "lexically"
determinable, e.g., if a function is omitted, you can tell if the program
uses it by scanning the program. Some subsets are "dynamically"
determinable, e.g, a subset might signal an error if the :TEST argument to
MAKE-HASH-TABLE is EQUALP. Some subsets are neither lexically nor
dynamically determinable, e.g., if the subset implements dynamic extent for
rest lists, it may be impossible to tell even with run-type checks whether
the a program written in the "full" language would conform.

Some "subsets" might be merely restrictive interpretations, e.g., a
"run-time" implementation that made ED, TRACE, UNTRACE into no-ops and made
BREAK halt the program execution rather than "enter the debugger"; since we
cannot define what "enter the debugger" means, we might want to define
explicitly this subset as a reasonable one for embedded systems.

I think there may be two issues, rather than one. 

a) What subsets should be specified in the draft standard we submit to
ANSI?

I think our position is that the draft standard we submit to ANSI should
contain *no* subsets. We should point out in a section on "subsetting" that
Lisp is a "small" language with a "big" library and that the conventional
mechanism for allowing small memory images is auto-load.

b) What position should we take if someone should propose a subset?

We don't have any proposals before us, but, if we did, I think we should
consider the cost/benefit properties of  such subsets  in mind. 

The benefits of a subset are presumably better performance (e.g., if you
assume that there are no displaced arrays), or smaller size (e.g., the
initial memory image is maller). Other benefits might be simpler semantics
(remove the possiblity of exceptions or awkward cases) or cleaner semantics
(less things to teach and learn.)

The cost of a subset is the difficulty of dealing with programs that want
to go from a "full" implementation to a "subset" implementation, and user
frustration in the different levels of the language.

Some of this analysis is as appropriate to the issue of extensions as it is
to subsets.

Frankly, we've not had much luck in "cleanup" in voting on "policy" in the
abstract; rather, we've handled particular cases. The only fleshed-out
proposal I've heard about for a subset of Common Lisp was from a Japanese
working group, well over  a year ago, and I don't know how actively they're
persuing it.

∂04-Jan-89  0900	CL-Editorial-mailer 	part 2 (there will be a part 3 too)    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  09:00:41 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA28886; Wed, 4 Jan 89 08:59:28 PST
Message-Id: <8901041659.AA28886@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 4 Jan 89 11:57
To: cl-editorial@sail.stanford.edu
Subject: part 2 (there will be a part 3 too)

 
******************************
DUA1:[CHAPMAN.STANDARD]F210.DEFPARAMETER;13
 
 (defparameter *p* 1) @EV *P*
 (defparameter *p* 3) @EV *P*
 
******************************
DUA1:[CHAPMAN.STANDARD]F208.DEFINE-SETF-METHOD;17
 
 (defsetf frob (x) (value) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F211.DEFSETF;12
 
 (defsetf access-fn update-fn @lbracket\ doc-string@rbracket)
 (defsetf symbol-value set)
 (defsetf car rplaca)
 (defsetf access-fn lambda-list (store-variable) . body)
 (defsetf middleguy set-middleguy) @EV MIDDLEGUY
 (defsetf subseq (sequence start &optional end) (new-sequence)
 
******************************
DUA1:[CHAPMAN.STANDARD]F212.DEFSTRUCT;28
 
 (defstruct (name option-1 option-2 ...)
 (defstruct ship
 (defstruct door knob-color width material)
 (defstruct person name age sex)
 (defstruct (astronaut (:include person)
 (defstruct (astronaut (:include person (age 45)))
 (defstruct (binop (:type list) :named (:initial-offset 2))
 (defstruct (annotated-binop (:type list)
 (defstruct (binop (:type list) (:initial-offset 2))
 (defstruct (binop (:type list) :named (:initial-offset 2))
 (defstruct (binop (:type list))
 (defstruct (binop (:type list) :named)
 (defstruct town
 (defstruct (clown (:conc-name bozo-))
 (defstruct (clown (:constructor make-up-clown) ;redefine using other
 (defstruct vehicle name year (diesel t :read-only t)) @EV VEHICLE
 (defstruct (truck (:include vehicle (year 79)))
 (defstruct (pickup (:include truck))     ;pickup type includes truck
 (defstruct (dfs-boa                      ;BOA constructors
 (defstruct ship
 (defstruct (binop (:type list) :named)
 
******************************
DUA1:[CHAPMAN.STANDARD]F687.TYPE-OF;7
 
 (defstruct temp-struct x y z) @EV\ TEMP-STRUCT
 
******************************
DUA1:[CHAPMAN.STANDARD]S2400.TYPE-SPECIFIERS;28
 
(deftype string-char () '(and character (satisfies string-char-p)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F213.DEFTYPE;10
 
 (deftype square-matrix (@optional type size)
 
******************************
DUA1:[CHAPMAN.STANDARD]F179.COMPILER-LET;12
 
 (defvar *collect-var* nil)  @EV\ *COLLECT-VAR*
 
******************************
DUA1:[CHAPMAN.STANDARD]F215.DEFVAR;15
 
 (defvar *my-variable* (construct-initial-value) "A documentation string")  
 (defvar *v* 'global) @EV *V*
 (defvar *v* (setq should-stay-nil t)) @EV *V*
 
******************************
DUA1:[CHAPMAN.STANDARD]F233.DOCUMENTATION;13
 
 (defvar grz 0 "grz variable documentation") @EV\ GRZ
 
******************************
DUA1:[CHAPMAN.STANDARD]F256.EVALHOOKVAR;11
 
 (defvar *last-form*) @EV *LAST-FORM*
 
******************************
DUA1:[CHAPMAN.STANDARD]F257.EVALHOOK;12
 
 (defvar *temp*) @EV *TEMP* 
% (defvar *hooklevel* 0)
 
******************************
DUA1:[CHAPMAN.STANDARD]F667.SYMBOL-PLIST;8
 
 (defvar *sym* (gensym)) @EV\ *SYM*
 
******************************
DUA1:[CHAPMAN.STANDARD]F218.DELETE-FILE;9
 
 (delete-file "/tmp/delete-test") @EV implementation dependent
 (delete-file s) @EV implementation dependent
 
******************************
DUA1:[CHAPMAN.STANDARD]F218.DELETE-FILE;9
 
 (delete-file "/tmp/delete-test") @EV implementation dependent
 (delete-file s) @EV implementation dependent
 
******************************
DUA1:[CHAPMAN.STANDARD]F568.REMOVE;14
 
 (setq list3 (delete 'four list)) @EV (LIST OF ELEMENTS)
 (delete-if #'evenp tester) @EV (1 3 5) 
 (delete 4 '(1 2 4 1 3 4 5)) @EV (1 2 1 3 5)
 (delete 4 '(1 2 4 1 3 4 5) :count 1) @EV (1 2 1 3 4 5)
 (delete 4 '(1 2 4 1 3 4 5) :count 1 :from-end t)
 (delete 3 '(1 2 4 1 3 4 5) :test #'>) @EV (4 3 4 5)
 (delete-if #'oddp '(1 2 4 1 3 4 5)) @EV (2 4 4)
 (delete-if #'evenp '(1 2 4 1 3 4 5) :count 1 :from-end t)
 
******************************
DUA1:[CHAPMAN.STANDARD]F569.REMOVE-DUPLICATES;14
 
 (delete-duplicates '(0 1 2 3 4 5 6) :key #'oddp :start 1 :end 6) @EV (0 4 5 6)
 
******************************
DUA1:[CHAPMAN.STANDARD]F228.DISASSEMBLE;12
 
     (progn (disassemble 'f)
 
******************************
DUA1:[CHAPMAN.STANDARD]F232.DO-SYMBOLS;10
 
    (do-symbols (s 'temp) (push s lst))
 
******************************
DUA1:[CHAPMAN.STANDARD]F239.DRIBBLE;10
 
{\function (dribble)} terminates the recording of input and output and
returning only when {\tt (dribble)} is done.
 
******************************
DUA1:[CHAPMAN.STANDARD]F273.FILL;14
 
 (fill '(0 1 2 3 4 5) '(444)) @EV ((444) (444) (444) (444) (444) (444))
 (fill "01234" #\\e :start 3) @EV "012ee"
 (fill x 'z :start 1 :end 3) @EV \#(a z z d e)
 (fill x 'p) @EV \#(p p p p p)
 
******************************
DUA1:[CHAPMAN.STANDARD]F274.FILL-POINTER;8
 
 (fill-pointer
 (setf (fill-pointer fa) 0) @EV 0
 (fill-pointer fa) @EV 0
 
******************************
DUA1:[CHAPMAN.STANDARD]F355.LENGTH;9
 
 (setf (fill-pointer str) 2) @EV\ 2
 
******************************
DUA1:[CHAPMAN.STANDARD]F704.VECTOR-POP;8
 
 (fill-pointer fa) @EV 3 
 (fill-pointer fa) @EV 1 
 
******************************
DUA1:[CHAPMAN.STANDARD]F705.VECTOR-PUSH;9
 
 (fill-pointer fa) @EV 3 
 (fill-pointer aa) @EV 4 
 
 
******************************
DUA1:[CHAPMAN.STANDARD]S3100.CHARACTER-READER;48
 
 (intern (string slotj) (find-package 'keyword))
 
******************************
DUA1:[CHAPMAN.STANDARD]F056.ASSOC;18
 
 (find item list :test fn :key \#'car)
 
******************************
DUA1:[CHAPMAN.STANDARD]F275.FIND;15
 
 (find #\\d "here are some letters that can be looked at" :test #'char>)
 (find-if #'oddp '(1 2 3 4 5) :end 3 :from-end t) @EV 3
 (find-if-not #'complexp                                    
 
******************************
DUA1:[CHAPMAN.STANDARD]F485.PACKAGE-NAME;8
 
 (package-name (find-package 'lisp)) @EV "LISP"
 
******************************
DUA1:[CHAPMAN.STANDARD]F490.PACKAGEP;7
 
 (packagep (find-package 'lisp)) @EV\ true 
 
******************************
DUA1:[CHAPMAN.STANDARD]F534.PROVIDE;12
 
 (find "TEST-MODULE" *modules* :test \#'equal) @EV\ "TEST-MODULE"
 
******************************
DUA1:[CHAPMAN.STANDARD]F544.RASSOC;12
 
 (find item list :test fn :key #'cdr)
 
 
******************************
DUA1:[CHAPMAN.STANDARD]F594.SET-DIFFERENCE;7
 
                #'(lambda (s c) (find c s)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F751.KEYKEYWORD;4
 
(find @i[item] @i[sequence] {\keyword :test} \#'eq {\keyword :key} \#'car)
 
******************************
DUA1:[CHAPMAN.STANDARD]F208.DEFINE-SETF-METHOD;17
 
 (flet ((frob (x) (cdr x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F263.FBOUNDP;8
 
 (flet ((dummy-function #'(lambda (x) x)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F283.FLET;15
 
 (flet ((flet1 (n) (+ n n)))
    (flet ((flet1 (n) (+ 2 (flet1 n))))
      (flet1 2))) @EV 6
 (flet ((+ (&rest args) 'crossed-out)) @EV (+ 1 2 3)) CROSSED-OUT
 (flet ((dummy-function () 'shadow)) 
 (flet ((dummy-function () 'shadow)) 
 (flet ((safesqrt (x) (sqrt (abs x))))
   (flet ((attach (x)
 
******************************
DUA1:[CHAPMAN.STANDARD]F413.MAKUNBOUND;11
 
 (flet ((dummy-function (x) (1+ x)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F909.DEFINE-METHOD-COMBINATION;8
 
  (flet ((call-methods (methods)
 
******************************
DUA1:[CHAPMAN.STANDARD]S5100.ERRORS;39
 
       (format t "~&Evaluation of ~S failed:~%~a" form condition))))
                 (format stream "Retry getting the value of ~S." variable))
           (format stream "Specify a value of ~S to use this time." variable))
           (format stream "Specify a value of ~S to store and use." variable))
                           (format stream "expunge ~A."
 
******************************
DUA1:[CHAPMAN.STANDARD]F002.STARVAR;16
 
 (format t "* => ~S~%** => ~S~%*** => ~S~%" * ** ***) @EV
 
******************************
DUA1:[CHAPMAN.STANDARD]F006.PLUSVAR;12
 
 (format t "+ =>~S~%++ => ~S~%+++ => ~S~%" + ++ +++)
 
******************************
DUA1:[CHAPMAN.STANDARD]F010.MINUSVAR;11
 
 (format t "- => ~S~%" -) @EV - => (FORMAT T "- => ~S~%" -)
 
******************************
DUA1:[CHAPMAN.STANDARD]F012.SLASHVAR;14
 
 (format t "/ => ~S~%// => ~S~%/// => ~S~%" / // ///) @EV 
 
******************************
DUA1:[CHAPMAN.STANDARD]F117.CASE;15
 
    (format t "~S "
 
******************************
DUA1:[CHAPMAN.STANDARD]F136.CERROR;11
 
  (format *query-io* "@tilde \&New word: ")
 
******************************
DUA1:[CHAPMAN.STANDARD]F169.CLEAR-INPUT;14
 
    (format t "~S " (read in-stream))
    (format t "~S " (read in-stream))) @EV\ 1 2 
 
******************************
DUA1:[CHAPMAN.STANDARD]F229.DO-DOSTAR;16
 
  (format t "@tilde \%Input @tilde D:" j)
	(format t "@tilde \&Output @tilde D: @tilde S" j (process item)))))
 
******************************
DUA1:[CHAPMAN.STANDARD]F257.EVALHOOK;12
 
%    (format *trace-output* "@tilde \% @tilde V\@TForm:  @tilde S"
%      (format *trace-output* "@tilde @tilde V\@TValue:@tilde \{ @tilde S @tilde \}"
 
******************************
DUA1:[CHAPMAN.STANDARD]F269.FILE-LENGTH;7
 
 (format s "0123456789") @EV\ NIL
 
******************************
DUA1:[CHAPMAN.STANDARD]F271.FILE-POSITION;9
 
 (format s "abcdefghijklmnopqrstuvwxyzzyxwvutsrqponmlkjihgfedcba") @EV\ NIL
 
******************************
DUA1:[CHAPMAN.STANDARD]F293.FORMAT;58
 
 (format nil "@tilde,,' ,4:B" 13) @EV "1101"
 (format nil "@tilde,,' ,4:B" 17) @EV "1 0001"
 (format nil "@tilde19,0,' ,4:B" 3333) @EV "0000 1101 0000 0101"
 (format nil "@tilde3,,,' ,2:R" 17) @EV "1 22"
 (format nil "@tilde,,'|,2:D" #xFFFF) @EV  "6|55|35"
 (format @false "@tilde\ D tr@tilde:@ats\ P/@tilde\ D win@tilde:P" 7 1) @EV "7 tries/1 win"
 (format @false "@tilde\ D tr@tilde:@ats\ P/@tilde\ D win@tilde:P" 1 0) @EV "1 try/0 wins"
 (format @false "@tilde\ D tr@tilde:@ats\ P/@tilde\ D win@tilde:P" 1 3) @EV "1 try/3 wins"
   (format *error-output*
 (format nil "@tilde\ ? @tilde\ D" "<@tilde\ A @tilde\ D>" '("Foo" 5) 7) @EV "<Foo 5> 7"
 (format nil "@tilde\ ? @tilde\ D" "<@tilde\ A @tilde\ D>" '("Foo" 5 14) 7) @EV "<Foo 5> 7"
 (format nil "@tilde\ @ats\ ? @tilde\ D" "<@tilde\ A @tilde\ D>" "Foo" 5 7) @EV "<Foo 5> 7"
 (format nil "@tilde\ @ats\ ? @tilde\ D" "<@tilde\ A @tilde\ D>" "Foo" 5 14 7) @EV "<Foo 5> 14"
%(format t "The item is a @tilde @lbracket Foo@tilde ;Bar@tilde ;Loser@tilde
 (format @false "@tilde\ :@lbracket\ abc@tilde\ :@ats\ (def@tilde\ ;ghi@tilde\ :@ats\ (jkl@tilde\ @rbracket\ mno@tilde\ )" x) ;Illegal!
 (format @false "@tilde\ ?ghi@tilde\ )" "abc@tilde\ @ats\ (def") ;Illegal!
 (format nil "@tilde\ @ats\ R @tilde\ (@tilde\ @ats\ R@tilde\ )" 14 14) @EV "XIV xiv"
 (defun f (n) (format nil "@tilde\ @ats\ (@tilde\ R@tilde\ ) error@tilde\ :P detected." n))
 (format @false                                  
 (format @false foo) @EV  "Items: none."
 (format @false foo 'foo) @EV  "Items: FOO."
 (format @false foo 'foo 'bar) @EV  "Items: FOO and BAR."
 (format @false foo 'foo 'bar 'baz) @EV  "Items: FOO, BAR, and BAZ."
 (format @false foo 'foo 'bar 'baz 'quux) @EV  "Items: FOO, BAR, BAZ, and QUUX."
 (format @false "The winners are:@tilde\ @lbr @tilde\ S@tilde\ @rbr\ ." 
 (format @false "Pairs:@tilde\ @lbr <@tilde\ S,@tilde\ S>@tilde\ @rbr\ ." 
 (format @false "Pairs:@tilde\ :@lbr <@tilde\ S,@tilde\ S>@tilde@rbr\ ." 
 (format @false "Pairs:@tilde\ @ats\ @lbr <@tilde\ S,@tilde\ S>@tilde\ @rbr\ ."
 (format @false "Pairs:@tilde\ :@ats\ @lbr <@tilde\ S,@tilde\ S>@tilde\ @rbr\  ." 
 (format stream "@tilde\ 1@lbr\ @tilde\ :@rbr\ " string arguments)
 (format @false donestr) @EV "Done."
 (format @false donestr 3) @EV "Done.  3 warnings."
 (format @false donestr 1 5) @EV "Done.  1 warning.  5 errors."
 (format nil "@tilde\ :@lbr\ @tilde\ @ats\ ?@tilde\ :@hat\ ...@tilde\ @rbr\ " '(("a") ("b")))
 (format @false tellstr 23) @EV "Twenty-three."
 (format @false tellstr nil "losers") @EV "Losers."
 (format @false tellstr 23 "losers") @EV "Twenty-three losers."
 (format @false "@tilde\ 15<@tilde\ S@tilde\ ;@tilde\ \↑@tilde\ S@tilde\ ;@tilde\ \↑@tilde\ S@tilde\ >" 'foo)
 (format @false "@tilde\ 15<@tilde\ S@tilde\ ;@tilde\ \↑@tilde\ S@tilde\ ;@tilde\ \↑@tilde\ S@tilde\ >" 'foo 'bar)
 (format @false "@tilde\ 15<@tilde\ S@tilde\ ;@tilde\ \↑@tilde\ S@tilde\ ;@tilde\ \↑@tilde\ S@tilde\ >" 'foo 'bar 'baz)
 (format @false "foo") @EV "foo"
 (format @false "The answer is @tilde\ D." x) @EV "The answer is 5."
 (format @false "The answer is @tilde\ 3D." x) @EV "The answer is   5."
 (format @false "The answer is @tilde\ 3,'0D." x) @EV "The answer is 005."
 (format @false "The answer is @tilde\ :D." (expt 47 x))
 (format @false "Look at the @tilde\ A!" y) @EV "Look at the elephant!"
 (format @false "Type @tilde\ :C to @tilde\ A."
 (format @false "@tilde\ D item@tilde\ :P found." n) @EV "3 items found."
 (format @false "@tilde\ R dog@tilde\ :@lbracket\ ;s are@tilde\ ; is@tilde\ @rbracket  here." n (= n 1))
 (format @false "@tilde\ R dog@tilde\ :*@tilde\ @lbracket\ s are@tilde\ ; is@tilde\ :;s are@tilde\ @rbracket  here." n)
 (format @false "Here @tilde\ @lbracket  are@tilde\ ;is@tilde\ :;are@tilde\ @rbracket  @tilde\ :*@tilde\ R pupp@tilde\ :@ats\ P." n)
   (format nil "@tilde\ 6,2F|@tilde\ 6,2,1,'*F|@tilde\ 6,2,,'?F|@tilde\ 6F|@tilde\ ,2F|@tilde\ F"
 (format @nil
   (format t "@tilde\ \%Scale factor @tilde\ 2D: |@tilde\ 13,6,2,VE|"
   (format @nil "@tilde\ 9,2,1,,'*G|@tilde\ 9,3,2,3,'?,,'\$G|@tilde\ 9,3,2,0,'\%G|@tilde\ 9,2G"
 (format @false "@tilde\ 10<foo@tilde\ ;bar@tilde\ >") @EV "foo    bar"
 (format @false "@tilde\ 10:<foo@tilde\ ;bar@tilde\ >") @EV "  foo  bar"
 (format @false "@tilde\ 10<foobar@tilde\ >") @EV "    foobar"
 (format @false "@tilde\ 10:<foobar@tilde\ >") @EV "    foobar"
 (format @false "@tilde\ 10:@ats\ <foo@tilde\ ;bar@tilde\ >") @EV  "  foo bar "
 (format @false "@tilde\ 10@ats\ <foobar@tilde\ >") @EV "foobar    "
 (format @false "@tilde\ 10:@ats\ <foobar@tilde\ >") @EV  "  foobar  "}
 
******************************
DUA1:[CHAPMAN.STANDARD]F356.LET-LETSTAR;13
 
    (format nil "~S ~S ~S" a b (dummy-function)))
    (format nil "~S ~S ~S" a b (dummy-function)))
    (format nil "~S ~S ~S" a b (dummy-function)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F393.MACROEXPAND-HOOK;13
 
    (format t "Now expanding: ~S~%" form)
 
******************************
DUA1:[CHAPMAN.STANDARD]F396.MAKE-BROADCAST-STREAM;10
 
 (format (make-broadcast-stream a-stream b-stream)
 
******************************
DUA1:[CHAPMAN.STANDARD]F400.MAKE-ECHO-STREAM;9
 
      (format s " * this-is-direct-output")
 
******************************
DUA1:[CHAPMAN.STANDARD]F408.MAKE-STRING-OUTPUT-STREAM;9
 
 (format s "output 1~\%") @EV\ NIL
 (format s "output 2~\%") @EV\ NIL
 
******************************
DUA1:[CHAPMAN.STANDARD]F412.MAKE-TWO-WAY-STREAM;7
 
        (format two "output...")
 
******************************
DUA1:[CHAPMAN.STANDARD]F502.PEEK-CHAR;11
 
    (format t "~S ~S ~S" 
 
******************************
DUA1:[CHAPMAN.STANDARD]F517.PRINT-BASE;12
 
      (if (zerop (mod i 10)) (terpri) (format t " ")))) @EV\ 101000
     (format t "~S ~S   " 10 1/10)))        ;3, 8, 10, 16
 
******************************
DUA1:[CHAPMAN.STANDARD]F518.PRINT-CASE;10
 
    (let ((*print-case* pc)) (format t "~S " 'up-and-down)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F523.PRINT-LEVEL;13
 
      (format t "~S~\%" a)))  @EV\ 
      (format t "~S~%" a))) @EV\ 
 
******************************
DUA1:[CHAPMAN.STANDARD]F550.READ;13
 
      (format t "~S ~S" (read is) (read is)))) @EV\ \#\\x \#\\Space
 
******************************
DUA1:[CHAPMAN.STANDARD]F552.READ-BYTE;7
 
    (format t "~S ~S" (read-byte s) (read-byte s nil 'eof))) @EV\ 101 EOF
 
******************************
DUA1:[CHAPMAN.STANDARD]F553.READ-CHAR-NO-HANG;8
 
 (format t "~S ~S ~S" (read-char-no-hang) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F554.READ-CHAR;8
 
     (format t "~S" c)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F560.READ-SUPPRESS;9
 
    (format t "~%input here> ")
    (format t "evaluated as: ~S~%" (eval (read)))
    (format t "~%input here> ")
    (format t "evaluated as: ~S~%" (eval (read)))
    (format t "~%input here> ")
    (format t "evaluated as: ~S~%" (eval (read)))
    (format t "~%input here> ")
    (format t "evaluated as: ~S~%" (eval (read)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F595.SET-DISPATCH-MACRO-CHARACTER;14
 
                  (format *trace-output* 
 
******************************
DUA1:[CHAPMAN.STANDARD]F627.STANDARD-OUTPUT;8
 
                     (format t "*standard-output* now going to a string")))
 
******************************
DUA1:[CHAPMAN.STANDARD]F676.TERMINAL-IO;7
 
                     (format t "you won't see")
                     (format *standard-output* "evaluate the string")
                     (format *query-io* " named  out")))
 
******************************
DUA1:[CHAPMAN.STANDARD]F677.TERPRI;10
 
    (format s "not an ")
    (format s "empty line")
    (format s "aftermath"))
    (format s "not an ")
    (format s "empty line")
    (format s "aftermath"))
 
******************************
DUA1:[CHAPMAN.STANDARD]F694.UNREAD-CHAR;9
 
        (if (evenp i) (format t "~S ~S~%" i c) (unread-char c is)))))
 
******************************
DUA1:[CHAPMAN.STANDARD]F711.WITH-OPEN-FILE;10
 
    (format s "Here are a couple~%of test data lines~%")) @EV NIL
     (format t "==>~A~%" l)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F713.WITH-OUTPUT-TO-STRING;8
 
    (format s "here's some output")
 
******************************
DUA1:[CHAPMAN.STANDARD]F809.CERROR;6
 
         (format t ">>> ")
              (format stream "~S is not a number"
         (format t ">>> ")
 
******************************
DUA1:[CHAPMAN.STANDARD]F812.CONTINUE;4
 
       (format t "~&Enter a new value: ")
 
******************************
DUA1:[CHAPMAN.STANDARD]F815.DEFINE-CONDITION;6
 
              (format stream "a ~a peg cannot go in a ~A hole."
             (format stream "there is a problem with ~A."
             (format stream "the machine ~A is not available."
              (format stream "~A ate too much ~A ice-cream
 (format t "~A" *)
 
******************************
DUA1:[CHAPMAN.STANDARD]F817.ERROR;4
 
              (format stream "~S is not a number"
 
******************************
DUA1:[CHAPMAN.STANDARD]F821.HANDLER-BIND;4
 
   (format *error-output* "~A was seen and ignored" condition)
 
******************************
DUA1:[CHAPMAN.STANDARD]F822.HANDLER-CASE;6
 
         (file-error (condition) (format t "~&fooey: ~A~%" condition)))
      (format nil "~A is a serious condition" condition))
 
******************************
DUA1:[CHAPMAN.STANDARD]F825.INVOKE-RESTART-INTERACTIVELY;5
 
         (format t "~&~D: ~A~%" (incf index) case))
       (format t "Please enter restart to invoke: ")
                      (format t "Please enter a value to return: ")
 
******************************
DUA1:[CHAPMAN.STANDARD]F826.INVOKE-RESTART;5
 
         (format t "~&~D: ~A~%" (incf index) case))
       (format t "Please enter restart to invoke: ")
 
******************************
DUA1:[CHAPMAN.STANDARD]F827.MAKE-CONDITION;5
 
 (format t "~A" a)
 
******************************
DUA1:[CHAPMAN.STANDARD]F828.MUFFLE-WARNING;6
 
     (format t "~&~D~%" counter)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F830.RESTART-BIND;6
 
                               (format stream "Return an optional value")))\kern-3pt
                               (format stream "Return the given value"))
                                    (format t "Enter a value to return: ")
         (format t "~&~D: ~A~%" (incf index) case))
       (format t "Please enter restart to invoke: ")
 
******************************
DUA1:[CHAPMAN.STANDARD]F831.RESTART-CASE;8
 
(format t "~&~S -- ~A~%" ':continue some-restart)
                       (format stream "Return from command level ~D." level))
              (format stream "Bad tasting sundae with ~S, ~S, and ~S"
   (format t "Enter a new value: ")
 
******************************
DUA1:[CHAPMAN.STANDARD]F832.RESTART-NAME;4
 
     (format t "~&~A~%" (restart-name case)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F833.SIGNAL;5
 
   (format t "Considering condition for division condition handling~%")
   (format t "Considering condition for arithmetic condition handling~%")
 
******************************
DUA1:[CHAPMAN.STANDARD]F842.WITH-SIMPLE-RESTART;8
 
{\tt                    (format stream ,format-string ,{\char '100}format-arguments))}
 
******************************
DUA1:[CHAPMAN.STANDARD]F208.DEFINE-SETF-METHOD;17
 
       (get-setf-method x)
       (get-setf-method int)    ;Get SETF method for int.
                        (get-setf-method place env)
 
******************************
DUA1:[CHAPMAN.STANDARD]F313.GET-SETF-METHOD;15
 
 (get-setf-method 'x) @EV NIL NIL (<symbol name>) (SETQ X <symbol name>) X 
 (get-setf-method-multiple-value '(multivalue dummy-symbol)) @EV NIL NIL
       (get-setf-method reference)
 
******************************
DUA1:[CHAPMAN.STANDARD]S5400.GENERALIZED-REFERENCE;19
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F207.DEFINE-MODIFY-MACRO;16
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F304.GET;10
 
(get x y) @EQ\ (getf (symbol-plist x) y)
 
******************************
DUA1:[CHAPMAN.STANDARD]F311.GET-PROPERTIES;8
 
 (getf (car x) 'prop1) @EV\ NIL
 (setf (getf (car x) 'prop1) 'val1) @EV\ VAL1
 (eq (getf (car x) 'prop1) 'val1) @EV\ true
 
******************************
DUA1:[CHAPMAN.STANDARD]F315.GETF;15
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 (getf (car x) 'prop1) @EV NIL
 (setf (getf (car x) 'prop1) 'val1) @EV VAL1
 (eq (getf (car x) 'prop1) 'val1) @EV true
 
******************************
DUA1:[CHAPMAN.STANDARD]F327.INCF;12
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F506.POP;12
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F537.PUSH;12
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F538.PUSHNEW;13
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F566.REMF;11
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 (setf (getf (car x) 'prop1) 'val1) @EV VAL1
 
******************************
DUA1:[CHAPMAN.STANDARD]F583.ROTATEF;9
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F599.SETF;25
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F604.SHIFTF;12
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F807.CCASE;6
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F810.CHECK-TYPE;8
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F813.CTYPECASE;8
 
 (defmacro wrong-order (x y) `(getf ,y ,x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F941.UPDATE-INSTANCE-FOR-REDEFINED-CLASS;7
 
  (let ((x (getf plist 'x))
        (y (getf plist 'y)))
 

∂04-Jan-89  0902	CL-Editorial-mailer 	part 3   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  09:02:31 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA28918; Wed, 4 Jan 89 09:01:21 PST
Message-Id: <8901041701.AA28918@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 4 Jan 89 11:59
To: cl-editorial@sail.stanford.edu
Subject: part 3


******************************
DUA1:[CHAPMAN.STANDARD]F325.IMPORT;13
 
 (import 'lisp::car (make-package 'temp :use nil)) @EV T
The form {\tt (import 'editor:buffer)} takes
 
******************************
DUA1:[CHAPMAN.STANDARD]F032.AND;11
 
 (and (incf temp1) (incf temp2) (incf temp3)) @EV\ 2 
 
******************************
DUA1:[CHAPMAN.STANDARD]F234.DOLIST;11
 
 (dolist (temp-one '(1 2 3 4)) (incf temp-two)) @EV\ NIL
 
******************************
DUA1:[CHAPMAN.STANDARD]F235.DOTIMES;10
 
 (dotimes (temp-one 10 t) (incf temp-two)) @EV\ T
 
******************************
DUA1:[CHAPMAN.STANDARD]F316.GETHASH;9
 
 (incf (gethash a-key table 0))
 
******************************
DUA1:[CHAPMAN.STANDARD]F317.GO;8
 
   (incf val 3)
   lp (incf val 4)) @EV\ NIL
 
******************************
DUA1:[CHAPMAN.STANDARD]F327.INCF;12
 
 (incf (car a)) @EV 2
 (incf n) @EV 1      and now n @EV 1
The effect of @f[(incf place delta)]
 
******************************
DUA1:[CHAPMAN.STANDARD]F385.LOOP;8
 
    (loop (incf i) (if (= i 3) (return i)))) @EV\ 3
      (loop (incf j 3) (incf i) (if (= i 3) (go exit)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F419.MAPHASH;8
 
                 (incf sum-of-squares (* val val))) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F482.OR;9
 
 (or (incf temp1) (incf temp2) (incf temp3)) @EV\ 2 
 
******************************
DUA1:[CHAPMAN.STANDARD]F578.RETURN;9
 
    (dotimes (i 10) (incf a) (when (oddp i) (return)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F583.ROTATEF;9
 
    (rotatef (nth (incf n) x)
             (nth (incf n) x)
             (nth (incf n) x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F671.TAGBODY;9
 
      (incf val 16)
      (incf val 04)
      (incf val 32)
      (incf val 02)
      (incf val 64)
      (incf val 08))
 
******************************
DUA1:[CHAPMAN.STANDARD]F680.THROW;7
 
    (loop (incf j 3) (incf i)
 
******************************
DUA1:[CHAPMAN.STANDARD]F697.UNWIND-PROTECT;8
 
   (progn (incf *access-count*)
     (progn (incf *access-count*)
 
******************************
DUA1:[CHAPMAN.STANDARD]F825.INVOKE-RESTART-INTERACTIVELY;5
 
         (format t "~&~D: ~A~%" (incf index) case))
 
******************************
DUA1:[CHAPMAN.STANDARD]F826.INVOKE-RESTART;5
 
         (format t "~&~D: ~A~%" (incf index) case))
 
******************************
DUA1:[CHAPMAN.STANDARD]F830.RESTART-BIND;6
 
         (format t "~&~D: ~A~%" (incf index) case))
 
******************************
DUA1:[CHAPMAN.STANDARD]FORMAT.EXA;2
 
         (format t "~&~D: ~A~%" (incf index) case))
         (format t "~&~D: ~A~%" (incf index) case))
         (format t "~&~D: ~A~%" (incf index) case))
 
******************************
DUA1:[CHAPMAN.STANDARD]S3100.CHARACTER-READER;48
 
 (rplacd (last y) (cdr y))
 
******************************
DUA1:[CHAPMAN.STANDARD]F208.DEFINE-SETF-METHOD;17
 
 (defun lastguy (x) (car (last x))) @EV LASTGUY
         `(progn (rplaca (last ,getter) ,store) ,store)
         `(lastguy ,getter))))) @EV LASTGUY
 (setf (lastguy a) 3) @EV 3
 (setf (lastguy b) 7) @EV 7
 (setf (lastguy (lastguy c)) 'lastguy-symbol) @EV LASTGUY-SYMBOL
 
******************************
DUA1:[CHAPMAN.STANDARD]F342.LAST;8
 
 (last nil) EV NIL
 (last '(1 2 3)) @EV (3)
 (last '(1 2 . 3)) @EV (2 . 3)
 (last x) @EV (d)
 (rplacd (last x) '(e f)) x @EV '(a b c d e f)
 (last '(a b c . d)) @EV (c . d)
 (last    '(a b c) 0) @EV ()
 (last    '(a b c) 1) @EV (C)
 (last    '(a b c) 2) @EV (B C)
 (last    '(a b c) 3) @EV (A B C)
 (last    '(a b c) 4) @EV (A B C)
 (last    '(a b c))   @EV (C)
 (last '(a . b) 0)    @EV B
 (last '(a . b) 1)    @EV (A . B)
 (last '(a . b) 2)    @EV (A . B)
 
******************************
DUA1:[CHAPMAN.STANDARD]F361.LIST-LENGTH;9
 
   (rplacd (last x) x)
 
******************************
DUA1:[CHAPMAN.STANDARD]F208.DEFINE-SETF-METHOD;17
 
;;; SETF method for the form (LDB bytespec int).
              @bq(ldb ,btemp ,access-form) ;Accessing form.
 
******************************
DUA1:[CHAPMAN.STANDARD]F211.DEFSETF;12
 
a generalized reference that is a byte, such as @f[(ldb field reference)]\rm.
 
******************************
DUA1:[CHAPMAN.STANDARD]F344.LDB;10
 
 (ldb (byte 2 1) 10) @EV 1
 (setf (ldb (byte 2 1) (car a)) 1) @EV 1
 (logbitp j (ldb (byte s p) n)
 
******************************
DUA1:[CHAPMAN.STANDARD]F345.LDB-TEST;6
 
 (ldb-test (byte 4 1) 16) @EV\ true
 (ldb-test (byte 3 1) 16) @EV\ NIL
 (ldb-test (byte 3 2) 16) @EV\ true
(ldb-test bytespec n) @EQ\ (not (zerop (ldb bytespec n)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F371.LOGBITP;7
 
 (logbitp k n) @EQ\ (ldb-test (byte 1 k) n)
 
******************************
DUA1:[CHAPMAN.STANDARD]F422.MASK-FIELD;10
 
(ldb bs (mask-field bs n)) @EQ\ (ldb bs n)
 
******************************
DUA1:[CHAPMAN.STANDARD]F390.MACRO-FUNCTION;13
 
 (defmacro macfun (x) '(macro-function 'macfun)) @EV MACFUN 
 (not (macro-function 'macfun)) @EV NIL 
 (and (setf (macro-function 'macfun) #'equal)
         (equal (macro-function 'macfun) #'equal)) @EV true
    (equal (macro-function 'macfun) #'equal)) @EV true
               (if (macro-function 'bar env)
 (setf (macro-function 'bar env) ...) is an error.
(setf (macro-function symbol) fn)
 
******************************
DUA1:[CHAPMAN.STANDARD]F205.DEFAULT-PATHNAME-DEFAULTS;7
 
 (merge-pathnames (make-pathname :name q)) @EV\ #P"/usr/bin/calendar" 
 
******************************
DUA1:[CHAPMAN.STANDARD]F218.DELETE-FILE;9
 
    (setq p (merge-pathnames s))) @EV <pathname>
 (setq p (merge-pathnames 
 
******************************
DUA1:[CHAPMAN.STANDARD]F268.FILE-AUTHOR;9
 
 (setq s (open (merge-pathnames "passwd"))) @EV\ <stream>
 
******************************
DUA1:[CHAPMAN.STANDARD]F364.LOAD;11
 
 (load (setq p (merge-pathnames <filename>)) :verbose t)
 
******************************
DUA1:[CHAPMAN.STANDARD]F428.MERGE-PATHNAMES;13
 
 (merge-pathnames "CMUC::FORMAT"
 
******************************
DUA1:[CHAPMAN.STANDARD]F451.NAMESTRING;17
 
 (merge-pathnames (enough-namestring pathname defaults) defaults)
 (merge-pathnames (parse-namestring pathname nil defaults) defaults)
 
******************************
DUA1:[CHAPMAN.STANDARD]F481.OPEN;14
 
 (setq q (merge-pathnames (user-homedir-pathname) "mbox"))
 
******************************
DUA1:[CHAPMAN.STANDARD]F573.RENAME-FILE;9
 
    (setq p (merge-pathnames s))) @EV <pathname>
 
******************************
DUA1:[CHAPMAN.STANDARD]F711.WITH-OPEN-FILE;10
 
 (setq p (merge-pathnames "/tmp/w-open-fl.tmp")) @EV <pathname>
 
******************************
DUA1:[CHAPMAN.STANDARD]F431.MISMATCH;15
 
 (mismatch "abcd" "ABCDE" :test \#'char-equal) @EV 4
 (mismatch '(3 2 1 1 2 3) '(1 2 3) :from-end t) @EV 3
 (mismatch '(1 2 3) '(2 3 4) :test-not \#'eq :key \#'oddp) @EV NIL
 (mismatch '(1 2 3 4 5 6) '(3 4 5 6 7) :start1 2 :end2 4) @EV NIL 
 
******************************
DUA1:[CHAPMAN.STANDARD]F451.NAMESTRING;17
 
 (namestring "getty")            ;current working directory is /etc  
 
******************************
DUA1:[CHAPMAN.STANDARD]F685.TRUENAME;8
 
 (namestring (pathname file)) @ev "CMUC::DOC:DUMPER.HLP"
 (namestring (truename file))
 
******************************
DUA1:[CHAPMAN.STANDARD]F453.NCONC;10
 
 (nconc (list* 'a 'b 'c 'd) '()) @EV (a b c)	
 (nconc (list* 'a 'b 'c) '() 3) @EV (a b . 3)	
 (nconc (list) 17) @EV 17			
 (nconc lst1 lst2) @EV (1 2 3 A B C)
 (nconc) @EV NIL
 (nconc x y) @EV (a b c d e f)
If @f[(nconc x y)] were evaluated again,
 
******************************
DUA1:[CHAPMAN.STANDARD]F460.NRECONC;8
 
@f[(nconc (nreverse x) y)] except that it is potentially more
 
******************************
DUA1:[CHAPMAN.STANDARD]S5100.ERRORS;39
 
 (ignore-errors (open filename :direction :input))
 (handler-case (open filename :direction :input)
 (handler-case (open filename :direction :input)
 (let ((form '(open "nosuchfile")))
  Evaluation of (OPEN "NOSUCHFILE") failed:
 (open "foo" :direction :output)
 
******************************
DUA1:[CHAPMAN.STANDARD]F218.DELETE-FILE;9
 
           (setq s (open "/tmp/delete-test" :direction :output))))
 
******************************
DUA1:[CHAPMAN.STANDARD]F268.FILE-AUTHOR;9
 
 (setq s (open (merge-pathnames "passwd"))) @EV\ <stream>
 
******************************
DUA1:[CHAPMAN.STANDARD]F269.FILE-LENGTH;7
 
 (setq s (open "/tmp/file-len-test" 
 
******************************
DUA1:[CHAPMAN.STANDARD]F271.FILE-POSITION;9
 
 (setq s (open "/tmp/file-pos-test" 
 
******************************
DUA1:[CHAPMAN.STANDARD]F481.OPEN;14
 
 (open "/dev/ttya" :direction :probe)  @EV <stream>
 (open q :direction :output :if-exists :append) @EV <stream> 
 (open "/tmp/bar" :if-does-not-exist :create)   ;file bar does not 
 (setq s (open "/tmp/bar" :direction :probe)) @EV <stream> 
 (open s :direction :output :if-exists nil) @EV NIL 
 
******************************
DUA1:[CHAPMAN.STANDARD]F493.PARSE-NAMESTRING;15
 
 (setq s (open "/usr/include/sys/types.h")) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F494.PATHNAME;12
 
 (setq s (open "/etc/getty")) @EV <stream>                    
 
******************************
DUA1:[CHAPMAN.STANDARD]F629.STREAM-ELEMENT-TYPE;8
 
 (setq s (open "tempfile.temp" 
 
******************************
DUA1:[CHAPMAN.STANDARD]F685.TRUENAME;8
 
 (setq s (open "/etc/passwd")) @EV <stream>
 (setq file (open "CMUC::DOC:DUMPER.HLP"))
 
******************************
DUA1:[CHAPMAN.STANDARD]F822.HANDLER-CASE;6
 
      (handler-case (open *the-file* :direction :input)
 
******************************
DUA1:[CHAPMAN.STANDARD]F492.PARSE-INTEGER;14
 
 (parse-integer "123") @EV 123 3
 (parse-integer "123" :start 1 :radix 5) @EV 13 3
 (parse-integer "no-integer" :junk-allowed t) @EV NIL 0
 
******************************
DUA1:[CHAPMAN.STANDARD]F451.NAMESTRING;17
 
 (merge-pathnames (parse-namestring pathname nil defaults) defaults)
 
******************************
DUA1:[CHAPMAN.STANDARD]F493.PARSE-NAMESTRING;15
 
 (setq q (parse-namestring "/etc/getty"))  @EV <pathname>
 (parse-namestring "getty") @EV <pathname> 5
 (parse-namestring s) @EV <pathname> 0
 (parse-namestring "/usr/include/sys/types.h" nil nil :start 6 :end 15 )
 (parse-namestring s nil nil :start 5 :end 12 ) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F497.PATHNAME-HOST;10
 
 (pathname-host q) @EV "edsel"
 (pathname-host "/user/temp/a:b:c") @EV "/user/temp/a"
 (pathname-host "::/user/temp/a:b:c") @EV ""
 
******************************
DUA1:[CHAPMAN.STANDARD]F404.MAKE-PATHNAME;10
 
                            (pathname-directory *default-pathname-defaults*)))
 (pathnamep q) @EV\ true
                 :directory (pathname-directory *default-pathname-defaults*)\kern-5pt
 (make-pathname :directory (pathname-directory *default-pathname-defaults*)\kern-5pt
 
******************************
DUA1:[CHAPMAN.STANDARD]F451.NAMESTRING;17
 
                           (pathname-directory *default-pathname-defaults*)\kern-4pt
 
******************************
DUA1:[CHAPMAN.STANDARD]F493.PARSE-NAMESTRING;15
 
 (pathnamep q) @EV true
 
******************************
DUA1:[CHAPMAN.STANDARD]F494.PATHNAME;12
 
 (pathname "/etc/getty")  @EV <pathname>
 (setq p (pathname "/etc/getty")) @EV <pathname>
 (pathnamep p) @EV true
 (eq p (pathname p))                                  ;no conversion 
 (eq (pathname "/etc/getty") (pathname "/etc/getty"))   ;creates new 
 (pathname s) @EV <pathname>
 
******************************
DUA1:[CHAPMAN.STANDARD]F497.PATHNAME-HOST;10
 
 (pathname-directory "chase.c") @EV (:RELATIVE)
 (pathname-version "chase.c") @EV NIL
 (pathname-host q) @EV "edsel"
 (pathname-directory q) @EV "usr" "src")
 (pathname-name q) @EV "chase"
 (pathname-type q) @EV "c"
 (pathname-host "/user/temp/a:b:c") @EV "/user/temp/a"
 (pathname-device "/user/temp/a:b:c") @EV "b"
 (pathname-directory "/user/temp/a:b:c") @EV (:RELATIVE)
 (pathname-name "/user/temp/a:b:c") @EV "c"
 (pathname-host "::/user/temp/a:b:c") @EV ""
 (pathname-device "::/user/temp/a:b:c") @EV ""
 (pathname-directory "::/user/temp/a:b:c") @EV ("user" "temp")
 (pathname-name "::/user/temp/a:b:c") @EV "a:b:c"
 
******************************
DUA1:[CHAPMAN.STANDARD]F501.PATHNAMEP;6
 
 (pathnamep q) @EV\ NIL
 (setq q (pathname "/etc/getty")) @EV\ <pathname>
 (pathnamep q) @EV\ true 
(pathnamep x) @EQ (typep x 'pathname)
 
******************************
DUA1:[CHAPMAN.STANDARD]F685.TRUENAME;8
 
 (namestring (pathname file)) @ev "CMUC::DOC:DUMPER.HLP"
 
******************************
DUA1:[CHAPMAN.STANDARD]F700.USER-HOMEDIR-PATHNAME;8
 
 (pathnamep (user-homedir-pathname)) @EV\ true
 
******************************
DUA1:[CHAPMAN.STANDARD]F342.LAST;8
 
     (if (>= i n) (pop r))))
 
******************************
DUA1:[CHAPMAN.STANDARD]F506.POP;12
 
 (pop (car llst)) @EV 1
 (pop stack) @EV a  and now stack @EV (b c)
The effect of @f[(pop place)] is roughly equivalent to
 
******************************
DUA1:[CHAPMAN.STANDARD]F507.POSITION;15
 
 (position #\\a "baobab" :from-end t) @EV 4
 (position-if #'oddp '((1) (2) (3) (4)) :start 1 :key #'car) @EV 2
 (position 595 '()) @EV NIL
 (position-if-not #'integerp '(1 2 3 4 5.0)) @EV 4 
 
******************************
DUA1:[CHAPMAN.STANDARD]F753.KEYSTART;4
 
(position \#{\char '134}b "foobar" {\keyword :start}  2 {\keyword :end} 5) @EV 3
(position \#{\char '134}b (subseq "foobar" 2 5)) @EV 1
 
******************************
DUA1:[CHAPMAN.STANDARD]F206.DEFCONSTANT;13
 
 (proclaim '(special name))
 
******************************
DUA1:[CHAPMAN.STANDARD]F210.DEFPARAMETER;13
 
 (proclaim '(special ',name))
 
******************************
DUA1:[CHAPMAN.STANDARD]F215.DEFVAR;15
 
 (proclaim '(special ,name))
 
******************************
DUA1:[CHAPMAN.STANDARD]F527.PROCLAIM;12
 
 (proclaim '(type float tolerance))
 (proclaim '(inline floor))
 (proclaim '(special x))
 (proclaim '(declaration author
 (proclaim '(target-language ada))
 (proclaim '(target-machine IBM-650))
 (proclaim '(special prosp))   @EV undefined
 (proclaim '(special x))		;x is always special.
 
******************************
DUA1:[CHAPMAN.STANDARD]F583.ROTATEF;9
 
(psetf @i[place1] @i[place2]
 
******************************
DUA1:[CHAPMAN.STANDARD]F599.SETF;25
 
 (psetf (car x) 'x (cadr y) (car x) (cdr x) y) @EV NIL 
 
******************************
DUA1:[CHAPMAN.STANDARD]F944.WITH-SLOTS;3
 
     (psetf x1 x2
 
******************************
DUA1:[CHAPMAN.STANDARD]S4100.EVALUATION-MODEL;39
 
     (push \#'(lambda (z)                        
       (push (function (lambda (z)
       (push (function (lambda (z) (+ x z)))
     (push (function (lambda (z) (+ 5 z)))
 
******************************
DUA1:[CHAPMAN.STANDARD]S5400.GENERALIZED-REFERENCE;19
 
 (push value (wrong-order place1 place2))
  (push (progn (princ "1") 'ref-1)
    (push (setq x (list 'a))
 
******************************
DUA1:[CHAPMAN.STANDARD]F207.DEFINE-MODIFY-MACRO;16
 
 (push value (wrong-order place1 place2))                     
 
******************************
DUA1:[CHAPMAN.STANDARD]F232.DO-SYMBOLS;10
 
    (do-symbols (s 'temp) (push s lst))
    (do-external-symbols (s 'temp lst) (push s lst))) @EV (TEMP:BOLD)
      (when (eq (find-package 'temp) (symbol-package s)) (push s lst))))
 
******************************
DUA1:[CHAPMAN.STANDARD]F234.DOLIST;11
 
 (dolist (temp-one '(1 2 3 4) temp-two) (push temp-one temp-two)) @EV\ (4 3 2 1)
 
******************************
DUA1:[CHAPMAN.STANDARD]F304.GET;10
 
 (push item (get sym 'token-stack '(initial-item)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F315.GETF;15
 
 (push value (wrong-order place1 place2))
 
******************************
DUA1:[CHAPMAN.STANDARD]F327.INCF;12
 
 (push value (wrong-order place1 place2))
 
******************************
DUA1:[CHAPMAN.STANDARD]F414.MAP;10
 
 (mapl \#'(lambda (x) (push x dummy)) '(1 2 3 4)) @EV\ (1 2 3 4) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F506.POP;12
 
 (push value (wrong-order place1 place2))
 
******************************
DUA1:[CHAPMAN.STANDARD]F537.PUSH;12
 
 (push value (wrong-order place1 place2))
 (push 1 (car llst)) @EV (1)
 (push 1 (car llst)) @EV (1 1)
 (push 5 (cadr x)) @EV (5 b c)  and now x @EV (a (5 b c) d)
The effect of @f[(push @i[item] @i[place])]
 
******************************
DUA1:[CHAPMAN.STANDARD]F538.PUSHNEW;13
 
 (push value (wrong-order place1 place2))
 (pushnew '(2) lst) @EV ((2) (1) (1 2) (1 2 3))
 (pushnew '(1) lst) @EV ((1) (2) (1) (1 2) (1 2 3))
 (pushnew '(1) lst :test 'equal) @EV ((1) (2) (1) (1 2) (1 2 3))
 (pushnew '(1) lst :key #'car) @EV ((1) (2) (1) (1 2) (1 2 3)) 
 (pushnew 5 (cadr x)) @EV (5 b c)   and now x @EV (a (5 b c) d)
 (pushnew 'b (cadr x)) @EV (5 b c)  and x is unchanged
 (pushnew item place @Kwd[:test] p)
 
******************************
DUA1:[CHAPMAN.STANDARD]F566.REMF;11
 
 (push value (wrong-order place1 place2))
 
******************************
DUA1:[CHAPMAN.STANDARD]F583.ROTATEF;9
 
 (push value (wrong-order place1 place2))
 
******************************
DUA1:[CHAPMAN.STANDARD]F599.SETF;25
 
 (push value (wrong-order place1 place2))
 
******************************
DUA1:[CHAPMAN.STANDARD]F604.SHIFTF;12
 
 (push value (wrong-order place1 place2))
 
******************************
DUA1:[CHAPMAN.STANDARD]F807.CCASE;6
 
 (push value (wrong-order place1 place2))
 
******************************
DUA1:[CHAPMAN.STANDARD]F810.CHECK-TYPE;8
 
 (push value (wrong-order place1 place2))
 
******************************
DUA1:[CHAPMAN.STANDARD]F813.CTYPECASE;8
 
 (push value (wrong-order place1 place2))
 
******************************
DUA1:[CHAPMAN.STANDARD]F922.MAKE-INSTANCE;8
 
%	 	 (push (car plist) keys)))
 
******************************
DUA1:[CHAPMAN.STANDARD]FIND.EXA;2
 
      (when (eq (find-package 'temp) (symbol-package s)) (push s lst))))
 
******************************
DUA1:[CHAPMAN.STANDARD]F538.PUSHNEW;13
 
 (pushnew '(2) lst) @EV ((2) (1) (1 2) (1 2 3))
 (pushnew '(1) lst) @EV ((1) (2) (1) (1 2) (1 2 3))
 (pushnew '(1) lst :test 'equal) @EV ((1) (2) (1) (1 2) (1 2 3))
 (pushnew '(1) lst :key #'car) @EV ((1) (2) (1) (1 2) (1 2 3)) 
 (pushnew 5 (cadr x)) @EV (5 b c)   and now x @EV (a (5 b c) d)
 (pushnew 'b (cadr x)) @EV (5 b c)  and x is unchanged
 (pushnew item place @Kwd[:test] p)
 
******************************
DUA1:[CHAPMAN.STANDARD]F544.RASSOC;12
 
 (rassoc 3 alist) @EV (3 . 3)
 (rassoc "two" alist) @EV NIL
 (rassoc "two" alist :test 'equal) @EV (2 . "two")
 (rassoc 1 alist :key #'(lambda (x) (if (numberp x) (/ x 3)))) @EV (3 . 3)
 (rassoc 'a '((a . b) (b . c) (c . a) (z . a))) @EV (c . a)
 (rassoc-if #'stringp alist) @EV (1 . "one")
 (rassoc-if-not #'vectorp alist) @EV (3 . 3)
 (rassoc item list :test fn)
 
******************************
DUA1:[CHAPMAN.STANDARD]F557.READ-FROM-STRING;12
 
 (read-from-string " 1 3 5" t nil :start 2) @EV 3 5
 (read-from-string "(a b c)") @EV (a b c) and 7
 
******************************
DUA1:[CHAPMAN.STANDARD]F049.ARRAY-TOTAL-SIZE;11
 
   @EQ\ (reduce #'* (array-dimensions x))
 
******************************
DUA1:[CHAPMAN.STANDARD]F212.DEFSTRUCT;28
 
 (reduce #'+ astros :key #'person-age) ; obtains the total of the ages 
 
******************************
DUA1:[CHAPMAN.STANDARD]F564.REDUCE;12
 
 (reduce #'* '(1 2 3 4 5)) @EV 120
 (reduce #'append '((1) (2)) :initial-value '(i n i t)) @EV (I N I T 1 2)
 (reduce #'append '((1) (2)) :from-end t                  
 (reduce #'+ '(1 2 3 4)) @ev 10
 (reduce #'- '(1 2 3 4)) @eq (- (- (- 1 2) 3) 4) @ev -8
 (reduce #'- '(1 2 3 4) :from-end t)	;Alternating sum.
 (reduce #'+ '()) @ev 0
 (reduce #'+ '(3)) @ev 3
 (reduce #'+ '(foo)) @ev foo
 (reduce #'list '(1 2 3 4)) @ev (((1 2) 3) 4)
 (reduce #'list '(1 2 3 4) :from-end t) @ev (1 (2 (3 4)))
 (reduce #'list '(1 2 3 4) :initial-value 'foo) @ev ((((foo 1) 2) 3) 4)
 (reduce #'list '(1 2 3 4)
 
******************************
DUA1:[CHAPMAN.STANDARD]F922.MAKE-INSTANCE;8
 
%	       (reduce #'union (mapcar #'function-keywords methods))))
 
******************************
DUA1:[CHAPMAN.STANDARD]F566.REMF;11
 
 (remf (car x) 'prop1) @EV true
 (remf (car x) 'prop1) @EV NIL
 
******************************
DUA1:[CHAPMAN.STANDARD]F572.REMPROP;8
 
 (remprop x y) @EQ\ (remf (symbol-plist x) y)
 
******************************
DUA1:[CHAPMAN.STANDARD]F569.REMOVE-DUPLICATES;14
 
 (remove-duplicates "aBcDAbCd" :test #'char-equal :from-end t) @EV "aBcD"
 (remove-duplicates '(a b c b d d e)) @EV (a c b d e)
 (remove-duplicates '(a b c b d d e) :from-end t) @EV (a b c d e)
 (remove-duplicates '((foo #\\a) (bar #\\%) (baz #\\A))
 (remove-duplicates '((foo #\\a) (bar #\\%) (baz #\\A))
 
******************************
DUA1:[CHAPMAN.STANDARD]F925.METHOD-QUALIFIERS;3
 
(setq methods (remove-duplicates methods
 
******************************
DUA1:[CHAPMAN.STANDARD]S3100.CHARACTER-READER;48
 
{\tt (remove-if \#'numberp '(1 a b 3))}
{\tt (remove-if (function numberp) '(1 a b 3))}
 
******************************
DUA1:[CHAPMAN.STANDARD]S6100.INTRODUCTION;53
 
{\tt (remove {\arg item} {\arg sequence})}
{\tt (remove-if \#'numberp {\arg sequence})}
 
******************************
DUA1:[CHAPMAN.STANDARD]F235.DOTIMES;10
 
 (remove-if-not \#'alpha-char-p		;Remove punctuation.
  (remove-if-not \#'alpha-char-p
  (remove-if-not
  (remove-if-not
 
******************************
DUA1:[CHAPMAN.STANDARD]F568.REMOVE;14
 
 (remove 4 '(1 3 4 5 9)) @EV (1 3 5 9)
 (remove-if-not #'evenp '(1 2 3 4 5 6 7 8 9) :count 2 :from-end t)
 (remove 4 '(1 2 4 1 3 4 5)) @EV (1 2 1 3 5)
 (remove 4 '(1 2 4 1 3 4 5) :count 1) @EV (1 2 1 3 4 5)
 (remove 4 '(1 2 4 1 3 4 5) :count 1 :from-end t) @EV (1 2 4 1 3 5)
 (remove 3 '(1 2 4 1 3 4 5) :test #'>) @EV (4 3 4 5)
 (remove-if #'oddp '(1 2 4 1 3 4 5)) @EV (2 4 4)
 (remove-if #'evenp '(1 2 4 1 3 4 5) :count 1 :from-end t) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F569.REMOVE-DUPLICATES;14
 
 (remove-duplicates "aBcDAbCd" :test #'char-equal :from-end t) @EV "aBcD"
 (remove-duplicates '(a b c b d d e)) @EV (a c b d e)
 (remove-duplicates '(a b c b d d e) :from-end t) @EV (a b c d e)
 (remove-duplicates '((foo #\\a) (bar #\\%) (baz #\\A))
 (remove-duplicates '((foo #\\a) (bar #\\%) (baz #\\A))
 
******************************
DUA1:[CHAPMAN.STANDARD]F750.TESTKEYWORD;4
 
(remove @i[item] @i[sequence])
(remove @i[item] @i[sequence] @Kwd[test] #'equal)
 
******************************
DUA1:[CHAPMAN.STANDARD]F925.METHOD-QUALIFIERS;3
 
(setq methods (remove-duplicates methods
 
******************************
DUA1:[CHAPMAN.STANDARD]F573.RENAME-FILE;9
 
 (rename-file "/tmp/rename-test.a" "rename-test.b") @EV
 
******************************
DUA1:[CHAPMAN.STANDARD]S5400.GENERALIZED-REFERENCE;19
 
{\tt (progn (replace g0004 g0007 :start1 g0005 :end1 g0006) }& \cr
 
******************************
DUA1:[CHAPMAN.STANDARD]F211.DEFSETF;12
 
   `(progn (replace ,sequence ,new-sequence
 
******************************
DUA1:[CHAPMAN.STANDARD]F575.REPLACE;11
 
 (replace "abcdefghij" "0123456789" :start1 4 :end1 7 :start2 4) 
 (replace lst lst :start1 2 :start2 0) @EV "010123456"
 
******************************
DUA1:[CHAPMAN.STANDARD]F750.ROW-MAJOR-AREF;2
 
 (row-major-aref array index) @EV
     (row-major-aref array (array-row-major-index array .. subscripts ..))
 
******************************
DUA1:[CHAPMAN.STANDARD]F590.SEARCH;13
 
 (search "dog" "it's a dog's life") @EV 7
 (search '(0 1) '(2 4 6 1 3 5) :key #'oddp) @EV 2
 
******************************
DUA1:[CHAPMAN.STANDARD]S2300.TYPES;40
 
(setf (gethash 'color a) 'brown)
(setf (gethash 'name a) 'fred)
 
******************************
DUA1:[CHAPMAN.STANDARD]S2500.OBJECT-CONCEPTS;7
 
there is also a method for {\tt (setf C2-S3)} that writes the
 
******************************
DUA1:[CHAPMAN.STANDARD]S2700.OBJECT-ACCESS;3
 
the list {\tt (setf {\it name\/})}.
 
******************************
DUA1:[CHAPMAN.STANDARD]S5100.ERRORS;39
 
     (setf (symbol-value variable) value)
 
******************************
DUA1:[CHAPMAN.STANDARD]S5400.GENERALIZED-REFERENCE;19
 
{\tt x }&{\tt  (setq x datum) }&{\tt  (setf x datum) }\cr
{\tt (car x) }&{\tt  (rplaca x datum) }&{\tt  (setf (car x) datum) }\cr
{\tt (symbol-value x) }&{\tt  (set x datum) }&{\tt  (setf (symbol-value x) datum) }\cr
 (setf place1 value1 place2 value2 ...)
{\tt (setf {\arg reference} {\arg value})}
 
******************************
DUA1:[CHAPMAN.STANDARD]F039.AREF;17
 
 (setf (aref ta 3) 'sirens) @EV\ SIRENS
 
******************************
DUA1:[CHAPMAN.STANDARD]F062.BIT;17
 
 (setf (bit ba 3) 0) @EV 0
 (setf (sbit ba 5) 1) @EV 1
 
******************************
DUA1:[CHAPMAN.STANDARD]F137.CHAR;12
 
{\tt (setf (schar simp-str 2) \#{\char '134}C) @EV\ \#{\char '134}C}
 
******************************
DUA1:[CHAPMAN.STANDARD]F138.CHAR-BIT;11
 
{\tt     (setf (char-bit tmp :hyper) t)}
 
******************************
DUA1:[CHAPMAN.STANDARD]F172.CLRHASH;8
 
 (dotimes (i 100) (setf (gethash i h) i)) @EV\ NIL
 
******************************
DUA1:[CHAPMAN.STANDARD]F176.COMPILE;13
 
 (setf (symbol-function 'foo)
 
******************************
DUA1:[CHAPMAN.STANDARD]F188.COPY-ALIST;9
 
 (setf (cdr (assoc 2 calist)) "deux") @EV\ "deux"
 (setf (cdr (assoc 1 clist)) "uno") @EV\ "uno"
 
******************************
DUA1:[CHAPMAN.STANDARD]F189.COPY-LIST;9
 
 (setf (caadr lst) "two") @EV\ "two"
 
******************************
DUA1:[CHAPMAN.STANDARD]F193.COPY-TREE;8
 
 (setf (cadadr lst) "a"
 
******************************
DUA1:[CHAPMAN.STANDARD]F206.DEFCONSTANT;13
 
 (setf (symbol-value 'name) initial-value)
 (setf (documentation ',name 'variable) 'doc-str)
 
******************************
DUA1:[CHAPMAN.STANDARD]F207.DEFINE-MODIFY-MACRO;16
 
   @bq(setf ,reference
 
******************************
DUA1:[CHAPMAN.STANDARD]F208.DEFINE-SETF-METHOD;17
 
 (setf (lastguy a) 3) @EV 3
 (setf (lastguy b) 7) @EV 7
 (setf (lastguy (lastguy c)) 'lastguy-symbol) @EV LASTGUY-SYMBOL
     `(setf (car ,x) ,value))
 
******************************
DUA1:[CHAPMAN.STANDARD]F210.DEFPARAMETER;13
 
 (setf (symbol-name ',name) initial-value)
 (setf (documentation ',name 'var) 'doc-str)
 
******************************
DUA1:[CHAPMAN.STANDARD]F211.DEFSETF;12
 
This causes the form @f[(setf (symbol-value foo) fu)]
 (setf (middleguy a) 3) @EV 3
 (setf (middleguy b) 7) @EV 7
 (setf (middleguy (middleguy c)) 'middleguy-symbol) @EV MIDDLEGUY-SYMBOL
 
******************************
DUA1:[CHAPMAN.STANDARD]F212.DEFSTRUCT;28
 
 (setf (door-width my-door) 43.7)
 (setf (town-population town1) 99)         ;setf recognizes access 
 (setf (ship-x-position ship2) 100)
 
******************************
DUA1:[CHAPMAN.STANDARD]F215.DEFVAR;15
 
 (setf (symbol-value 'name) initial-value) ;if not BOUNDP
 (setf (documentation ',name 'variable) 'doc-string)
 
******************************
DUA1:[CHAPMAN.STANDARD]F229.DO-DOSTAR;16
 
    (setf (aref a-vector i) 0)))
%    (setf (aref a-vector i) 0)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F243.ELT;12
 
 (setf (elt str 0) \#\\\#) @EV\ \#\\\#
 
******************************
DUA1:[CHAPMAN.STANDARD]F274.FILL-POINTER;8
 
 (setf (fill-pointer fa) 0) @EV 0
 
******************************
DUA1:[CHAPMAN.STANDARD]F282.FIRST;7
 
 (setf (fourth lst) "four") @EV\ "four"
 
******************************
DUA1:[CHAPMAN.STANDARD]F304.GET;10
 
 (setf (get *symbol* *indicator*) *value*) @EV\ <symbol name>
 (setf (get 'clyde 'species) 'elephant) @EV\ elephant
 (setf (get sym 'token-stack '(initial-item))
 (setf (get sym 'token-stack)
 
******************************
DUA1:[CHAPMAN.STANDARD]F311.GET-PROPERTIES;8
 
 (setf (getf (car x) 'prop1) 'val1) @EV\ VAL1
 
******************************
DUA1:[CHAPMAN.STANDARD]F315.GETF;15
 
 (setf (getf (car x) 'prop1) 'val1) @EV VAL1
 
******************************
DUA1:[CHAPMAN.STANDARD]F316.GETHASH;9
 
 (setf (gethash 1 h) "one") @EV\ "one"
 (setf (gethash 'nil h "ignored default") nil) @EV\ NIL
 (setf (gethash a-key table 0) (+ (gethash a-key table 0) 1))
 (setf (gethash a-key table) (+ (gethash a-key table 0) 1))
 
******************************
DUA1:[CHAPMAN.STANDARD]F319.HASH-TABLE-COUNT;6
 
 (setf (gethash 57 h) "57") @EV\ "57"
 (dotimes (i 100) (setf (gethash i h) i)) @EV\ NIL
 
******************************
DUA1:[CHAPMAN.STANDARD]F327.INCF;12
 
(setf place (+ place delta))
 
******************************
DUA1:[CHAPMAN.STANDARD]F344.LDB;10
 
 (setf (ldb (byte 2 1) (car a)) 1) @EV 1
 
******************************
DUA1:[CHAPMAN.STANDARD]F355.LENGTH;9
 
 (setf (fill-pointer str) 2) @EV\ 2
 
******************************
DUA1:[CHAPMAN.STANDARD]F390.MACRO-FUNCTION;13
 
 (and (setf (macro-function 'macfun) #'equal)
 (setf (macro-function 'bar env) ...) is an error.
(setf (macro-function symbol) fn)
 
******************************
DUA1:[CHAPMAN.STANDARD]F401.MAKE-HASH-TABLE;12
 
 (setf (gethash "one" h) 1) @EV\ 1
 (setf (gethash "one" h) 1) @EV\ 1
 
******************************
DUA1:[CHAPMAN.STANDARD]F419.MAPHASH;8
 
 (dotimes (i 10) (setf (gethash i h) i)) @EV\ NIL
                   (setf (gethash key my-hash-table)
 
******************************
DUA1:[CHAPMAN.STANDARD]F422.MASK-FIELD;10
 
 (setf (mask-field (byte 2 0) a) 1) @EV\ 1
 
******************************
DUA1:[CHAPMAN.STANDARD]F474.NTH;7
 
 (setf (nth 2 lst) "two") @EV\ "two"
 
******************************
DUA1:[CHAPMAN.STANDARD]F506.POP;12
 
 (prog1 (car place) (setf place (cdr place)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F519.PRINT-CIRCLE;11
 
         (setf (cdddr a) a)                      ;create a circular list
 
******************************
DUA1:[CHAPMAN.STANDARD]F537.PUSH;12
 
 (setf place (cons item place))
 
******************************
DUA1:[CHAPMAN.STANDARD]F538.PUSHNEW;13
 
 (setf place (adjoin item place @Kwd[:test] p))
 
******************************
DUA1:[CHAPMAN.STANDARD]F566.REMF;11
 
 (setf (getf (car x) 'prop1) 'val1) @EV VAL1
 
******************************
DUA1:[CHAPMAN.STANDARD]F567.REMHASH;6
 
 (setf (gethash 100 h) "C") @EV\ C"
 
******************************
DUA1:[CHAPMAN.STANDARD]F572.REMPROP;8
 
 (setf (get *symbol* 'prop1) 'val1) @EV\ VAL1
 
******************************
DUA1:[CHAPMAN.STANDARD]F577.REST;6
 
 (setf (rest cns) "two") @EV\ "two"
 
******************************
DUA1:[CHAPMAN.STANDARD]F599.SETF;25
 
@f[(setf)]\rm: @nil.
@f[(setf place newvalue)] 
 (setf @i[place1] @i[newvalue1]
 (progn (setf @i[place1] @i[newvalue1])
        (setf @i[place2] @i[newvalue2])
        (setf @i[placen] @i[newvaluen]))
 (setf place1 value1 place2 value2 ...)
 (setf (the integer (cadr x)) (+ y 3))
 (setf (cadr x) (the integer (+ y 3)))
 (setf (apply #'@i[name] @i[x1] @i[x2] ... @i[xn] @i[rest]) @i[x0])
 (setf (@i[name] @i[z1] @i[z2] ... @i[zm]) @i[z0])
 (setf (apply #'aref foo indexes) newvalue)
 (setf (car x) 'x (cadr y) (car x) (cdr x) y) @EV (1 X 3) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F604.SHIFTF;12
 
   (setf @i[place1] @i[var2])
   (setf @i[place2] @i[var3])
   (setf @i[placen] @i[newvalue])
 	(setf (nth (setq n (+ n 1)) x) 'z)) @EV b
 
******************************
DUA1:[CHAPMAN.STANDARD]F653.SUBSEQ;14
 
 (setf (subseq str 4) "abc") @EV "abc"
 (setf (subseq str 0 2) "A") @EV "A"
 
******************************
DUA1:[CHAPMAN.STANDARD]F662.SVREF;10
 
 (setf (svref v 1) 'newcomer) @EV\ NEWCOMER               
 
******************************
DUA1:[CHAPMAN.STANDARD]F664.SYMBOL-FUNCTION;8
 
 (setf (symbol-function 'dummy-function)
 
******************************
DUA1:[CHAPMAN.STANDARD]F667.SYMBOL-PLIST;8
 
 (setf (get *sym* 'prop1) 'val1) @EV\ VAL1
 (setf (get *sym* 'prop2) 'val2) @EV\ VAL2
 (setf (symbol-plist *sym*) '(prop3 val3)) @EV\ (PROP3 VAL3)
 
******************************
DUA1:[CHAPMAN.STANDARD]F668.SYMBOL-VALUE;7
 
   (setf (symbol-value 'a) 3)
 
******************************
DUA1:[CHAPMAN.STANDARD]F678.THE;8
 
    (setf (the fixnum (car x)) y)) @EV\ 5 ;Implies y is a fixnum 
 
******************************
DUA1:[CHAPMAN.STANDARD]F903.CHANGE-CLASS;8
 
    (setf (slot-value new 'rho) (sqrt (+ (* x x) (* y y)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F941.UPDATE-INSTANCE-FOR-REDEFINED-CLASS;7
 
    (setf (position-rho pos) (sqrt (+ (* x x) (* y y)))
(defmethod (setf position-x) (new-x (pos x-y-position))
(defmethod (setf position-y) (new-y (pos x-y-position))
 
******************************
DUA1:[CHAPMAN.STANDARD]F487.PACKAGE-SHADOWING-SYMBOLS;8
 
 (shadow 'cdr 'temp) @EV T
 (shadowing-import 'pill 'temp) @EV T
 
******************************
DUA1:[CHAPMAN.STANDARD]F602.SHADOW;9
 
 (shadow 'car 'temp) @EV T
 (shadow 'test-1::test (find-package 'test-1))
 (shadow 'TEST (find-package 'test-1))
 
******************************
DUA1:[CHAPMAN.STANDARD]F603.SHADOWING-IMPORT;9
 
 (shadowing-import sym 'temp) @EV T 
 
******************************
DUA1:[CHAPMAN.STANDARD]FIND.EXA;2
 
 (shadow 'test-1::test (find-package 'test-1))
 (shadow 'TEST (find-package 'test-1))
 
******************************
DUA1:[CHAPMAN.STANDARD]F604.SHIFTF;12
 
In the form @f[(shiftf @i[place1] @i[place2] ... @i[placen] @i[newvalue])]\rm,
The effect of @f[(shiftf @i[place1] @i[place2] ... @i[placen] @i[newvalue])]
 (shiftf y x (cdr x) '(hi there)) @EV TRASH
 (shiftf (cadr x) 'z) @EV b
 (shiftf (cadr x) (cddr x) 'q) @EV z
 (shiftf (nth (setq n (+ n 1)) x) 'z) @EV b
 
******************************
DUA1:[CHAPMAN.STANDARD]F644.STRING-UPCASE;10
 
 (string-upcase "abcde") @EV "ABCDE"
 (string-upcase "Dr. Livingston, I presume?")
 (string-upcase "Dr. Livingston, I presume?" @Kwd[:start] 6 @Kwd[:end] 10)
 
******************************
DUA1:[CHAPMAN.STANDARD]S4100.EVALUATION-MODEL;39
 
          :initial-element (subseq str start end)
 
******************************
DUA1:[CHAPMAN.STANDARD]S5400.GENERALIZED-REFERENCE;19
 
For {\tt (subseq {\arg seq s e})}:
{\tt (subseq g0004 g0005 g0006)         }&{\tt  ; accessing form} \cr
 
******************************
DUA1:[CHAPMAN.STANDARD]F136.CERROR;11
 
	   (setq vals (append vals (subseq '(0 0 0) nvals 3))))
	     (setq vals (subseq vals 0 3))))))
 
******************************
DUA1:[CHAPMAN.STANDARD]F191.COPY-SEQ;10
 
(copy-seq x) @EQ\ (subseq x 0)
 
******************************
DUA1:[CHAPMAN.STANDARD]F653.SUBSEQ;14
 
 (subseq str 2) @EV "2345"
 (subseq str 3 5) @EV "34"
 (setf (subseq str 4) "abc") @EV "abc"
 (setf (subseq str 0 2) "A") @EV "A"
 
******************************
DUA1:[CHAPMAN.STANDARD]F753.KEYSTART;4
 
(position \#{\char '134}b (subseq "foobar" 2 5)) @EV 1
 
******************************
DUA1:[CHAPMAN.STANDARD]F658.SUBSTITUTE;14
 
 (substitute #\\. #\\SPACE "0 2 4 6") @EV "0.2.4.6"
 (substitute-if 0 #'evenp '((1) (2) (3) (4)) :start 2 :key #'car)
 (substitute 9 4 '(1 2 4 1 3 4 5)) @EV (1 2 9 1 3 9 5)
 (substitute 9 4 '(1 2 4 1 3 4 5) :count 1) @EV (1 2 9 1 3 4 5)
 (substitute 9 4 '(1 2 4 1 3 4 5) :count 1 :from-end t)
 (substitute 9 3 '(1 2 4 1 3 4 5) :test #'>) @EV (9 9 4 9 3 4 5)
 (substitute-if 9 #'oddp '(1 2 4 1 3 4 5)) @EV (9 2 4 9 9 4 9)
 (substitute-if 9 #'evenp '(1 2 4 1 3 4 5) :count 1 :from-end t)
 
******************************
DUA1:[CHAPMAN.STANDARD]F481.OPEN;14
 
 (truename s) @EV <pathname> 
 
******************************
DUA1:[CHAPMAN.STANDARD]F685.TRUENAME;8
 
 (truename s) @EV <pathname>
 (truename "bin") @EV <pathname>
 (namestring (truename file))
 
******************************
DUA1:[CHAPMAN.STANDARD]F169.CLEAR-INPUT;14
 
 (with-input-from-string (in-stream "1 2 3")
 
******************************
DUA1:[CHAPMAN.STANDARD]F200.DEBUG-IO;10
 
   (with-input-from-string (in "enter > ")
 
******************************
DUA1:[CHAPMAN.STANDARD]F412.MAKE-TWO-WAY-STREAM;7
 
    (with-input-from-string (in "input...")
 
******************************
DUA1:[CHAPMAN.STANDARD]F502.PEEK-CHAR;11
 
 (with-input-from-string (is "    1 2 3 4 5")
 
******************************
DUA1:[CHAPMAN.STANDARD]F550.READ;13
 
 (with-input-from-string (is " ") (read is nil 'the-end)) @EV\ THE-END
    (with-input-from-string (is "#{123 x #}123 y")
 
******************************
DUA1:[CHAPMAN.STANDARD]F554.READ-CHAR;8
 
 (with-input-from-string (is "0123")
 
******************************
DUA1:[CHAPMAN.STANDARD]F626.STANDARD-INPUT;8
 
 (with-input-from-string (*standard-input* "1001")
 
******************************
DUA1:[CHAPMAN.STANDARD]F694.UNREAD-CHAR;9
 
 (with-input-from-string (is "0123")
 
******************************
DUA1:[CHAPMAN.STANDARD]F710.WITH-INPUT-FROM-STRING;11
 
 (with-input-from-string (s "XXX1 2 3 4xxx"
 (with-input-from-string (s "Animal Crackers" :index j :start 6)
 
******************************
DUA1:[CHAPMAN.STANDARD]F218.DELETE-FILE;9
 
 (with-open-file (s "/tmp/delete-test" :if-does-not-exist :create) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F552.READ-BYTE;7
 
 (with-open-file (s "temp-bytes" 
 (with-open-file (s "temp-bytes" :element-type 'unsigned-byte)
 
******************************
DUA1:[CHAPMAN.STANDARD]F573.RENAME-FILE;9
 
 (with-open-file (s "/tmp/rename-test.a" :if-does-not-exist :create) 
 
******************************
DUA1:[CHAPMAN.STANDARD]F711.WITH-OPEN-FILE;10
 
 (with-open-file (s p :direction :output :if-exists :supersede)
 (with-open-file (s p)
 (with-open-file (ifile name :direction :input)
   (with-open-file (ofile (merge-pathname-defaults ifile
 
******************************
DUA1:[CHAPMAN.STANDARD]F715.WRITE-BYTE;6
 
 (with-open-file (s "temp-bytes" 
 
******************************
DUA1:[CHAPMAN.STANDARD]F310.GET-OUTPUT-STREAM-STRING;10
 
 (write-string a-string a-stream) @EV\ "abcdefghijklm"
 
******************************
DUA1:[CHAPMAN.STANDARD]F718.WRITE-STRING;12
 
 (write-string "beans") @EV beans "beans"
 
******************************
DUA1:[CHAPMAN.STANDARD]F815.DEFINE-CONDITION;6
 
  (write-string report stream))
 
******************************
DUA1:[CHAPMAN.STANDARD]F831.RESTART-CASE;8
 
 (lambda (stream) (write-string value stream))
 
******************************
DUA1:[CHAPMAN.STANDARD]F310.GET-OUTPUT-STREAM-STRING;10
 
 (write-string a-string a-stream) @EV\ "abcdefghijklm"
 
******************************
DUA1:[CHAPMAN.STANDARD]F517.PRINT-BASE;12
 
      (write 40)                            ;in each base from 2 to 36
 
******************************
DUA1:[CHAPMAN.STANDARD]F519.PRINT-CIRCLE;11
 
 (let ((*print-circle* t)) (write a) (values))  ;print it
 
******************************
DUA1:[CHAPMAN.STANDARD]F520.PRINT-ESCAPE;10
 
 (write \#\\a) @EV\ \#\\a \#\\a
 (let ((*print-escape* nil)) (write \#\\a)) @EV\ a \#\\a
 
******************************
DUA1:[CHAPMAN.STANDARD]F524.PRINT-PRETTY;10
 
 (progn (write '(let((a 1)(b 2)(c 3))(+ a b c))) (values))
   (progn (write '(let((a 1)(b 2)(c 3))(+ a b c))) (values)))
 
******************************
DUA1:[CHAPMAN.STANDARD]F552.READ-BYTE;7
 
    (write-byte 101 s)) @EV\ 101
 
******************************
DUA1:[CHAPMAN.STANDARD]F677.TERPRI;10
 
 (write-char #\\Newline output-stream)
 
******************************
DUA1:[CHAPMAN.STANDARD]F714.WRITE;17
 
 (princ character output-stream) @EQ\ (write-char character output-stream)
 (write #\\a) @EV #\\a 
 (write '(let((a 1)(b 2))(+ a b))) @EV (LET ((A 1) (B 2)) (+ A B))
 (write '(let((a 1)(b 2))(+ a b)) :pretty t) @EV 
    (write 'write :stream s)
@EQ (write object :stream output-stream :escape t)
@EQ (write object stream output-stream :escape @false)
 
******************************
DUA1:[CHAPMAN.STANDARD]F715.WRITE-BYTE;6
 
    (write-byte 101 s)) @EV\ 101
 
******************************
DUA1:[CHAPMAN.STANDARD]F716.WRITE-CHAR;8
 
 (write-char #\\a) @EV\ a #\\a
 (with-output-to-string (s) (write-char #\\b s)) @EV\ "b"
 
******************************
DUA1:[CHAPMAN.STANDARD]F718.WRITE-STRING;12
 
 (write-string "beans") @EV beans "beans"
 (write-line "limas" *standard-output* :end 4) @EV lima "limas"
 
******************************
DUA1:[CHAPMAN.STANDARD]F719.WRITE-TO-STRING;12
 
(write-to-string x) 
   (write istream x...))
 
******************************
DUA1:[CHAPMAN.STANDARD]F815.DEFINE-CONDITION;6
 
  (write-string report stream))
 
******************************
DUA1:[CHAPMAN.STANDARD]F831.RESTART-CASE;8
 
 (lambda (stream) (write-string value stream))
 
========================================================================
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for aitg::chapman; id AB24452; Tue, 20 Dec 88 21:02:29 PST
 
========================================================================
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for aitg::chapman; id AA06031; Tue, 3 Jan 89 14:39:21 PST

∂04-Jan-89  1919	CL-Editorial-mailer 	Re: Unpredictable but Harmless    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89  19:19:14 PST
Received: from Semillon.ms by ArpaGateway.ms ; 04 JAN 89 19:00:13 PST
Date: 4 Jan 89 18:59 PST
From: masinter.pa@Xerox.COM
Subject: Re: Unpredictable but Harmless   
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 30 Dec 88
 13:47 PST
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: cl-editorial@SAIL.Stanford.EDU
Message-ID: <890104-190013-1138@Xerox>

I think the example you give is useful; perhaps "harmless" means "without
side effects that are otherwise usually implicit".

"The intent is that programmers need not worry about guarding against the
situation. You would have to guard against output going into a file
by accident, though the result would not be fatal. Additional CONSing
causing a GC that prints is an effect that the programmer must already
guard
against."

Perhaps some more examples of "harmless" effects would help put this into
focus.

∂06-Jan-89  2246	CL-Editorial-mailer 	Conformance   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:45:14 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 11:03:50 PST
Date: 6 Jan 89 11:03 PST
From: masinter.pa@Xerox.COM
Subject: Conformance
To: CL-editorial@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890106-110350-246@Xerox>

I think we might want to introduce the notion of a "portable" program, as
well as a "conformal" one. 

One of the reasons that things are stickier than Pascal, C, Fortran, is
that Lisp doesn't share the compile-execute model, and so the notion of a
"program" is much more vague. Does a Common Lisp have to have a
read-eval-print loop to be conformal?

What's a Common Lisp program? Its hard to make progress on conformance
without a good definition of "program" for LISP.

The more I think about it, I think the standard pretty much only defines
conformance for implementations, and that what "A conformal Common Lisp
program" is is one that will be executed by a conformal implementation with
no unhandled exceptions and no unspecified and potentially harmful
consequences. 

A "portable Common Lisp program" is a conformal Common Lisp program that
"works the same" in all conformal implementations. 

∂08-Jan-89  1327	CL-Editorial-mailer 	conformance & extensions issues   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  13:27:32 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 13:26:07 PST
Date: 8 Jan 89 13:25 PST
From: masinter.pa@Xerox.COM
Subject: conformance & extensions issues
To: cl-editorial@sail.stanford.edu, cl-cleanup@sail.stanford.edu 
reply-to: cl-editorial@sail.stanford.edu
Message-ID: <890108-132607-3283@Xerox>

These was in discussion on the common lisp mailing list, but it is relevant
to the conformance discussion, and probably should be split up into
separate issues. I've not the time to do so myself. There's some overlap
with a couple of cleanup issues but not much. I think these are not so much
"cleanup" issues since they have to deal with the broad policies of
conformance and extension rather than individual functions/variables, so
I'd think they should be discussed in the "editorial" forum rather than
cleanup -- unless there is strong objection.


Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
Problem:

Is it OK to define Common Lisp functions with extra optional or  keyword
parameters, with system dependent meanings?  

Proposal: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS:NO-EXCEPT-AS-ALLOWED

No, except as explicitly allowed in the standard. Functions that may be
extended to take implementation-specific optional arguments are indicated
by an &REST IGNORE in their argument list. Functions that may be extended
to take additional keyword parameters are indicated by &ALLOW-OTHER-KEYS. 

It isn't required that implementations signal errors at all safety/speed
setting, but this is not legitimate/conformal behavior.

Rationale:
The goal is not to outlaw any current extensions currently offered by
implementors, but to make the range of extensions to functions defined in
the standard well documented in the standard.  Implementations that want to
extend functions that aren't explicitly allowed to be extended can instead
shadow them.

Issue: EXTRA-SYNTAX
Problem: is it OK to extend Common Lisp macros and special forms to take
additional syntax not specified?

Proposal:  EXTRA-SYNTAX:NO

It isn't allowed.

Issue: EXTRA-RETURN-VALUES
Problem: Is it OK to return extra values from Common Lisp functions?

Proposal: No, except where explicitly allowed. The reason is that
additional arguments are visible to otherwise portable programs. "For
instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
will try to pass the wrong number of arguments to CONS if FLOOR returns an
extra value."

Issue: UNPSECIFIED-DATATYPES
Problem: Is it OK to define the behavior of functions on datatypes not
explicitly permitted in CLtL?  

Proposal: UNPSECIFIED-DATATYPES:NO-EXCEPT-AS-EXPLICITLY-ALLOWED

Example: It is currently not allowed for an implementation to define + as
operating on vectors.
 
Rationale: While the original intent of CL designers ws that
implementations be permitted to do these things, they get in the way of
portability when they're done, since it is nearly impossible to detect when
a program has used one of these features. It is simple to define a new
function 
acme-common-lisp:+ which has the behavior of the "portable" + plus all the
new whizzy features, too.


Issue: UNSOLICITED-MESSAGES
Problem: Is it legal for an implementation to produce unsolicited output,
e.g., GC notifications, autoload heralds, and progress messages from
COMPILE-FILE or LOAD?

Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS

Unsolicited messages, such as GC notifications and autoload heralds, if
they are produced by an implementation, should not be directed to
*standard-output*, *error-output*. If an implementation produces them, they
may be produced on a stream that is not "shared" with any of the streams
that a user might redefine or redirect. (This really means that it is OK to
direct such notifications to *terminal-io* since a user may not redirect
*terminal-io*.)

Messages such as progress reports from LOAD and COMPILE are "solicited",
and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.


Issue: MACRO-AS-FUNCTION
Problem: May implementations implement things documented as "macros" or
special forms be implemented as a function instead? PROG1 is the main
example, but there might be others.

Proposal: MACRO-AS-FUNCTION:YES

Things that are defined in CL as "macros" may have function definitions
instead if the semantics can be preserved. This is rare, perhaps only
restricted to

(defun prog1 (value &rest ignore) value)
(defun prog2 (value1 value2 &rest ignore) value2)

Rationale: 
There are few cases, and there doesn't seem to be a good reason to disallow
it. It doesn't seem to interfere with portability.


∂09-Jan-89  0446	CL-Editorial-mailer 	Re: Issue: SUBSETTING-POSITION (Version 1)  
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 9 Jan 89  04:46:18 PST
Received: from relay2.cs.net by RELAY.CS.NET id bg15401; 9 Jan 89 7:30 EST
Received: from utokyo-relay by RELAY.CS.NET id ae22341; 9 Jan 89 6:54 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
	id AA04765; Mon, 9 Jan 89 20:28:37 JST
Received: from kepa.cc.aoyama.junet by aoyama.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA04764; Mon, 9 Jan 89 14:52:22 JST
Received: by kepa.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA03030; Mon, 9 Jan 89 14:52:23 JST
Date: Mon, 9 Jan 89 14:52:23 JST
From: Masayuki Ida <ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@cc.aoyama.junet>
Message-Id: <8901090552.AA03030@kepa.cc.aoyama.junet>
To: cl-editorial@SAIL.STANFORD.EDU
Subject: Re: Issue: SUBSETTING-POSITION (Version 1)
Cc: ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET, masinter.pa@XEROX.COM


> Date: 3 Jan 89 12:29 PST
> From: masinter.pa@xerox.com
> Subject: Issue: SUBSETTING-POSITION (Version 1)
> In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 3 Jan 89 10:56
> 
> Frankly, we've not had much luck in "cleanup" in voting on "policy" in the
> abstract; rather, we've handled particular cases. The only fleshed-out
> proposal I've heard about for a subset of Common Lisp was from a Japanese
> working group, well over  a year ago, and I don't know how actively they're
> persuing it.
> 
Yes, it was two years ago that we were energetic to subset.
(I assume his comment refers our case.)

We are not active on subsetting CL, though we get several enquiries from
different organizations and countries every year
and CL/Core is not dead.
It seems to me that the current main subject of our group is
to introduce/share/contribute the developement activities around
this rich-function Lisp first.

Masayuki Ida

∂09-Jan-89  0938	CL-Editorial-mailer 	conformance & extensions issues   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  09:37:45 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 9 Jan 89 12:30:37 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 9 Jan 89 12:35:07 EST
Date: Mon, 9 Jan 89 12:35 EST
From: Barry Margolin <barmar@Think.COM>
Subject: conformance & extensions issues
To: cl-editorial@sail.stanford.edu
In-Reply-To: <890108-132607-3283@Xerox>
Message-Id: <19890109173528.6.BARMAR@OCCAM.THINK.COM>

    Date: 8 Jan 89 13:25 PST
    From: masinter.pa@xerox.com

    Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
    Problem:

    Is it OK to define Common Lisp functions with extra optional or  keyword
    parameters, with system dependent meanings?  

    Proposal: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS:NO-EXCEPT-AS-ALLOWED

    No, except as explicitly allowed in the standard. Functions that may be
    extended to take implementation-specific optional arguments are indicated
    by an &REST IGNORE in their argument list. Functions that may be extended
    to take additional keyword parameters are indicated by &ALLOW-OTHER-KEYS. 

    It isn't required that implementations signal errors at all safety/speed
    setting, but this is not legitimate/conformal behavior.

    Rationale:
    The goal is not to outlaw any current extensions currently offered by
    implementors, but to make the range of extensions to functions defined in
    the standard well documented in the standard.  

Currently this is only OPEN, which says that implementation-specific
keywords are likely to exist.  Do you expect to propose a list of other
functions for which extension may be permitted?

						   Implementations that want to
    extend functions that aren't explicitly allowed to be extended can instead
    shadow them.

Alternate proposal: NOT-IN-STANDARD-PACKAGE

Like NO-EXCEPT-AS-ALLOWED, except that an implementation may always
provide additional named arguments to a function if the names are not in
the LISP or KEYWORD packages (non-keyword named arguments were approved
sometime last year for CLOS use, weren't they?).

    Issue: EXTRA-SYNTAX
    Problem: is it OK to extend Common Lisp macros and special forms to take
    additional syntax not specified?

    Proposal:  EXTRA-SYNTAX:NO

    It isn't allowed.

    Issue: UNPSECIFIED-DATATYPES
    Problem: Is it OK to define the behavior of functions on datatypes not
    explicitly permitted in CLtL?  

    Proposal: UNPSECIFIED-DATATYPES:NO-EXCEPT-AS-EXPLICITLY-ALLOWED

    Example: It is currently not allowed for an implementation to define + as
    operating on vectors.
 
    Rationale: While the original intent of CL designers ws that
    implementations be permitted to do these things, they get in the way of
    portability when they're done, since it is nearly impossible to detect when
    a program has used one of these features. It is simple to define a new
    function 
    acme-common-lisp:+ which has the behavior of the "portable" + plus all the
    new whizzy features, too.

I'm not too happy with the general tone of the above proposals, as they
are extremely restrictive, and I think this is contrary to the original
style of CL.  Except for EXTRA-RETURN-VALUES and UNSOLICITED-MESSAGES,
the disallowed behavior cannot affect conforming CL programs, and
there's no way for a validation suite to check whether an implementation
includes the disallowed extensions (I'm not sure whether this latter
point is significant -- we may have already agreed that to disallow an
extension merely means that the extended behavior may not be documented
as a feature).

The suggestion that implementations can shadow standard functions to
provide these features has been made before, and I'll repeat my standard
objection.  The behavior of a standard function is also apparent when
calling a portable function that is defined to use that function.  A
good example is FORMAT: a portable subroutine library would be quite
likely to define functions that take FORMAT-style argument lists
(Pitman's portable condition system defines several).  If an
implementation extends FORMAT, these extensions should be reflected in
the behavior of these functions.  But if the extensions are hidden in
ACME:FORMAT and the library calls LISP:FORMAT, this won't happen, and
there's no way to make it happen without modifying the library's source.

    Issue: EXTRA-RETURN-VALUES
    Problem: Is it OK to return extra values from Common Lisp functions?

    Proposal: No, except where explicitly allowed. The reason is that
    additional arguments are visible to otherwise portable programs. "For
    instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
    will try to pass the wrong number of arguments to CONS if FLOOR returns an
    extra value."

This should probably be strengthened even more, to say that a function
must return EXACTLY the number of return values specified by the
standard.  Otherwise, an implementation might choose to return trailing
NIL values by not returning those values (since MULTIPLE-VALUE-BIND
would default those values to NIL).


                                                barmar

∂09-Jan-89  1058	RPG  
chapman%aitg.DEC@decwrl.dec.com/su
CLOS concept section  

Hm, I judged the outline by pulling out the sections and looking at them
in the order you suggested and it seemed ok to me, but if you think it's
no good, I'll look at the new version.

				-rpg-

∂09-Jan-89  1107	CL-Editorial-mailer 	Re: Issue:CONFORMANCE-POSITION    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  11:07:10 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 11:03:13 PST
Date: 9 Jan 89 10:49 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue:CONFORMANCE-POSITION
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 9 Jan 89 11:50
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu
Message-ID: <890109-110313-4288@Xerox>

The proposal name (CONFORMANCE-POSITION:PROGRAM) is probably inappropriate,
since this is really IMPLEMENTATION-AND-PROGRAM.

A conforming program is required to "run" in conforming implementations.
We've not really defined what that is -- what happens when you run out of
storage? -- but a portable program is required to have identical behavior
in all conformal implementations.   Its possible for a conformal program to
run in all conformal implementations, but to have allowable
implementation-dependent behavior. Insofar as we allow options in the
standard this will be true.

For example, a conformal implementation may support mixtures of Latin and
Greek characters. A conformal program may use mixtures of Latin and Greek
characters in symbol names. That program, however, may not be portable to
another implementation that does not support mixtures of Latin and Greek
characters.  

There are other examples of "optional" behavior for which I believe we will
want to declare that the use of them is conformal but not necessarily
"portable".



∂09-Jan-89  1242	CL-Editorial-mailer 	Re: Issue:CUT-OFF-DATES 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jan 89  12:42:38 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06783; 9 Jan 89 19:46 GMT
Date: Mon, 9 Jan 89 19:48:21 GMT
Message-Id: <11726.8901091948@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue:CUT-OFF-DATES
To: chapman <@decwrl.dec.com:chapman@aitg.dec>
In-Reply-To: chapman's message of 9 Jan 89 11:49
Cc: cl-editorial@sail.stanford.edu

I don't know what any of the items mean.

∂09-Jan-89  1524	CL-Editorial-mailer 	"Discussion" in issues  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jan 89  15:23:26 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa08166; 9 Jan 89 23:12 GMT
Date: Mon, 9 Jan 89 23:13:36 GMT
Message-Id: <12110.8901092313@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: "Discussion" in issues
To: chapman <@decwrl.dec.com:chapman@aitg.dec>, cl-editorial@sail.stanford.edu
In-Reply-To: chapman's message of 9 Jan 89 11:48

I don't much like the format of the "discussion" section and prefer
the way such things are put in cl-cleanup.  In cleanup issues,
comments are often attributed to the person who made them, and there's
no attempt to seal off all lines of disagreement.  The various
comments are then placed on an equal footing, and the issue writer
appears to be neutral.  Here the comments are always answered, as if
there were nothing more to be said, and as if the responses were
always correct and complete answers to the comments.  That might be
fine if they were correct and complete answers, but they aren't,
and I'm not sure it's possible that they can be.

For example:

> Discussion:
>  
> Comments:
> "The most commonly proposed solution to this kind of problem is to
> require the implementation to have a way to disable its extensions, so
> that a programmer can be told when he is using a feature that might
> affect his program's portability.  Whether this should be the default
> mode is up for debate; I think most other standards that do this don't
> require it to be the default."
> 
> Response:
> Requiring an implementation to be able to disable extensions seems like
> a more costly alternative than requiring an implementation to document
> its extensions as extensions if it is to be conforming, since presumably
> an implementation will document user-visible extension anyway.

At this point, I feel almost compelled to say:  So?  Perhaps it's
worth paying that cost (just because it costs more doesn't mean it's
not better).  And what about this "presumably"?  What if the
implementation doesn't?

The response brings up the relative costs but doesn't really show
why the cost should decide the issue.  All it really does is bring
up some things to consider.  But placed after the comment in this
way it encourages us to think the comment has been answered and
its psoposed solution shown to be inferior.

I would also like alternative resolutions of an issue to be presented
as alternatives (so long as there is support for more than one) rather
than as a single issue where all but one possibility has been
dismissed by the "responses".

∂13-Jan-89  1903	CL-Editorial-mailer 	Code as Spec: {Issue: THE-AMBIGUITY (Version 2)} 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Jan 89  19:03:43 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03136g; Fri, 13 Jan 89 18:59:30 PST
Received: by bhopal id AA08485g; Fri, 13 Jan 89 19:01:46 PST
Date: Fri, 13 Jan 89 19:01:46 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901140301.AA08485@bhopal>
To: cl-cleanup@sail.stanford.edu, cl-editorial@sail.stanford.edu
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 11 Jan 89 23:14 PST <890111-231458-11647@Xerox>
Subject: Code as Spec: {Issue: THE-AMBIGUITY (Version 2)}

re: Proposal (THE-AMBIGUITY:FOR-DECLARATION):
      Clarify that the type specifier in
	    (THE type exp)
      may be any valid type specifier.  In the case that exp returns one
      value and type is not a VALUES type specifier, (THE type exp) is
      equivalent to
	    (LET ((g exp))
	      (DECLARE (TYPE type g))
	      g)
      where "g" is a gensym.

I'm not very happy with this style of specification: instead of
spelling out what "for declaration" means, a piece of code is
offered which is allegedly "equivalent".  But "equivalent" under
what terms?  Does this mean that for those types for which <type>
has specialized storage (and for which the compiler takes advantage
of declarations to use that specialization) then 

        (THE type exp)

imples that "exp" must also be in specialized storeage?

I remember a similar misleading definition -- the one that was worked
out "on the fly" at the Boston meeting for:
    (COERCE '(LAMBDA (...) ...) 'FUNCTION)
It said that such a form should be like:
    (EVAL '(FUNCTION (LAMBDA (...) ...)))
[or, words like that].  Presumably this was a cheap way of trying to say
"closure in the null lexical environment".  I objected to this as being a
circular definition, since both forms will be implemented by some
non-portable code in each implementation, and it is precisely the
behaviour of that non-portable action that need specification.  Anyway,
I mention this now because some vendors have, upon ocasion, delivered a
subseted Common Lisp without an interpreter in it; the above-mentioned
style of definition would imply that COERCE should not work in such a
subset.  But in fact, COERCE can quite easily work; it is APPLY that
probably cannot work.

Code as illustrative example, of course, is fine.  And while the
colloquialisms of code segments can be a shorthand for fuller
definitions, we need to be awfully careful that we don't use it in
situations where the reader will really understand it only if he 
already knows what it is trying to say.


-- JonL --

∂23-Jan-89  0106	CL-Editorial-mailer 	Requests from the Japanese   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 23 Jan 89  01:06:02 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA02393; Mon, 23 Jan 89 01:04:36 PST
Message-Id: <8901230904.AA02393@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 23 Jan 89 04:02
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub,
        ucsb.edu%aitg.DEC@decwrl.dec.com
Subject: Requests from the Japanese

Following is one of the memos that prompted my question about
shortening the standard (re: editorial lunch meeting).
kc


From:	DECWRL::"ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET" "Masayuki Ida  11-Jan-89 1149 O" 11-JAN-1989 00:29:32.98
To:	aitg::chapman, ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET
CC:	
Subj:	ANSI draft

Dear Kathy,
 
Yesterday we had a meeting of Jeida Common Lisp committee.
At the table,we discussed how to contribute/share the ANSI efforts,
especially on draft.
Persons from several companies are eager to discuss about the contents.
I know it is the USA domestic matters and not international matter,
and I have no will to interfare you activity but
want to assist your effort.
please give me your comments on the following;
1) Several members want to have an Electronic version of ANSI draft.
I think it is on the machine named 'hudson.dec.com', and
publicly FTPable.
Is it ok to ask Kawai san of DEC-J to FTP them to japan and
distribute it to the limitted number of persons ?
 
2) I want to know the importance of the examples section for each tool.
As far as I know, examples are *not* included in the JIS standard
for existing languages.
And we get the reaction that 'Common Lisp manual is too big'.
If we can remove examples or move them to a different part,
we can reduce the total size of the volume. Say, the size will be half.
Other voices say 'if examples are in the standard, any implementation
must do the same thing and must return the same value with
the same textual representation appeared in the standard document.'
I think specifying the examples do the validation role in many extents
and I will welcome.
But, too large volume of the document
does not always be welcomed by people.
Is it impossible to split the whole contents into two ?
The standard itself and the rationale as ADA.
It will reduce the physical size of the standard, and 
people can know what is the basic thing, and what is the interpretation for 
them.
 
Masayuki Ida
 
PS: I can not attend the Hawaii meeting due to the University
schedule which I should be responsible.
 
 
========================================================================
Received: from RELAY.CS.NET by decwrl.dec.com (5.54.5/4.7.34)
	for aitg::chapman; id AA11081; Tue, 10 Jan 89 21:24:35 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa23034; 11 Jan 89 0:09 EST
Received: from utokyo-relay by RELAY.CS.NET id al08271; 10 Jan 89 23:42 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
	id AA14976; Wed, 11 Jan 89 13:08:19 JST
Received: from kepa.cc.aoyama.junet by aoyama.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA17592; Wed, 11 Jan 89 11:49:36 JST
Received: by kepa.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA03703; Wed, 11 Jan 89 11:49:39 JST
Return-Path: <ida@cc.aoyama.junet>
Message-Id: <8901110249.AA03703@kepa.cc.aoyama.junet>

∂23-Jan-89  1640	CL-Editorial-mailer 	Re: Requests from the Japanese    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Jan 89  16:40:46 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 JAN 89 15:48:07 PST
Date: 23 Jan 89 15:43 PST
From: masinter.pa@Xerox.COM
Subject: Re: Requests from the Japanese
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 23 Jan 89 04:02
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ARPA,
 ucsb.edu%aitg.DEC@decwrl.dec.com
Message-ID: <890123-154807-2134@Xerox>

I think we should take seriously their concerns as to the apparent size of
the standard.

Is there some way of hacking the TeX macros so that it can be compiled
without the examples, or with the examples at the end? This would require
being careful to make sure that the text actually read well with the
examples omitted, but it might be possible to leave the examples in the
source TeX, but have a way of producing a document that has only the text
that is actually "the official standard".

Clearly "if examples are in the standard, any implementation
must do the same thing and must return the same value with
the same textual representation appeared in the standard document" is
wrong. That has to be made very clear, if it isn't already.



∂23-Jan-89  1640	CL-Cleanup-mailer 	[Robert S. Boyer <boyer@CLI.COM>: Backquote Documentation    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Jan 89  16:40:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 JAN 89 15:37:56 PST
Date: 23 Jan 89 15:36 PST
From: masinter.pa@Xerox.COM
Subject: [Robert S. Boyer <boyer@CLI.COM>: Backquote Documentation
 Elaboration]
To: cl-editorial@sail.stanford.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890123-153756-2114@Xerox>

I think this falls into the "editorial" category. 

     ----- Begin Forwarded Messages -----

Return-Path: <boyer@CLI.COM>
Received: from CLI.COM ([10.8.0.62]) by Xerox.COM ; 21 JAN 89 09:17:00 PST
Received: by CLI.COM (4.0/1); Sat, 21 Jan 89 11:12:14 CST
Date: Sat, 21 Jan 89 11:12:14 CST
From: Robert S. Boyer <boyer@CLI.COM>
Message-Id: <8901211712.AA17553@CLI.COM>
To: masinter.pa
Subject: Backquote Documentation Elaboration
Reply-To: boyer@cli.com

On p. 349 of CLTL it states "An implementation is quite free to
interpret backquote in any way such that a backquoted form, when
evaluated, will produce a result equal to that produced by the
interpretation shown here."  It should perhaps be emphasized that the
phrase ``when evaluated'' means ``when evaluated in the implementation
of Common Lisp that is currently running'' rather than ``when
evaluated in any correct implementation of Common Lisp''.  The
following examples on p. 350 and 351 illustrate alternative results of
backquote reading that use standard Common Lisp functions such as
APPEND, LIST*, etc., but none that use things from, say, package
LUCID-RUNTIME-SUPPORT.

Here is a function that illustrates READ treating backquote
differently in the three Common Lisps I have at hand, using in two
cases functions not defined in CLTL.

(in-package "USER")

(defun which-lisp ()
  (let* ((sym (car (read-from-string "`(foo ,y)")))
	 (package-name (package-name (symbol-package sym))))
    (cond ((eq sym 'list) 'kcl)
	  ((equal package-name "SYSTEM-INTERNALS")
	   'symbolics)
	  ((equal package-name "LUCID-RUNTIME-SUPPORT")
	   ;  works in Sun/Lucid 3.0, but not in 2.1
	   'lucid)
	  (t 'unknown))))




     ----- End Forwarded Messages -----

∂27-Jan-89  0130	CL-Editorial-mailer 	The volume of ANSI draft
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 27 Jan 89  01:30:41 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa14534; 27 Jan 89 4:15 EST
Received: from utokyo-relay by RELAY.CS.NET id aa02446; 27 Jan 89 4:08 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
	id AA26729; Fri, 27 Jan 89 17:06:05 JST
Received: from kepa.cc.aoyama.junet by aoyama.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA03045; Fri, 27 Jan 89 14:20:15 JST
Received: by kepa.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA11212; Fri, 27 Jan 89 14:20:23 JST
Date: Fri, 27 Jan 89 14:20:23 JST
From: Masayuki Ida <ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@cc.aoyama.junet>
Message-Id: <8901270520.AA11212@kepa.cc.aoyama.junet>
To: cl-editorial@SAIL.STANFORD.EDU
Cc: ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET
Subject: The volume of ANSI draft

Here is my recent Electronic conversation with chapman@aitg.
----------------------------------------
Date: Wed, 25 Jan 89 17:53:50 JST
From: Masayuki Ida <ida>
To: chapman%aitg.dec@decwrl.dec.com, ida
Subject: Re: ANSI draft
> 
> >How do you think about the minimize the page size of
> >Common Lisp Specification ?
> >I still think the splitting the definition and rationale thing
> >will give avarage users friendly feeling more.
> I forwarded your mail message to the editorial committee (composed of
> Gabriel, Steele, Mathis, and others), and asked them personally at
> our subcommittee meeting in Hawaii. I have heard similar comments from
> others. The edit committee feels that the contents of the document
> should remain in tact at this time. Of course they may change their
> minds as more of them have to review the whole thing, but now they
> think that everything there now is necessary. I'll keep you posted.
> 

Thank you for forwarding my mail to editorial committee members.
(Yes, I also received editorial mail).
Please let the members know that my point is not on the specific section
like 'examples' but on 'we should seriously consider how to make
the document slim without dropping information'.
(I know we cannot save 50% size with the removal of examples section only.)
Did you estimate the total page numbers if
each page of chapter6 is serially concatenated ?
(In the current style, each tool is placed on separate page.
So, there are lots of white part in each page.)

> Thanks for all your help.

You're welcome. Its my pleasure!

> kc
>
Masayuki Ida


--------------------------------------------
Date: Thu, 26 Jan 89 04:44:56 PST
From: chapman%aitg.DEC@decwrl.dec.com
To: ida%cc.aoyama.junet%UTOKYO-RELAY.CSNET@RELAY.CS.NET
Subject: Re: ANSI draft

>Did you estimate the total page numbers if
>each page of chapter6 is serially concatenated ?
>(In the current style, each tool is placed on separate page.
>So, there are lots of white part in each page.)
We talked about that also. LThe editorial committee didn't to
want to do that either. I'm hoping that new publishing techniques
and thin paper will make the document physically smaller than it
is now, without changing the format. If you want to let the editorial
committee know how strongly you feel about this, please do!
Just send mail to cl-editorial.
kc

-----------------My comment on the above mail -------------
Why the editorial committee didn't want to do that either ?
With thin paper, we can reduce only 70 or 80% of its physical volume.
Then the draft book can be 2 inch thick but not enough.

Masayuki Ida

∂27-Jan-89  0941	CL-Editorial-mailer 	The volume of ANSI draft
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 89  09:41:22 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 528232; Fri 27-Jan-89 12:39:25 EST
Date: Fri, 27 Jan 89 12:39 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: The volume of ANSI draft
To: CL-Editorial@SAIL.Stanford.EDU
cc: ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET
In-Reply-To: <8901270520.AA11212@kepa.cc.aoyama.junet>
Message-ID: <890127123922.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

I share the concerns that have been expressed by numerous people that
Common Lisp has become very large. However, for me that concern is
not related to the number of pages it takes to express it. I don't
think that without a radical change to the number of functions and
features of the language, we can make a dent in that. Further, I
consider that any radical change which would make the language 
measurably smaller in that regard would be de-stabilizing to the
community using the language and would therefore not appropriate for
us to attempt.

With regard to the issue of the number of pages in the presentation, I
am not sure how to reconcile the recent comments from Japan with the
fact that in meetings we have been told over and over again that making
this document "user friendly", "non-redundant", etc.  are not to be
goals of this committee.

Asking for any form of reformatting will require work from our editor
which she does not have time to offer. She is working on a limited time
schedule and has much too much to do already just to make sure things
get documented consistently in any form.

It seems to me that reducing the presented size of the standard is
something which could and should be taken up as a post-standardization
activity, and that our extremely limited resources should remain
focussed on issues of substance rather than issues of presentation.

If the resource situation and/or the power of the communication media
we use were different, I would certainly be the first to suggest that
we pursue this issue of reformatting. I'm sure Kathy doesn't like 
waiting for the printer to print all those pages, and I know I don't
like to have to carry them around once they are printed. So I don't
mean to dismiss the formatting issue as an unreasonable concern;
however, I do mean to suggest dismissing it as a goal which is not
feasible given our dwindling resources.

These are my personal views and not those of Symbolics or X3J13.

∂29-Jan-89  2050	CL-Editorial-mailer 	The volume of ANSI draft
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 29 Jan 89  20:50:24 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa01727; 29 Jan 89 23:41 EST
Received: from utokyo-relay by RELAY.CS.NET id ao23302; 29 Jan 89 23:36 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
	id AA22555; Mon, 30 Jan 89 13:11:48 JST
Received: from kepa.cc.aoyama.junet by aoyama.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA11649; Mon, 30 Jan 89 12:46:09 JST
Received: by kepa.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA12110; Mon, 30 Jan 89 12:46:18 JST
Date: Mon, 30 Jan 89 12:46:18 JST
From: Masayuki Ida <ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@cc.aoyama.junet>
Message-Id: <8901300346.AA12110@kepa.cc.aoyama.junet>
To: KMP@SCRC-STONY-BROOK.ARPA
Cc: CL-Editorial@SAIL.STANFORD.EDU, ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET
In-Reply-To: Kent M Pitman's message of Fri, 27 Jan 89 12:39 EST <890127123922.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: The volume of ANSI draft

   >>Date: Fri, 27 Jan 89 12:39 EST
   >>From: Kent M Pitman <KMP@scrc-stony-brook.arpa>
   >>
   >>I share the concerns that have been expressed by numerous people that
   >>Common Lisp has become very large. However, for me that concern is
   >>not related to the number of pages it takes to express it. I don't
   >>think that without a radical change to the number of functions and
   >>features of the language, we can make a dent in that. Further, I
   >>consider that any radical change which would make the language 
   >>measurably smaller in that regard would be de-stabilizing to the
   >>community using the language and would therefore not appropriate for
   >>us to attempt.
My concern is related to the way we send Common Lisp to end-users
without their embarrassment. I don't want any de-stabilization.
I know the schedule is tight and fixed and its great job of her.
I hope the things go well as promised.
So, I wonder I should not have sent any comments on the possible
reaction of possible users (I feel we should spread Common Lisp
to more people).
I myself is swinging among three ideas,
  one idea that means radical reduction,
  another idea that means  splitting the total volume into 
two parts preserving all the contents,
 and the other idea that means some magic about the physical
appearance of the manual.
(I have much concern about the second choice as of now)
Of cause I know ANSI thing is not an international but US domestic,
though I am still a princpal member of X3J13.
I am not representing my country, japan. I think I am joining 
this activity as one of the Common Lispers.
   >>
   >>With regard to the issue of the number of pages in the presentation, I
   >>am not sure how to reconcile the recent comments from Japan with the
   >>fact that in meetings we have been told over and over again that making
   >>this document "user friendly", "non-redundant", etc.  are not to be
   >>goals of this committee.
As you say, it may not be goals of this committee. But any standard
is for the people and of the people. If user will hesitate to read
and use a standard, the language described in such a standard will
encounter hard time, I am afraid.
I believe Lisp is one of the best languages to use and
I pray Common Lisp will have more population.
   >>
   >>It seems to me that reducing the presented size of the standard is
   >>something which could and should be taken up as a post-standardization
   >>activity, and that our extremely limited resources should remain
   >>focussed on issues of substance rather than issues of presentation.
I have no data to analyze. So, you may be right.
   >>
   >>If the resource situation and/or the power of the communication media
   >>we use were different, I would certainly be the first to suggest that
   >>we pursue this issue of reformatting. I'm sure Kathy doesn't like 
   >>waiting for the printer to print all those pages, ...
   >>
OK, I understand.
I can spare my time to assist draft making process.
I have been reveiwing the whole contents of the draft as a member.
And I will continue to review the on-going draft.
Please suggest me any onther type of contribution I can if there is.

(My machine is directly connected to ccut which is the junet gateway,
and ccut is scheduled to have a direct connection via a leased line
to NSF and I may telnet/ftp to internet after the networkers great 
achievement in this year. It's experimental and it may be the entrance to
the new age of pacific communication among research organizations
of this pretty planet)

Masayuki Ida

∂30-Jan-89  0804	CL-Editorial-mailer 	The volume of ANSI draft
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 30 Jan 89  08:03:49 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 30 Jan 89 10:28:16 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 30 Jan 89 11:00:10 EST
Date: Mon, 30 Jan 89 11:00 EST
From: Barry Margolin <barmar@Think.COM>
Subject: The volume of ANSI draft
To: Masayuki Ida <ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Editorial@sail.stanford.edu
In-Reply-To: <8901300346.AA12110@kepa.cc.aoyama.junet>
Message-Id: <19890130160055.4.BARMAR@OCCAM.THINK.COM>

    Date: Mon, 30 Jan 89 12:46:18 JST
    From: Masayuki Ida <ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET>

    My concern is related to the way we send Common Lisp to end-users
    without their embarrassment. 

While I believe we appreciate this concern, I think it is misplaced.  I
don't know of any ANSI standard document that is actively used by end
users.  For example, I'm sure the ANSI C standard will be very large,
too, but end users will learn C from Kernighan&Ritchie, Harbison&Steele,
etc.

Standards documents must of necessity be extremely detailed, more than
is necessary for the average user.  Expecting end users to make use of
the standard itself is like expecting citizens to own a copy of all the
law books, or expecting airline pilots to have a copy of the regulations
regarding aircraft manufacture.

    As you say, it may not be goals of this committee. But any standard
    is for the people and of the people. If user will hesitate to read
    and use a standard, the language described in such a standard will
    encounter hard time, I am afraid.

On what do you base this conclusion?  I've used a number of languages in
my career, and I've never felt the need to read an ANSI document in
order to use one of these languages.  I used PL/I for several years, and
it is supposed to have one of the largest standards around (for a
programming language), but I've never seen it.  The audience of
standards documents is primarily implementors; they may also be used to
resolve disputes between vendors and customers over whether the
implementation actually conforms to the standard.  But for average
users' reference needs, there are much better vehicles.

                                                barmar

∂30-Jan-89  1918	CL-Editorial-mailer 	The volume of ANSI draft
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 30 Jan 89  19:18:23 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac21052; 30 Jan 89 21:56 EST
Received: from utokyo-relay by RELAY.CS.NET id af06375; 30 Jan 89 21:34 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
	id AA16221; Tue, 31 Jan 89 11:13:05 JST
Received: from kepa.cc.aoyama.junet by aoyama.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA16090; Tue, 31 Jan 89 11:06:32 JST
Received: by kepa.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA12411; Tue, 31 Jan 89 11:06:42 JST
Date: Tue, 31 Jan 89 11:06:42 JST
From: Masayuki Ida <ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@cc.aoyama.junet>
Message-Id: <8901310206.AA12411@kepa.cc.aoyama.junet>
To: barmar@THINK.COM
Cc: ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET, CL-Editorial@SAIL.STANFORD.EDU
In-Reply-To: Barry Margolin's message of Mon, 30 Jan 89 11:00 EST <19890130160055.4.BARMAR@OCCAM.THINK.COM>
Subject: The volume of ANSI draft

   >>Date: Mon, 30 Jan 89 11:00 EST
   >>From: Barry Margolin <barmar@think.com>
   >>
   >>...  I
   >>don't know of any ANSI standard document that is actively used by end
   >>users.  For example, I'm sure the ANSI C standard will be very large,
   >>too, but end users will learn C from Kernighan&Ritchie, Harbison&Steele,
   >>etc.
   >>
   >>Standards documents must of necessity be extremely detailed, more than
   >>is necessary for the average user.  Expecting end users to make use of
   >>the standard itself is like expecting citizens to own a copy of all the
   >>law books, or expecting airline pilots to have a copy of the regulations
   >>regarding aircraft manufacture.
   >>
   >>  ...                            I've used a number of languages in
   >>my career, and I've never felt the need to read an ANSI document in
   >>order to use one of these languages.  I used PL/I for several years, and
   >>it is supposed to have one of the largest standards around (for a
   >>programming language), but I've never seen it.  The audience of
   >>standards documents is primarily implementors; ...
I understand. It may be a kind of culture difference. 
The audience of standards documents is primarily implementors in japan
too. But, JIS standard document is openly sold from Kikakukyoukai
(Japanese Standards Association) at bookstore.
(every year, more than thousands copies of handbooks which contain 
standards for each industry categories are published and sold. )

Guidline, which is a pre-standard or a defacto standard, is usually
available from its originator in book style or in journal article style.
The number of copies of CLtL in japanese is more than 10,000.

I also believe that all the persons who buy these documents
do not read and understand the whole contents. But they play a role
in many extents.
At least, lots of pure end-user and software developer buy standard
documents.
This morning I asked the data management division of our university
to borrow JIS Jouhoushori handbook. They have. Its 5,000 yen and
about 1700 pages containing every JIS from data codes, languages,
devices, communications, etc.
   >>                                               ...  But for average
   >>users' reference needs, there are much better vehicles.
I agree with you.
   >>
   >>						     barmar
   >>
   >>
Masayuki Ida

PS: I think further discussion about this issue should go to
a different mailing list, like how-we-are-different-and-
how-we-cannot-share/join mailing-list :-)

∂31-Jan-89  1106	CL-Editorial-mailer 	Re: Issue: EXTRA-SYNTAX (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Jan 89  11:06:26 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 31 JAN 89 10:55:10 PST
Date: 31 Jan 89 10:53 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXTRA-SYNTAX (Version 1)
In-reply-to: your message of 10 Jan 89 14:03
To: cl-editorial@sail.stanford.edu
line-fold: NO
Message-ID: <890131-105510-7987@Xerox>

Re:

"The suggestion that implementations can shadow standard functions to
provide these features has been made before, and I'll repeat my standard
objection.  The behavior of a standard function is also apparent when
calling a portable function that is defined to use that function.  A
good example is FORMAT: a portable subroutine library would be quite
likely to define functions that take FORMAT-style argument lists
(Pitman's portable condition system defines several).  If an
implementation extends FORMAT, these extensions should be reflected in
the behavior of these functions.  But if the extensions are hidden in
ACME:FORMAT and the library calls LISP:FORMAT, this won't happen, and
there's no way to make it happen without modifying the library's source. "

This rebuttal does not apply to the subject of the proposal, which deals
with extra syntax of macros & special forms, e.g., IF.  I thought we might
want to deal with "extensions" in classes, which is why I gave separate
proposals; there are several kinds of extensions for which we might define
conformance differently. Certainly the proposal
is extremely restrictive. This was discussed at length under the cleanup
issue IF-BODY.  There seems to be no good reason why ACME:IF couldn't
be different than CL:IF.


∂31-Jan-89  1226	CL-Editorial-mailer 	Re: Issue: EXTENSIONS-POSITION (version 1)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 31 Jan 89  12:26:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 31 JAN 89 11:20:40 PST
Date: 31 Jan 89 11:18 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXTENSIONS-POSITION (version 1)
In-reply-to: your message of 10 Jan 89 14:30
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu, cl-compiler@sail.stanford.edu
Message-ID: <890131-112040-8084@Xerox>

The compiler issue SHARP-COMMA-CONFUSION seems to imply that
implementations "could continue to provide #, as an extension". However, is
such an extension legal? Can't legal common lisp programs redefine #, if #,
isn't in the language? If they can, wouldn't it disallow having #, be an
extension?

I'm discussing this under EXTENSIONS-POSITION since the proposal itself for
#, didn't propose making it explicit in the standard that #, "was allowed
as an extension".

∂31-Jan-89  1237	CL-Editorial-mailer 	Re: Issue: EXTENSIONS-POSITION (version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 Jan 89  12:37:20 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 530994; Tue 31-Jan-89 15:34:56 EST
Date: Tue, 31 Jan 89 15:34 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EXTENSIONS-POSITION (version 1)
To: masinter.pa@Xerox.COM
cc: chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu,
    cl-compiler@sail.stanford.edu
In-Reply-To: <890131-112040-8084@Xerox>
Message-ID: <890131153443.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 31 Jan 89 11:18 PST
    From: masinter.pa@Xerox.COM

    The compiler issue SHARP-COMMA-CONFUSION seems to imply that
    implementations "could continue to provide #, as an extension". However, is
    such an extension legal? Can't legal common lisp programs redefine #, if #,
    isn't in the language? If they can, wouldn't it disallow having #, be an
    extension?

Presumably the only thing that defining it as an extension can mean from
CL's point of view is `initially definining' it as an extension. Whether
an implementation permits you to redefine its extensions is between that
implementation and its users and beyond the scope of Common Lisp. For
example, it is common practice to redefine some kinds of system functions
in Genera -- to extend the system in interesting ways, to fix bugs, etc.
Given this, I don't see that there is necessarily a conflict.

    I'm discussing this under EXTENSIONS-POSITION since the proposal itself for
    #, didn't propose making it explicit in the standard that #, "was allowed
    as an extension".

∂31-Jan-89  1248	CL-Compiler-mailer 	Re: Issue: EXTENSIONS-POSITION (version 1)   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 31 Jan 89  12:48:45 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA29248; Tue, 31 Jan 89 13:45:45 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA26447; Tue, 31 Jan 89 13:45:42 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901312045.AA26447@defun.utah.edu>
Date: Tue, 31 Jan 89 13:45:40 MST
Subject: Re: Issue: EXTENSIONS-POSITION (version 1)
To: masinter.pa@Xerox.COM
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu,
        cl-compiler@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 31 Jan 89 11:18 PST

CLtL p. 351 indicates that more # read macros could be added to the
standard language, but doesn't really address the issue of whether
implementations can provide their own # read macros.  It does list a
set that are explicitly reserved for users, though.

I know of at least one implementation (Lucid) that has added a #P
syntax for pathnames -- see the requirement on p. 370 that pathnames
PRINT in such a way that they can be READ in again.  

-Sandra
-------

∂31-Jan-89  1300	CL-Editorial-mailer 	Re: Issue: EXTENSIONS-POSITION (version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 Jan 89  13:00:27 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 531021; Tue 31-Jan-89 15:57:23 EST
Date: Tue, 31 Jan 89 15:57 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EXTENSIONS-POSITION (version 1)
To: sandra%defun@cs.utah.edu
cc: masinter.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com,
    cl-editorial@sail.stanford.edu, cl-compiler@sail.stanford.edu
In-Reply-To: <8901312045.AA26447@defun.utah.edu>
Message-ID: <890131155704.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Tue, 31 Jan 89 13:45:40 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    ... It does list a set that are explicitly reserved for users, though. ...

In the world of third- (or Nth-) party products, I have to say that I
find this concept pretty bizarre. If I market two Common Lisps, one
layered atop the other, or if I market a Lisp and a Lisp+Tools (eg,
embedded expert system) environment, is the layered product a "user"? If
I think I'm a user for months until I realize I've got something
valuable and then decide to sell it, must I go through and eliminate my
use of readmacros because suddenly I'm not the end user?

I think we should eliminate the seemingly arbitrary distinction between
Nth level and N-1th level users. CL either defines something or it does
not. What happens after that is out of its jurisdiction. We don't define
the myriad of other things that might be added later; of what possible
value is it for us to reserve a few obscure characters in an obscure
namespace?

As an aside, if we did readtables right (allowed local binding of them)
we could forbid extension and say that extensions should be provided in
another readtable.

∂31-Jan-89  1613	CL-Editorial-mailer 
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

Size of the Draft

I agree with Professor Ida. Not only Japanese computer scientists but
Europeans are distressed by the size of the draft. When the ISO
delegations judge the draft, it will be the size that is criticized and
not the clarity or precision (I believe). It is difficult at this stage to
find people who can spend the time to distill the document, but we should
try to figure out something to do. One alternative is to separate the core
language from the library functions. The core language would be those
things that would be described by a formal semantics. Examples and rationale
could be put in a separate volume. Thus, one could imagine a core language
specification in one volume, CLOS in another, library in a third, and
examples/rationale in a fourth.

Another alternative is simple distillation. We could even try a formal
semantics only for the core language with English description for derived
libraries.

It is possibly the realization that resources cannot be found to do what
Professor Ida suggests and not a strong belief that he is wrong to desire a
smaller (looking) standard.

I have tried elsewhere to make the following argument work:

People claim Common Lisp is large and C is small. They point to Kernighan
& Ritchie versus Steele. But this is comparing two things in parallel:
the languages and the authors. Steele has also written a description of C
ala CLtL. CLtL is 465 pages; Harbison and Steele is 404 pages; K&R is 272
pages.

Therefore, I believe we can get a smaller document with some effort. Is there
a way to find that effort?

			-rpg-

∂31-Jan-89  1739	CL-Editorial-mailer 	Re: Issue: EXTRA-SYNTAX (Version 1)    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 31 Jan 89  17:39:12 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 31 Jan 89 20:31:31 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 31 Jan 89 20:35:04 EST
Date: Tue, 31 Jan 89 20:36 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: Issue: EXTRA-SYNTAX (Version 1)
To: masinter.pa@xerox.com
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <890131-105510-7987@Xerox>
Message-Id: <19890201013637.9.BARMAR@OCCAM.THINK.COM>

    Date: 31 Jan 89 10:53 PST
    From: masinter.pa@xerox.com

    Re:

    "The suggestion that implementations can shadow standard functions to
    provide these features has been made before, and I'll repeat my standard
    objection. ... "

    This rebuttal does not apply to the subject of the proposal, which deals
    with extra syntax of macros & special forms, e.g., IF.

The rebuttal you included was written as a response to the collection of
extension-related issues, which were originally mailed as a single
message; someone else (you, I thought) later copied it into the
Discussion section of each proposal that was split out from that
message.  It's not my fault that it doesn't apply to all of them
equally well.

    There seems to be no good reason why ACME:IF couldn't
    be different than CL:IF.

Here's a way in which my argument applies to macros and special forms,
although I admit it isn't as convincing as the argument for functions:
Suppose I distribute a macro, and specify that the <body> in an
invocation of this macro is used as the <body> of a COND.  Also suppose
that an implementation wishes to extend the syntax of COND (e.g. they
define a meaning for an atomic clause).  My belief is that the user of
the macro could reasonably expect the implementation's extension to
propogate to the macro.  If the extension were only available when
ACME:COND is used, and not when CL:COND is used, this would not happen,
since the portable macro would not know about ACME:COND.

I can live with this restriction on macros and special forms, though,
because the above argument runs into trouble when you try to extend it
to forms with more complex syntax.  If a macro were defined to take
arguments like DEFUN, I would expect the macro to do some parsing of its
own, and it could fail to parse uses of extended syntax.  For instance,
Symbolics DEFUN allows (with a warning) Maclisp-style lexpr syntax
(using a symbol in place of the lambda list, and binding it to the
number of arguments), but I think any macro that expected to be used
like DEFUN would be justified if it complained that its second sub-form
wasn't a list.  And a macro that expected IF-like arguments would be
justified in being defined with
	(DEFMACRO FOO (PREDICATE THEN-FORM &optional ELSE-FORM) ...)

So, I guess I agree with you about extending special operator syntax.

                                                barmar

∂01-Feb-89  0702	CL-Editorial-mailer 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Feb 89  07:02:37 PST
Received: from fafnir.think.com by Think.COM; Wed, 1 Feb 89 09:53:44 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 1 Feb 89 09:58:39 EST
Received: by verdi.think.com; Wed, 1 Feb 89 09:58:13 EST
Date: Wed, 1 Feb 89 09:58:13 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902011458.AA14467@verdi.think.com>
To: RPG@sail.stanford.edu
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: Dick Gabriel's message of 31 Jan 89  1613 PST <ritvK@SAIL.Stanford.EDU>

   Date: 31 Jan 89  1613 PST
   From: Dick Gabriel <RPG@sail.stanford.edu>
   ...
   I have tried elsewhere to make the following argument work:

   People claim Common Lisp is large and C is small. They point to Kernighan
   & Ritchie versus Steele. But this is comparing two things in parallel:
   the languages and the authors. Steele has also written a description of C
   ala CLtL. CLtL is 465 pages; Harbison and Steele is 404 pages; K&R is 272
   pages.

   Therefore, I believe we can get a smaller document with some effort. Is there
   a way to find that effort?

Ahem!

I am also all in favor of a concise draft.  But regarding this argument,
please bear in mind that the primary motivation that drove Harbison and
me to do our C book was that K&R was distressingly vague and imprecise
in many places.

A better argument is that the ANSI C standard is smaller than the H&S book.
I believe this is primarily thanks to the omission of examples.

--Guy

∂01-Feb-89  1419	CL-Editorial-mailer 	Importance of non-US opinion 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Feb 89  14:19:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 FEB 89 13:54:06 PST
Date: Wed, 1 Feb 89 13:53 PST
From: Gregor.pa@Xerox.COM
Subject: Importance of non-US opinion
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: cl-editorial@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <ritvK@SAIL.Stanford.EDU>
Message-ID: <19890201215331.2.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

    Date: 31 Jan 89 16:13 PST
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    Therefore, I believe we can get a smaller document with some effort.
    Is there a way to find that effort?

Yes, there is no doubt we could get a smaller document with some effort.
There are a number of ways to do this.  One simple way which has been
suggested by Professor IDA is to alter the formatting of Chapter 6.
Other simple ways to do it are to remove examples or reformat other
sections.

Dick has suggested other ways to reduce the size of the specification
including separating "core language" and "library", producing a formal
semantics etc.  These kinds of proposals are more elegant, but would
certainly require more work.

It seems clear that most US representatives to X3J13 are not troubled by
the projected size of the document.  These people believe that altering
the size of the document doesn't affect the actual standard.  These
people expect that only a very small number of U.S. users will reference
the actual standard document.

But, a growing number of people outside the United States, are very
troubled by the size of the document.  Apparently there are cultural
difference which cause the size of the document to be more important to
these people than it is to those of us in the US.  Some people are
troubled enough that they are willing to volunteer their efforts to help
solve this problem.

We have already decided that we want this standard to be suitable for
international use, in fact we want to see it adopted by ISO.  To achieve
this we need to be sure not to let language or cultural barriers prevent
us from hearing serious objections from non-US members of X3J13 or ISO.
We cannot afford to produce a specification which is technically
pleasing, but which is nonetheless unacceptable to a large portion of
its prospective users.

We cannot try to "explain" to these people why the size of the document
doesn't matter, instead we must listen to them tell us why it does
matter.  We must try to understand in more detail the concerns Professor
IDA and others are voicing.  We need to understand how they see the
expanded-work-effort vs. specification-page-count tradeoff.  It is true
that we have made most of our technical decisions, but now we need to
try and be flexible about the form of the actual document we produce.
-------

∂02-Feb-89  0727	CL-Editorial-mailer 	Issue: FONTS  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Feb 89  07:27:17 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA12549; Thu, 2 Feb 89 07:25:33 PST
Message-Id: <8902021525.AA12549@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Feb 89 10:24
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: FONTS

Issue:        FONTS
References:   Working draft of the standard
Category:     Clarifiaction
Edit history: 25-JAN-89, Version 1 by Chapman
              
 
Problem Description:

The Common Lisp language description makes use of many commonly-used
English words for both their establish meanings and for special
purposes. Since the standard is required to be unambiguous, 
a way was devised to distinguish an English word from special word of the same
name. 

Proposal (FONTS:STANDARD)

Following is a list of the types of words that have been chosen for 
special fonting and the name of the font used to represent each.

Word type 						Font name

Objects of type xxx (e.g. symbols)			Slanted 10 point
Words in the glossary					Italics
Tools in Chapters 6 and 7				Bold 9 point
Words in the keyword package defined by the standard	Bold 9 point
Parameters supplied to functions/macros/special forms	Sans serif 10 point

Rationale:

If the wording in the standard is unambiguous, users of the
standard will find it much easier to write portable code and
conforming implementations.

Current Practice:

CLtL uses fonting mainly for emphasis and for referring to 
parameters in function descriptions.

Adoption Cost:
 
None.
 
Benefits:

The English descriptions in the standard will be less ambiguous.

Conversion Cost:

None. 

Aesthetics:
 
The fonts have been reworked several times in order to improve
readability. It still requires some familiarity with the style
in order to discover its utility.
 
Discussion:

∂02-Feb-89  0728	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Feb 89  07:28:19 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA12594; Thu, 2 Feb 89 07:26:38 PST
Message-Id: <8902021526.AA12594@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Feb 89 10:25
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: ERROR-TERMINOLOGY

Issue:        ERROR-TERMINOLOGY
References:   Chapter 5, Section 5.1, Working draft of the standard
	      CLOS Chapter 1
	      CLtL Chapter 1, Section 1.2.4
              Condition System, Version 18
Category:     Clarification
Edit history: 27-DEC-88, Version 1 by Chapman
              31-JAN-89, Version 2 by Chapman
 
Problem Description:
In CLtL, CLOS and the Condition System, similar but slightly
different language is used to describe
non-normal actions by CL operators. The X3J13 committee needs to
agree on a standard set of terms and their meanings.
 
Proposal (ERROR-TERMINOLOGY:STANDARD TERMS)

TERM			MEANING (including CLtL -> standard conversion)
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
CONFORMING PROGRAM (*)	A program whose code adheres to
			the requirements of conforming code:
			(1) Conforming code shall not use any constructions 
			that are prohibited by the standard.
			(2) Conforming code shall not depend on 
			extensions included in an implementation.

SAFE CODE (*)		Code processed with the SAFETY optimization at its
			highest setting. SAFETY is a lexical property of code.

UNSAFE CODE  (*) 	Code processed with lower safety levels.
		        Note that `unsafe code' is not necesarily code that
		        does not do error checking. In many cases it may
		        do less error checking, but no guarantee that error
		        checking will be less in unsafe code is expressed or
		        implied. Implementations are permitted to treat all
		        code as safe code all the time, by simply ignoring
		        the SAFETY quality or the entire OPTIMIZE declaration.

IS SIGNALLED   		An error is signalled in both safe and 
			unsafe code.
			Conforming programs may rely on the fact that 
			the error will be signalled in both safe 
			and unsafe code.
     			Every implementation is required to detect the error
			in both safe and unsafe code.
			For example, "an error is signalled if 
			UNEXPORT is given a symbol not accessible in 
			the current package."

SHOULD BE SIGNALLED 	An error will be signalled in safe code, and an error
		        might or might not be signalled in unsafe code.
		        A conforming program may only rely on an error's being
		        signalled if the code doing the signalling is
		        known to be safe. 
			Every implementation is required to detect the error
			at least in safe code.
			When the error is not signalled, the "consequences 
			are undefined" (see below).
			The situation which has been identified as an error is
			illegal in all implementations, but some 
			implementations do not actually detect the situation.
			For example, "an error should be signalled if ENDP is
			given a non-list argument."

CONSEQUENCES ARE UNDEFINED The consequences are unpredictable. The consequences
			may range from halting the running Lisp system or
			leaving the file system in an inconsistent state, to
			directly entering the debugger or accidentally 
			violating the integrity of a user data structure,
			but the consequences are not limited to the above
			examples.
			No portable program can depend on 
			the consequences of this
			situation, and all portable programs are required 
			to treat the situation
			as unpredictable.
			In places where the words "must", "must not"
			or "may not" are used, then "the consequences are 
			undefined" if the stated requirement
			is not met, and no specific consequence is 
			explicitly stated.
			Implementations can do anything in this situation, but
			should not try to do anything useful since the 
			result will be ignored.
			Users should never depend on the result of this 
			situation.
			For example: CLtL currently says: (page 69)
			"Once a name has been declared by DEFCONSTANT to
			be constant, any further assignment or binding
			of that special variable is an error." This statement
			would be transformed to: "Once a name has been declared 
			by DEFCONSTANT to
			be constant, any further assignment or binding
			of that special variable has undefined consequences." 

RETURN VALUES ARE UNDEFINED Only the number and nature of the return values 
			of a construct are not well defined but any 
			side-effect and transfer-of-control behavior is
			well defined. 
			For example, if the return values of some 
			function F are undefined,
			then an expression such as 
			(length (list (F))) is still well-defined
			because it does not rely on any 
			particular aspect of the value or values
			returned by F.

CONSEQUENCES ARE UNSPECIFIED The consequences are unpredictable but can
			potentially lead to bad effects since subsequent
			control flow may depend on the unspecified data
			flow. The debugger is not entered automatically
			in this situation, and normally is not entered at
			all.
			Implementations are allowed to specify the 
			consequences of this situation.
			Implementations are allowed to detect this situation and
			signal an error, but no implementation is required 
			to detect the situation.
			No conforming program may depend on the effects of this
			situation, and all conforming programs are required to 
			treat the effects of this situation as unpredictable.

IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat
			the situation in ANY ONE of the following ways:
			(1)When the situation occurs, an 
			error is signalled at least
			in safe situations, 
			OR
			(2)When the situation occurs, the 
			"consequences are undefined", 
			OR
			(3)When the situation occurs, the consequences 
			are defined.
			Also,
			no portable program can depend on 
			the consequences of this
			situation, and all portable programs are 
			required to treat the 
			consequences of the situation as undefined.
			Implementations can do anything in this situation. 
			The two most common approaches
			are to define a useful (but non-portable) behavior 
			or to signal an error.
			The former approach allows a richer environment for 
			the particular implementation
			in question, but makes the development of portable 
			code more difficult because
			the distinction between portable and non-portable 
			features becomes blurred.
			The latter approach promotes portable programs by 
			forcing the programmer to
			resign himself to features which can be portably 
			depended on, but can adversely
			affect the ease of use for programmers not trying 
			to develop portable code.
			Users should consult the implementation 
			reference manual to determine
			the result of this situation, but 
			should never depend on the result of
			this situation in portable code.
			For example, "implementations may be extended
			to define other type
			specifiers to have a corresponding class."

FREE TO EXTEND THE SYNTAX Implementations are allowed to 
			define unambiguous extensions
			to the syntax of the construct being described.
			No portable program can depend on this extension,
			all portable programs are required to treat the syntax
			as meaningless.
			The standard may disallow certain extensions 
			while allowing others.
			For example, "no `implementation is free 
			to extend the syntax' of DEFCLASS."

WARNING IS ISSUED	A warning is issued, as described in WARN,
			in both safe and unsafe code and when the situation is
			detected by the compiler.           
			Conforming programs may rely on the fact that a 
			warning will be issued
			in both safe and unsafe code and when the 
			situation is detected by the compiler.
			Every implementation is required to detect this 
			situation in both safe and unsafe code and 
			when the situation is detected by the compiler.
			The presence of a warning will in no 
			way alter the value returned
			by the form which caused the situation to occur.
			For example,
			"a warning is issued by the compiler
			if a declaration specifier is not one of those
			defined in Chapter 9 of CLtL and has not been 
			declared in a DECLARATION
			declaration."

WARNING SHOULD BE ISSUED A warning may be issued.
			Conforming programs may not rely on the 
			fact that a warning will be issued.
			If the situation is detected by the compiler, a
			warning may or may not be issued, depending on 
			the implementation.
			The presence of a warning will in no way alter 
			the value returned by the form which caused the 
			situation to occur.
			For example, (paraphrasing from CLtL, p. 160)
			"a warning should be issued by a compiler
			if a variable declared to be ignored is 
			ever referred to or is also declared special, or if 
			a variable is lexical, never referred to,
			and not declared to be ignored."
			(see Chapter 9, CLtL)


(*) means this term is used to define other terms in this proposal,
not explicitly used in the standard.
 
Rationale:

For the standard to be an exact specification, terminology must be
defined and agreed upon. 
 
Current Practice:

CLtL uses "is signalled", "should be signalled", "is an error", 
"a warning is issued", and "a warning should be issued". CLOS 
and the Condition System use
"is undefined" "is unspecified", "may be extended", 
"free to extend the syntax", and "return values are undefined". 
The definition of "is an error" in CLtL has come to mean "is allowed"
in places where implementations typically extend the language. 

Adoption Cost:

The cost of adopting this terminology will be mostly associated with the 
change from "is an error" to some other more specific terminology
from the above list (typically "is an error" -> "is undefined").

Benefits:

Specific terminology will disambiguate function descriptions which
will save implementor's time and decrease user frustration. Users should
be able to write more portable code if the specification is exact. 
 
Conversion Cost:

See Adoption Cost.
 
Aesthetics:

None.
 
Discussion:

∂02-Feb-89  0728	CL-Editorial-mailer 	Issue: TOC    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Feb 89  07:28:20 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA12630; Thu, 2 Feb 89 07:26:41 PST
Message-Id: <8902021526.AA12630@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Feb 89 10:26
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: TOC

Issue:        TOC
References:   Working draft of the standard
Category:     Editorial
Edit history: 25-JAN-89, Version 1 by Chapman
 
Problem Description:

The Table of Contents of the standard has changed several times since
the first one was introduced in November, 1987. One step in finalizing
the standard is to agree on the TOC.

Proposal (TOC:STANDARD)

Chapter 1. Introduction                           
CONTENTS
1.1 Scope, Purpose, and Application               
1.2 Organization of the Document                  
1.3 Referenced Publications                       
1.4 Definitions                                   
1.5 Compliance                                    
1.6 Implementation-defined Features               
Values
Results
Data Representation and Typing
Program and Control Structure
Comparisons
Numerical Calculations
User Interface
Input/Output
Compiling
Miscellaneous
Programming Environment
1.7 Language Extensions                           
1.8 Portability Issues                            

Chapter 2. Objects and Types                      
CONTENTS
2.1 Introduction                                  
2.2 Types                                         
Type Hierarchy and Relationships
Data Type Definition
Type Specifiers
2.3 Classes                                       
Introduction to Classes
Metaclasses
Standard Metaclasses
Defining Classes
Creating Instances of Classes
Inheritance
Inheritance of Class Options
Examples
Determining the Class Precedence List
Topological Sorting
Examples
Redefining Classes
Modifying the Structure of Instances
Initializing Newly Added Local Slots
Customizing Class Redefinition
Extensions
Integrating Types and Classes
2.4 Slots                                         
Introduction to Slots
Accessing Slots
Inheritance of Slots and Slot Options
2.5 Objects                                       
Object Creation and Initialization
Initialization Arguments
Declaring the Validity of Initialization Arguments
Defaulting of Initialization Arguments
Rules for Initialization Arguments
Shared-Initialize
Initialize-Instance
Definitions of Make-Instance and Initialize-Instance
Changing the Class of an Instance
Modifying the Structure of the Instance
Initializing Newly Added Local Slots
Customizing the Change of Class of an Instance
Reinitializing an Instance
Customizing Reinitialization
Meta-Objects
Standard Meta-objects

Chapter 3. Object Syntax                          
CONTENTS
3.1 Character Reader                              
Reader Algorithm
Numbers as tokens
Symbols as tokens
Macro character collection
3.2 Object Syntax                                 

Chapter 4. Evaluation and Compilation             
CONTENTS
4.1 Evaluation Model                              
Introduction
Context and Environment
The Model
Form evaluation
Self-evaluating forms
Symbols as forms
Conses as forms
Return values
Shadowing
Extent
Generic Functions and Methods
Introduction to Generic Functions
Introduction to Methods
Agreement on Parameter Specializers and Qualifiers
Congruent Lambda-Lists for All Methods of a Generic Function
Keyword Arguments in Generic Functions and Methods
Method Selection and Combination
Determining the Effective Method
Standard Method Combination
Declarative Method Combination   
Built-in Method Combination Types
Inheritance of Methods
Lambda-expressions
4.2 Compilation                                   

Chapter 5. Other Topics                           
CONTENTS
5.1 Errors                                        
Error Terminology
Condition System Concepts
Condtion System Data Types
Condtion System Operation
5.2 Input/Output
Files
Character and Binary Input/Output
Loading         
5.3 Interface with the Programming Environment                 
Top level loop
Environment inquiry
Time
5.4 Generalized Reference                         

Chapter 6. Catalog of Tools (A-M)                 		 
A-F plus non-alphabetics			  
G-M                                               

Chapter 7. Catalog of Tools (N-Z)                                
N-S                                               
T-Z                                               

Rationale:

The current TOC is a result of a year's worth of meetings and many
discussions of the editorial committee. The organization loosely
follows the CLOS chapters 1 and 2 organization by putting the 
concepts first, and followed by an alphabetic listing of the
functions/macros/special forms/variables/constants.  
The information that deals with data types is organized according to
the Lisp type hierarchy, and a listing of each language element
that is associated with that data type is located at the end
of each data type description in Chapter 2. These listings are
derived from the contents of the chapters in CLtL.

If we come to the conclusion that the standard should be shortened,
Chapters 6 and 7 can be modified to include fewer tools, and section
6.1 can be modified to reflect movement of some of the non-essential
parts of each description to an appendix.

Current Practice:

CLtL, as well as many other Lisp language specifications,
are organized by data types. The Lucid reference manual's chapters
each deal with a data type, but within those chapters, the information
is organized by concepts followed by an alphabetic listing of 
language elements.

CLOS chapters 1 and 2 are organized by concepts first and an
alphabetic listing of language elements next.

Adoption Cost:
 
None.
 
Benefits:

The data type organization is useful for describing Lisp, and is therefore
used in chapters 2 and 3. However, categorizing
language elements by the data types they are meant to be used with imposes
an unnecessary structure on the document. 

Conversion Cost:

None. 

Aesthetics:
 
None.
 
Discussion:
 

∂02-Feb-89  0726	CL-Editorial-mailer 	Issue: CUT-OFF-DATES    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Feb 89  07:26:25 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA12488; Thu, 2 Feb 89 07:24:45 PST
Message-Id: <8902021524.AA12488@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Feb 89 10:23
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: CUT-OFF-DATES


 Issue:        CUT-OFF-DATES
 References:   Working draft of the standard
 Category:     Policy
 Edit history: 20-DEC-88, Version 1 by Chapman
               9-JAN-89, Version 2 by Chapman
               25-JAN-89, Version 3 by Chapman
               
  
 Problem Description:
 
 The X3J13 committee has informally agreed that a 12/89 standard is 
 a doable goal. However, the standard has to be reviewed by a large
 number of people outside the X3J13 committee. We must allow plenty 
 of time for these reviews, and should therefore plan our internal
 reviews and "document freeze" accordingly.
 
 Proposal (CUT-OFF-DATES:ESTABLISH)
 
 Item						           Dates 
 ________________________________________________Final Changes___Letter Ballot__
 Format of tool descriptions			   11/1/88        2/21/89
 Meaning of each item in each tool description     11/1/88        2/21/89
 Fonts                                             2/1/89         2/21/89
 Changes via clean-up to existing functions        4/1/89
 Adding functions via clean-up                     3/15/89
 Conformance issues                                3/1/89	  mtg
 Error terms					   2/19/89        2/21/89
 Changes to TOC					   2/19/89        2/21/89
 
 Contents of sections:                             
 
 Chapter 1. Introduction                           4/1/89         n/a
 CONTENTS
 1.1 Scope, Purpose, and Application               3/1/89         mtg
 1.2 Organization of the Document                  3/1/89         mtg
 1.3 Referenced Publications                       3/1/89         mtg
 1.4 Definitions                                   3/1/89         mtg
 1.5 Compliance                                    3/1/89         mtg
 1.6 Implementation-defined Features               3/15/89        mtg
 Values
 Results
 Data Representation and Typing
 Program and Control Structure
 Comparisons
 Numerical Calculations
 User Interface
 Input/Output
 Compiling
 Miscellaneous
 Programming Environment
 1.7 Language Extensions                           3/1/89         mtg
 1.8 Portability Issues                            2/19/89        2/21/89
 
 Chapter 2. Objects and Types                      4/1/89         4/14/89
 CONTENTS
 2.1 Introduction                                  3/15/89        mtg
 2.2 Types                                         3/22/89        mtg
 Type Hierarchy and Relationships
 Data Type Definition
 Type Specifiers
 2.3 Classes                                       2/19/89        2/21/89
 Introduction to Classes
 Metaclasses
 Standard Metaclasses
 Defining Classes
 Creating Instances of Classes
 Inheritance
 Inheritance of Class Options
 Examples
 Determining the Class Precedence List
 Topological Sorting
 Examples
 Redefining Classes
 Modifying the Structure of Instances
 Initializing Newly Added Local Slots
 Customizing Class Redefinition
 Extensions
 Integrating Types and Classes
 2.4 Slots                                         2/19/89        2/21/89
 Introduction to Slots
 Accessing Slots
 Inheritance of Slots and Slot Options
 2.5 Objects                                       2/19/89        2/21/89
 Object Creation and Initialization
 Initialization Arguments
 Declaring the Validity of Initialization Arguments
 Defaulting of Initialization Arguments
 Rules for Initialization Arguments
 Shared-Initialize
 Initialize-Instance
 Definitions of Make-Instance and Initialize-Instance
 Changing the Class of an Instance
 Modifying the Structure of the Instance
 Initializing Newly Added Local Slots
 Customizing the Change of Class of an Instance
 Reinitializing an Instance
 Customizing Reinitialization
 Meta-Objects
 Standard Meta-objects
 
 Chapter 3. Object Syntax                          4/14/89	 5/14/89
 CONTENTS
 3.1 Character Reader                              4/1/89         4/14/89
 Reader Algorithm
 Numbers as tokens
 Symbols as tokens
 Macro character collection
 3.2 Object Syntax                                 4/8/89         4/14/89
 
 Chapter 4. Evaluation and Compilation             5/1/89         5/14/89
 CONTENTS
 4.1 Evaluation Model                              4/14/89        5/14/89
 Introduction
 Context and Environment
 The Model
 Form evaluation
 Self-evaluating forms
 Symbols as forms
 Conses as forms
 Return values
 Shadowing
 Extent
 Generic Functions and Methods
 Introduction to Generic Functions
 Introduction to Methods
 Agreement on Parameter Specializers and Qualifiers
 Congruent Lambda-Lists for All Methods of a Generic Function
 Keyword Arguments in Generic Functions and Methods
 Method Selection and Combination
 Determining the Effective Method
 Standard Method Combination
 Declarative Method Combination   
 Built-in Method Combination Types
 Inheritance of Methods
 Lambda-expressions
 4.2 Compilation                                   4/22/89	 5/14/89
 
 Chapter 5. Other Topics                           4/1/89	 4/14/89
 CONTENTS
 5.1 Errors                                        3/15/89        mtg
 Error Terminology
 Condition System Concepts
 Condtion System Data Types
 Condtion System Operation
 5.2 Input/Output                                  3/8/89         mtg
 Files
 Character and Binary Input/Output
 Loading
 5.3 Interface with the Programming Environment    3/8/89         mtg
 Top level loop
 Environment inquiry
 Time
 5.4 Generalized Reference                         3/8/89         mtg
 The following sections in the standard:
 
 Chapter 6. Catalog of Tools (A-M)                 		  6/14/89
 A-F plus non-alphabetics			   4/1/89         4/14/89
 G-M                                               5/1/89         5/14/89
 
 Chapter 7. Catalog of Tools (N-Z)                                6/30/89
 N-S                                               6/1/89         6/14/89
 T-Z                                               6/14/89        6/30/89
 
 Glossary                                          4/1/89         4/14/89
 
 
 
 The following will  be decided by a letter ballot mailed on 2/21/89:
 
 This list of cut-off-dates (issue CUT-OFF-DATES)
 Format of tool descriptions (in Chapters 6 and 7)
 Meaning of each item in each tool description (Section 6.1) 
 Fonts used for distinguishing special words and phrases (issue FONTS)
 Error terms (issue ERROR-TERMINOLOGY)
 Table of Contents of the standard (issue TOC)
 The following sections in the standard:
  1.8 Portability Issues 
  2.3 Classes
  2.4 Slots
  2.5 Objects
 
 
 The following will  be decided at the 3/89 meeting:
 
 Conformance issues (the issues presented at the 1/89 meeting)
 Chapter 1. Introduction (even though all parts have been voted on,
    chapter 1 as a whole should be voted on)
 The following sections in the standard:
  1.1 Scope, Purpose, and Application               
  1.2 Organization of the Document                  
  1.3 Referenced Publications                       
  1.4 Definitions                                   
  1.5 Compliance                                    
  1.6 Implementation-defined Features               
  1.7 Language Extensions                           
  2.1 Introduction                                  
  2.2 Types                                         
  5.1 Errors                                        
  5.2 Input/Output                                  
  5.3 Interface with the Programming Environment                 
  5.4 Generalized Reference                         
 
 The following will  be decided by a letter ballot mailed on 4/14/89:
 
 Chapter 2. Objects and Types (ditto, chapter 1)
 Chapter 5. Other Topics (ditto, chapter 1)
 Glossary
 The following sections in the standard:
  3.1 Character Reader                              
  3.2 Object Syntax                                 
  Chapter 6, A-F plus non-alphabetics	          
 
 The following will  be decided by a letter ballot mailed on 5/14/89:
 
 Chapter 3. Object Syntax (ditto, chapter 1)
 Chapter 4. Evaluation and Compilation (ditto, chapter 1) 
 The following sections in the standard:
  4.2 Compilation                                   
  G-M                                               
 
 The following will  be decided by a letter ballot mailed on 6/14/89:
 Chapter 6. Catalog of Tools (A-M) (ditto, chapter 1)
 The following section in the standard:
  N-S                                               
 
 The following will  be decided by a letter ballot mailed on 6/30/89:
 Chapter 7. Catalog of Tools (N-Z) (ditto, chapter 1)
 The following section in the standard:
  T-Z                                               
 
 All comments received according to this schedule will be incorporated
 by 6/30/89. Any comments received after the dates listed above will 
 only be considered if they are of an extreme nature, if they impact
 the correctness of the document. Otherwise the comments will be filed
 and reserved for the next standard.
 
 To change these dates, a 2/3 vote of the editorial committee
 or a majority vote of X3J13 is required.
 
 Rationale:
 
 In order to complete this standard and move on to the next version,
 we need to establish dates after which changes will not be allowed.
  
 Current Practice:
 None.
 
 Adoption Cost:
  
 None.
  
 Benefits:
 
 Establishing cut-off dates will encourage reviewers to complete
 a thorough review in a timely manner.
  
 Conversion Cost:
 
 None. 
 
 Aesthetics:
  
 None.
  
 Discussion:
  
 Comment:
 "There are a couple of areas where I expect some further work that might
 impact these dates:
  
 a) pathname functions
 I'm still hoping to get some cleanup of many of the pathname issues
  
 b) errors signalled, by name
 I'm still hoping that we can get at least a partial listing, for each
 function, of the possible errors signalled, under what circumstances. 
  
 c) pending cleanups
 There will probably be 10-15 cleanup issues dealing with ambiguities that
 will drag out beyond 3/89. I hope not, but I'm trying to be realistic;
 there are just too many "open" issues left."

∂02-Feb-89  0822	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Feb 89  08:22:44 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA17198; Thu, 2 Feb 89 08:20:57 PST
Message-Id: <8902021620.AA17198@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Feb 89 11:18
To: cl-editorial@sail.stanford.edu, maxiv@mu.edu, skona%csilvax@hub.ucsb.edu,
        sandra%defun@cs.utah.edu
Subject: Issue: CONFORMANCE-POSITION

Would you all make a pass over this before I send it to X3J13?

Thanks.
kc

Issue:        CONFORMANCE-POSITION
References:   Chapter 1, Section 1.5, Working draft of standard
Category:     Clarification
Related Issues: EXTENSIONS-POSITION, LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Edit history: 12-DEC-88, Version 1 by Chapman
              20-DEC-88, Version 2 by Chapman 
              9-JAN-89, Version 3 by Chapman 
              10-JAN-89, Version 4 by Chapman 
              2-FEB-89, Version 5 by Chapman 
 
Problem Description:
 
Two ways of defining conformance are in terms of a conforming program
and in terms of a conforming implementation. How should our standard
define conformance? What is the relationship between conformance and
portability?
 
 
Proposal (CONFORMANCE-POSITION:IMPLEMENTATION-AND-PROGRAM)
 
The standard presents the syntax and semantics to be implemented by
a conforming implementation.

The basic test for conformance will be that a program written to the letter 
of the standard will run in all "conforming" implementations.
The basic rules are as follows:
. Conforming programs use the syntax described in the standard.
. Conforming programs are written using the functions, macros,
special forms, variables, constants described in the standard.
. Conforming implementations provide the functions, macros, special
forms, variables, constants, and arrange that they behave in ways 
that conform to the descriptions of them in the standard.

A portable program is required to produce equivalent results and 
observable side effects in all conforming implementations.   
 
It's possible for a conformal program to
run in all conformal implementations, but to have allowable
implementation-dependent behavior which could make it non-portable.
Insofar as we allow options in the standard this will be true.
 
Rationale:
 
The standard must contain information about conformance. Only including 
requirements which would be placed on implementations, however, leaves
the possiblity open that something would be overlooked, and so 
implementations may well conform without processing correctly
conforming programs.
 
Current Practice:

CLtL generally describes things in terms of what a correct program can
expect, but the document itself levies the requirement on an implemention
to support all the described functionality.

dpANS C is also in terms of programs.  They have further defined
both "conforming" and "strictly conforming" programs; the
difference has something to do with how the program deals with features
that the standard says are implementation-defined.
 
Pascal defines 
conformance in terms of both, PL/I defines conformance in terms of 
conforming programs only.
Fortran and Ada say that a conforming implementation correctly processes
conforming programs. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both programs and implementations.
 
Adoption Cost:
 
None.
 
Benefits:
 
This definition will give readers and validators a basis on which to read
the standard.
 
Conversion Cost:
 
None.
 
Aesthetics:
 
None.
 
Discussion:
 

∂02-Feb-89  0825	CL-Editorial-mailer 	Please review ASAP 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Feb 89  08:24:56 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA17338; Thu, 2 Feb 89 08:23:20 PST
Message-Id: <8902021623.AA17338@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Feb 89 10:22
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Please review ASAP

Please review the following and comment before Feb. 7. The issues listed
below fall into two categories: issues that reflect the state of the current
standard and conformance-related issues. In an effort to come to closure
on the standard, I have decided to divide it into pieces and call for a
vote on the separate pieces. You can see a summary of the divisions I have
made in the revised issue, CUT-OFF-DATES. 

Following this message you will receive copies of all the issues listed
below. The turn-around time for comments from you is short for two reasons:
the set of these issues that reflects the current state of the standard should
be no news to you since we have been discussing them since 11/87; the
conformance-related issues are going to be mostly debated on the X3J13 mailing
list as was discussed at the 1/89 meeting. X3J13 will only have until 2/19
to comment on the issues and other things that will go in the 2/21 letter
ballot, so I want to get these issues to them ASAP.

Thanks for your help!
kc

Letter ballot (2/21/89)

CUT-OFF-DATES
FONTS
ERROR-TERMINOLOGY
TOC
1.8 Portability Issues
2.3 Classes
2.4 Slots
2.5 Objects
6.1 Intro to catalog of tools



3/89 meeting 

EXTRA-SYNTAX
EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
UNSPECIFIED-DATATYPES
EXTRA-RETURN-VALUES
UNSOLICITED-MESSAGES
MACRO-AS-FUNCTION
CONFORMANCE-POSITION
EXTENSIONS-POSITION
SUBSETTING-POSITION

Chapter 1 - all parts except 1.8 will be voted on separately, then
Chapter 1 as a whole will be voted on.
2.1 Introduction
2.2 Types
5.1 Errors
5.2 Input/Output
5.3 Interface with the Programming Environment
5.4 Generalized Reference

∂02-Feb-89  0842	CL-Editorial-mailer 	Issue: FONTS  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Feb 89  08:42:42 PST
Received: from fafnir.think.com by Think.COM; Thu, 2 Feb 89 11:31:15 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 2 Feb 89 11:37:47 EST
Received: by verdi.think.com; Thu, 2 Feb 89 11:37:18 EST
Date: Thu, 2 Feb 89 11:37:18 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902021637.AA18328@verdi.think.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 2 Feb 89 10:24 <8902021525.AA12549@decwrl.dec.com>
Subject: Issue: FONTS

   From: chapman%aitg.DEC@decwrl.dec.com
   Date: 2 Feb 89 10:24

   Issue:        FONTS
   References:   Working draft of the standard
   Category:     Clarifiaction
   Edit history: 25-JAN-89, Version 1 by Chapman


Looks fine to me.  Good work.
--Guy

∂02-Feb-89  0850	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Feb 89  08:50:12 PST
Received: from fafnir.think.com by Think.COM; Thu, 2 Feb 89 11:36:48 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 2 Feb 89 11:43:16 EST
Received: by verdi.think.com; Thu, 2 Feb 89 11:42:49 EST
Date: Thu, 2 Feb 89 11:42:49 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902021642.AA18350@verdi.think.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, maxiv@mu.edu, skona%csilvax@hub.ucsb.edu,
        sandra%defun@cs.utah.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 2 Feb 89 11:18 <8902021620.AA17198@decwrl.dec.com>
Subject: Issue: CONFORMANCE-POSITION

   From: chapman%aitg.DEC@decwrl.dec.com
   Date: 2 Feb 89 11:18

   Would you all make a pass over this before I send it to X3J13?


   Issue:        CONFORMANCE-POSITION
   ...
		 2-FEB-89, Version 5 by Chapman 

I read this pretty carefully, and it looks okay.
--Guy

∂02-Feb-89  0853	CL-Editorial-mailer 	Re: Issue: CONFORMANCE-POSITION   
Received: from cs.utah.edu ([128.110.4.21]) by SAIL.Stanford.EDU with TCP; 2 Feb 89  08:53:31 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA06623; Thu, 2 Feb 89 09:51:56 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA27664; Thu, 2 Feb 89 09:51:52 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902021651.AA27664@defun.utah.edu>
Date: Thu, 2 Feb 89 09:51:51 MST
Subject: Re: Issue: CONFORMANCE-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com, 2 Feb 89 11:18

I have two minor wording suggestions:
 
> . Conforming programs use the syntax described in the standard.
                            ↑↑↑
                            only

> . Conforming programs are written using the functions, macros,
                                          ↑↑↑
                                          only

I also have a concern about how conformance relates to compilation.
It is reasonable to expect that if a program is conforming, then it
will be possible to compile it with COMPILE-FILE.  But some people
have been pushing for placing some additional constraints on programs
processed by COMPILE-FILE that will explicitly not apply to
interpreted programs or functions compiled with COMPILE (in
particular, on what kinds of objects may appear in quoted constants).
Plus, it also seems like we will be requiring certain things (type
definitions, package structure, etc) to be defined consistently at
COMPILE-FILE and LOAD time.  Do you have any suggestions on how we
should state these requirements? 

-Sandra
-------

∂02-Feb-89  0900	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Feb 89  08:59:43 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA19844; Thu, 2 Feb 89 08:57:46 PST
Message-Id: <8902021657.AA19844@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Feb 89 11:25
To: cl-editorial@sail.stanford.edu, maxiv@mu.edu, skona%csilvax@hub.ucsb.edu,
        sandra%defun@cs.utah.edu
Subject: Issue: SUBSETTING-POSITION

I'm sending this one out again to you before sending it to X3J13. If there
are no comments by 2/14, I'll send in on the X3J13.
kc

Issue:        SUBSETTING-POSITION
References:   X3J13 committee and sub-committee meetings
Category:     Policy
Edit history: 12-DEC-88, Version 1 by Chapman
              9-JAN-89, Version 2 by Chapman 
              10-JAN-89, Version 3 by Chapman 
              
 
Problem Description:
 
Should the CL standard be partitioned such that an implementation
could chose a subset of all the CL facilities to implement and 
still be a conforming implementation?
What subsets should be specified in the draft standard we submit to
ANSI?
What position should we take if someone should propose a subset?

Subsets might omit syntax, functions, admissable values or arguments
to functions, or data types. For example, a subset might disallow SPECIAL
declarations (a syntactic subset), might omit the COS, SIN, ATAN functions,
might disallow the :TEST keyword to MAKE-HASH-TABLE, might restrict TAILP
to work on proper lists, or might omit complex numbers. Each of these is a
"subset" in the sense that a subset of correct programs for the "full"
language would be correct for the "subset" language.
 
Subsets can have various levels of "determinability" for programs. The
issue is: how easy is it to tell whether a program written in the "full"
language would run in a "subset" implementation?  Except for the
(non-trivial) issue of macro expansions, some subsets are "lexically"
determinable, e.g., if a function is omitted, you can tell if the program
uses it by scanning the program. Some subsets are "dynamically"
determinable, e.g, a subset might signal an error if the :TEST argument to
MAKE-HASH-TABLE is EQUALP. Some subsets are neither lexically nor
dynamically determinable, e.g., if the subset implements dynamic extent for
rest lists, it may be impossible to tell even with run-type checks whether
the a program written in the "full" language would conform.
 
Some "subsets" might be merely restrictive interpretations, e.g., a
"run-time" implementation that made ED, TRACE, UNTRACE into no-ops and made
BREAK halt the program execution rather than "enter the debugger"; since we
cannot define what "enter the debugger" means, we might want to define
explicitly this subset as a reasonable one for embedded systems.
 
Proposal (SUBSETTING-POSITION:NONE)

The draft standard we submit to ANSI 
contains *no* subsets. In the section on "subsetting" it should be mentioned
that Lisp is a "small" language with a "big" library and that the conventional
mechanism for allowing small memory images is auto-load.
 
 
Rationale:
 
 
Current Practice:
 
Pascal has two levels of conforming implementations -- level 1 contains
level 0 and conformant arrays. This was a compromise necessary to achieve
international agreement. The 1981 PL/I was subsetted and the 
results were a range of implementations between the
subset and the full language; nobody wanted to use the subset so vendors
were forced to implement the full language eventually anyway.
Cobol had multiple levels of subsets. However, 
the only two levels that were important were the minimum 
subset and the full language. The middle levels were
seldom used other than transient points to the full language.
Fortran was subsetted. It was felt that subsetting encouraged
vendors to implement Fortran and therefore proliferate its usage,
but users were quite annoyed that one Fortran was considerably
different from another. 
The new Fortran language standards committee is
banning subsetting.
At one point,
there was an ANSI standard for "Minimal Basic".  It was too minimal.
Later work on ANSI Basic involved a rather different-looking language
(think "structured control structures") and a number of optional
extensions for such things as real-time process control. 
SPARC feels that 
subsets aren't good for facilitating interchange, but serve the
purpose of allowing
timely implementation of the standard.
 
A suggestion that was made by most language committee representatives
was to group subsetted parts meaningfully, and to minimize the number
of levels.
 
Adoption Cost:
 
None.
 
Benefits:
 
This policy will provide a basis for making decisions in X3J13.
 
Conversion Cost:
 
None.
 
Aesthetics:
 
None.
 
Discussion:
Jeff Dalton says: 
I'd be happier if it were fairly easy for someone reading the standard
to determine which part was the "library" and which the core language.
For example, where do we find FUNCALL and APPLY?
The draft C standard has an explicit division.  Section 3 is
"Language" and section 4 is "Library".  It may not be necessary
to go that far for Common Lisp.

∂02-Feb-89  0921	CL-Editorial-mailer 	Issue: EXTENSIONS-POSITION   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Feb 89  09:21:30 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA21460; Thu, 2 Feb 89 09:19:43 PST
Message-Id: <8902021719.AA21460@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Feb 89 11:40
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu, maxiv@mu.edu,
        andra%defun@cs.utah.edu
Subject: Issue: EXTENSIONS-POSITION

I think the wording in this proposal is too wimpy, but need some help
un-wimping it without unduly constraining implementations.
Please comment by 2/14.
Thanks.
kc


Issue:        EXTENSIONS-POSITION
References:   Chapter 1, Working draft of standard
Category:     Clarification
Related Issues: CONFORMANCE-POSITION, IF-BODY, ERROR-TERMINOLOGY
Edit history: 12-DEC-88, Version 1 by Chapman
              20-DEC-88, Version 2 by Chapman
              9-JAN-89, Version 3 by Chapman
              10-JAN-89, Version 4 by Chapman
              2-FEB-89, Version 5 by Chapman
 
Problem Description:
 
What is the definition of a language extension?
What effect does a language extension have on a conforming program? 
What obligation does an implementation have to warn the user that an 
extension is being used?

 
Proposal (EXTENSIONS-POSITION:DOCUMENTATION)
 
The standard document should define a language extension to be
any implementation-supplied tool that isn't explicitly defined
in the standard. This includes facilities added to tools defined
in the standard.
The standard document should levy the following requirement on a 
conforming implementation's documentation:
The documentation that accompanies a conforming implementation should clearly
state which parts of the implementation are extensions.  


If the standard says that "the results are unspecified", and an
implementation specifies the results, this an extension in the
sense that if the correct behavior of a program depends on the results,
only implementations with the same extension will execute the program
correctly.

In places where the standard says that "an implementation may be extended",
this implies that a conforming, but probably non-portable, program can
be written using the implementation's extension.

Proposal (EXTENSIONS-POSITION:DISABLE)

Same as EXTENSIONS-POSITION:DOCUMENTATION except that
an implementation is required to have a way to disable its extensions, so
that a programmer can be told when he is using a feature that might
affect his program's portability. 


Rationale:
 
The standard should contain information about language extensions
since most implementations have extended the language.
 
Current Practice:

CLtL allows any extension, provided that it doesn't alter the behavior
of a program that only uses what is specified in CLtL.  In particular,
any situation that "is an error" (either explicitly or implicitly) is a
potential area for extension.
 
 
Adoption Cost:
 
Vendors will have to improve their documentation
to list all their extensions.  Vendors will have to go through their
implementation and determine what is or isn't an extension.
 
 
Benefits:
 
This definition will provide a basis for proper understanding of 
the error terminology used in the standard. The implementation
documentation requirement will aid the user in producing portable code.
 
Conversion Cost:
 
None.
 
Aesthetics:
 
None.
 
Discussion:
Masinter says:
It seems to be a constraint on "documentation" rather than "implementation"
if you turn the accidental behavior of (CAR T) into a "feature" of your
implementation. We might want to disallow such an extension as "conforming
to the standard". An implementation which had such an extension might
conform, even if the extension did not conform.

∂02-Feb-89  0925	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Feb 89  09:25:32 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 532437; Thu 2-Feb-89 12:22:37 EST
Date: Thu, 2 Feb 89 12:22 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SUBSETTING-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu, maxiv@mu.edu,
    skona%csilvax@hub.ucsb.edu, sandra%defun@cs.utah.edu
In-Reply-To: <8902021657.AA19844@decwrl.dec.com>
Message-ID: <890202122220.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

I'd like to us to also say:
 - why we did not go with subsets
 - what our attitude is toward subsets that might
   emerge in the future.

The following text is my personal view which others might want to 
react to in order to help form a consensus. I would add it to the
end of the existing Proposal. Although it (or whatever we end up
with after discussion) has the sound of a Rationale, I think it
belongs in the Proposal part so that it's clear that it's part of
what we're really voting on, and so that we can feel comfortable
including wording to the same effect in the standard...

-----
 The major reason we did not separate the language core from
 its library was an issue of resources.

 Reducing the size of the total language plus library would have
 been relatively difficult because some parties involved wanted
 to assure that the resulting language was very rich. Our charter
 statement indicated that we were to begin with CLtL and add things,
 not to strip away.

 Some time would have been lost to minor disagreements as to exactly
 which routines were part of the core. Also, considerable time would
 have been lost even to partitioning the core and the library at
 non-controversial points, and to approving that result. 

 Given resource considerations, we chose to standardize on the larger
 language, and to leave open the possibility of other agencies defining
 interesting subsets as part of later endeavors.

 Anyone may at a later time identify some new language as a subset of
 ANSI Common Lisp if (and only if) all valid programs in the new
 language are valid programs in Common Lisp.

∂02-Feb-89  0941	CL-Editorial-mailer 	Re: Issue: EXTENSIONS-POSITION    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Feb 89  09:41:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 FEB 89 09:36:48 PST
Date: 2 Feb 89 09:34 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXTENSIONS-POSITION
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 2 Feb 89 11:40
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu,
 maxiv@mu.edu, andra%defun@cs.utah.edu
Message-ID: <890202-093648-13266@Xerox>

Kathy:

I thought that we should address the different types of extensions
separately. I had written them up separately in "issue" format, although I
don't mind discussing them together, although the treatment might vary for
different kinds.

In particular, I think it is reasonable to disallow extensions to the
syntax of macros & special forms in the LISP package, to disallow extra
optional arguments & extra return values, to allow new named arguments
("keyword" arguments) as long as either the spec says &ALLOW-OTHER-KEYS or
the named arguments are *not* in the keyword package, to allow and
encourage extensions in terms of new or shadowed symbols but not in the
LISP package. The cleanup issue PACKAGE-CLUTTER deals with some part of
this "extension" policy, although indirectly.

These were discussed under titles:

EXTRA-SYNTAX (extensions to syntax of macros & special forms)
EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (extensions to functions argument lists)
EXTRA-RETURN-VALUES (additional values returned)

+ new functions, special forms, macros
+ new behavior defined for values outside of the "defined" range
+ a general "specifying things the standard leaves unspecified"

∂02-Feb-89  0955	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Feb 89  09:55:38 PST
Received: from fafnir.think.com by Think.COM; Thu, 2 Feb 89 12:41:46 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 2 Feb 89 12:48:20 EST
Received: by verdi.think.com; Thu, 2 Feb 89 12:47:33 EST
Date: Thu, 2 Feb 89 12:47:33 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902021747.AA18557@verdi.think.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, maxiv@mu.edu, skona%csilvax@hub.ucsb.edu,
        sandra%defun@cs.utah.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 2 Feb 89 11:25 <8902021657.AA19844@decwrl.dec.com>
Subject: Issue: SUBSETTING-POSITION

   From: chapman%aitg.DEC@decwrl.dec.com
   Date: 2 Feb 89 11:25

   I'm sending this one out again to you before sending it to X3J13. If there
   are no comments by 2/14, I'll send in on the X3J13.
   kc

   Issue:        SUBSETTING-POSITION
   References:   X3J13 committee and sub-committee meetings
   Category:     Policy
   Edit history: 12-DEC-88, Version 1 by Chapman
		 9-JAN-89, Version 2 by Chapman 
		 10-JAN-89, Version 3 by Chapman 

I am in agreement with SUBSETTING-POSITION:NONE.

∂02-Feb-89  1000	CL-Editorial-mailer 	Re: Issue: SUBSETTING-POSITION    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Feb 89  09:59:52 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 FEB 89 09:51:09 PST
Date: 2 Feb 89 09:49 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SUBSETTING-POSITION
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 2 Feb 89 12:22 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu,
 maxiv@mu.edu, skona%csilvax@hub.ucsb.edu, sandra%defun@cs.utah.edu
Message-ID: <890202-095109-13304@Xerox>

Saying that it is a "resource" issue implies some confidence that, with the
addition of a reasonable amount of "resource" one might come up with a
reasonable subset. I don't think that is true. The reason we don't include
a subset is that we don't have a reasonable subset proposal to consider;
while certainly more resources is necessary, it isn't clear that it would
be sufficient.
 
We are not opposed in principle to one or more subset definitions.

We have no well-defined proposals for subset definitions, and didn't have
the time or energy to pursue their definition, or confidence that we could
reach convergence on a reasonable definition.

There are several properties that a subset definition must have to be
considered: it must be well defined in terms of conformance of programs and
implementations; all valid programs in the subset must be valid programs in
the full language; the subset definition should address how it can be
determined if  a program in the full language is valid in the subset. 

∂02-Feb-89  1023	CL-Editorial-mailer 	Re: Issue: SUBSETTING-POSITION    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Feb 89  10:23:21 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 532491; Thu 2-Feb-89 13:21:13 EST
Date: Thu, 2 Feb 89 13:20 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: SUBSETTING-POSITION
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, chapman%aitg.DEC@decwrl.dec.com,
    cl-editorial@sail.stanford.edu, maxiv@mu.edu,
    skona%csilvax@hub.ucsb.edu, sandra%defun@cs.utah.edu
In-Reply-To: <890202-095109-13304@Xerox>
Message-ID: <890202132055.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 2 Feb 89 09:49 PST
    From: masinter.pa@Xerox.COM

    ... while certainly more resources is necessary, it isn't clear that
    it would be sufficient. ...
 
I buy this.

    We are not opposed in principle to one or more subset definitions.

This is the essence of what somehow needs to be added.

    We have no well-defined proposals for subset definitions, and didn't have
    the time or energy to pursue their definition, or confidence that we could
    reach convergence on a reasonable definition.

Right.

    There are several properties that a subset definition must have to be
    considered: it must be well defined in terms of conformance of programs and
    implementations; all valid programs in the subset must be valid programs in
    the full language; the subset definition should address how it can be
    determined if  a program in the full language is valid in the subset. 

While I'm not entirely convinced that all these are really -necessary- to being
a subset (any language description establishes its own goals, and those goals
may not demand the precision of an ANSI standard). On the other hand, without
these restrictions, there would be the possibility for someone to abuse the name
of ANSI CL, so making a few hoops to jump through probably isn't a bad idea
on general principles. Hence, I'll go along with something like this.

∂02-Feb-89  1052	CL-Editorial-mailer 	Re: Issue: SUBSETTING-POSITION    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Feb 89  10:52:10 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA10666; Thu, 2 Feb 89 11:47:18 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA27814; Thu, 2 Feb 89 11:46:51 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902021846.AA27814@defun.utah.edu>
Date: Thu, 2 Feb 89 11:46:49 MST
Subject: Re: Issue: SUBSETTING-POSITION
To: masinter.pa@Xerox.COM
Cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
        chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu,
        maxiv@mu.edu, skona%csilvax@hub.ucsb.edu, sandra%defun@cs.utah.edu
In-Reply-To: masinter.pa@Xerox.COM, 2 Feb 89 09:49 PST

I expect to have more to say on this issue once I've had time to 
consult with others here on our "official" position.  What follows
are just some unofficial thoughts of my own.

I am rather concerned that, with all of the major additions to the
language (particularly CLOS and the LOOP macro), institutions such as
the University of Utah that implement Lisps primarily for educational
use and compiler research will not have the resources to implement the
entire language.  (Implementors of commercial Lisp products obviously
have an interest in supplying a "complete" and fully-featurized
product, as their customers will go elsewhere if they don't.  On the
other hand, what we choose to implement is based primarily on the
availability of students who are interested in working on it, and has
very little to do with external demand or monetary advantages.) Since
it seems highly unlikely that we will support all of ANSI Common Lisp,
will we be justified in continuing to call our implementation "Utah
Common Lisp"?  Would it be meaningful to describe it as a "subset of
Common Lisp" instead? 

Basically, what I'm saying is that even if the standard doesn't define
any subsets, that is not going to prevent subsets from happening, and
perhaps the standard ought to define some terminology to describe such
implementations (even if it's only to say that they can't call
themselves Common Lisps at all). 

-Sandra
-------

∂02-Feb-89  1115	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Feb 89  11:15:24 PST
Received: from fafnir.think.com by Think.COM; Thu, 2 Feb 89 14:01:45 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 2 Feb 89 14:08:18 EST
Received: by verdi.think.com; Thu, 2 Feb 89 14:07:51 EST
Date: Thu, 2 Feb 89 14:07:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902021907.AA18920@verdi.think.com>
To: sandra%defun@cs.utah.edu
Cc: masinter.pa@xerox.com, KMP@stony-brook.scrc.symbolics.com,
        chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu,
        maxiv@mu.edu, skona%csilvax@hub.ucsb.edu, sandra%defun@cs.utah.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 2 Feb 89 11:46:49 MST <8902021846.AA27814@defun.utah.edu>
Subject: Issue: SUBSETTING-POSITION


   Basically, what I'm saying is that even if the standard doesn't define
   any subsets, that is not going to prevent subsets from happening, and
   perhaps the standard ought to define some terminology to describe such
   implementations (even if it's only to say that they can't call
   themselves Common Lisps at all). 

I recall seeing a conference paper out of CMU with the footnote
"Our language would be a subset of Ada if Ada had subsets."
--Guy

∂02-Feb-89  1513	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Feb 89  15:13:02 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Thu, 2 Feb 89 18:01:59 EST
Received: by kulla.think.com; Thu, 2 Feb 89 18:09:00 EST
Date: Thu, 2 Feb 89 18:09:00 EST
From: barmar@Think.COM
Message-Id: <8902022309.AA09072@kulla.think.com>
To: chapman%aitg.DEC@decwrl.dec.com, gls@Think.COM
Cc: cl-editorial@sail.stanford.edu, maxiv@mu.edu, skona%csilvax@hub.ucsb.edu,
        sandra%defun@cs.utah.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 2 Feb 89 11:18 <8902021620.AA17198@decwrl.dec.com>
Subject: Issue: CONFORMANCE-POSITION

    dpANS C is also in terms of programs.  They have further defined
    both "conforming" and "strictly conforming" programs; the
    difference has something to do with how the program deals with features
    that the standard says are implementation-defined.

I'd really appreciate it if someone who knows more about the ANSI C
specification would update this paragraph.  I never intended my
hearsay "has something to do with" comment to end up as an official
part of the proposal.

In relation to the rest of the proposal, I suspect C's "conforming"
and "strictly conforming" may be similar to your "conforming" and
"portable" definitions.

Guy, you've been involved with ANSI C, can you fix it up?

						barmar

∂02-Feb-89  1521	CL-Editorial-mailer 	Issue: CONFORMANCE-POSITION  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Feb 89  15:21:04 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Thu, 2 Feb 89 18:09:02 EST
Received: by kulla.think.com; Thu, 2 Feb 89 18:16:10 EST
Date: Thu, 2 Feb 89 18:16:10 EST
From: barmar@Think.COM
Message-Id: <8902022316.AA09087@kulla.think.com>
To: sandra%defun@cs.utah.edu
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 2 Feb 89 09:51:51 MST <8902021651.AA27664@defun.utah.edu>
Subject: Issue: CONFORMANCE-POSITION

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Thu, 2 Feb 89 09:51:51 MST

   I also have a concern about how conformance relates to compilation.
   It is reasonable to expect that if a program is conforming, then it
   will be possible to compile it with COMPILE-FILE.  But some people
   have been pushing for placing some additional constraints on programs
   processed by COMPILE-FILE that will explicitly not apply to
   interpreted programs or functions compiled with COMPILE (in
   particular, on what kinds of objects may appear in quoted constants).
   Plus, it also seems like we will be requiring certain things (type
   definitions, package structure, etc) to be defined consistently at
   COMPILE-FILE and LOAD time.  Do you have any suggestions on how we
   should state these requirements? 

Since an implementation is not required to have an interpreter, any
restrictions on compiled code must also apply to the language in
general.  For instance, any restrictions on quoted constants that are
necessary for the compiler must be made into general restrictions
within the language.  It's possible that an implementation may have
behaviors that only apply to interpreted code, but we should try hard
not to put such things into the standard.

∂02-Feb-89  1558	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Feb 89  15:58:32 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Thu, 2 Feb 89 18:46:13 EST
Received: by kulla.think.com; Thu, 2 Feb 89 18:53:23 EST
Date: Thu, 2 Feb 89 18:53:23 EST
From: barmar@Think.COM
Message-Id: <8902022353.AA09163@kulla.think.com>
To: sandra%defun@cs.utah.edu
Cc: masinter.pa@xerox.com, KMP@stony-brook.scrc.symbolics.com,
        chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu,
        maxiv@mu.edu, skona%csilvax@hub.ucsb.edu, sandra%defun@cs.utah.edu
In-Reply-To: Sandra J Loosemore's message of Thu, 2 Feb 89 11:46:49 MST <8902021846.AA27814@defun.utah.edu>
Subject: Issue: SUBSETTING-POSITION

Unless we trademark the name "Common Lisp" (and it's probably too late
now, since there are a number of products using that in their names
already), there's no way we can stop anyone from calling their
implementation "Something Common Lisp", even if it is nothing like
ANSI Common Lisp.  The issue of unofficial subsets is a matter between
vendors and their customers.  So long as the advertising and
documentation make it clear that it isn't an impementation of ANSI
Common Lisp, I don't think there's much of a problem.

Personally, I'd suggest U of Utah should call their implementation
"Utah Lisp", and mention early on in the documentation that it is a
subset of ANSI Common Lisp.  

Another issue related to this is that there is a pre-ANSI definition
of Common Lisp.  Pre-ANSI CLtL-based Lisps (such as Utah Common Lisp)
have just as much right to call themselves Common Lisp as
ANSI-conformant Common Lisps.

The only language around that has gone so far as to make conformance a
requirement on using the name is Ada.  The DOD had the forethought to
trademark the name and then license it only to validated
implementations.

∂03-Feb-89  0811	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Feb 89  08:11:18 PST
Received: from fafnir.think.com by Think.COM; Fri, 3 Feb 89 10:43:49 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 3 Feb 89 10:43:37 EST
Received: by verdi.think.com; Fri, 3 Feb 89 10:43:09 EST
Date: Fri, 3 Feb 89 10:43:09 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8902031543.AA21748@verdi.think.com>
To: barmar@Think.COM
Cc: sandra%defun@cs.utah.edu, masinter.pa@xerox.com,
        KMP@stony-brook.scrc.symbolics.com, chapman%aitg.DEC@decwrl.dec.com,
        cl-editorial@sail.stanford.edu, maxiv@mu.edu,
        skona%csilvax@hub.ucsb.edu, sandra%defun@cs.utah.edu
In-Reply-To: barmar@Think.COM's message of Thu, 2 Feb 89 18:53:23 EST <8902022353.AA09163@kulla.think.com>
Subject: Issue: SUBSETTING-POSITION

   Date: Thu, 2 Feb 89 18:53:23 EST
   From: barmar@Think.COM
   ...
   The only language around that has gone so far as to make conformance a
   requirement on using the name is Ada.  The DOD had the forethought to
   trademark the name and then license it only to validated
   implementations.

That is correct.  Note, however, that sometime last year DoD decided
to relinquish the trademark.

∂03-Feb-89  1112	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Feb 89  11:12:13 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 3 Feb 89 14:07:03 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 3 Feb 89 14:07:42 EST
Date: Fri, 3 Feb 89 14:09 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: ERROR-TERMINOLOGY
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902021526.AA12594@decwrl.dec.com>
Message-Id: <19890203190918.1.BARMAR@OCCAM.THINK.COM>

    Date: 2 Feb 89 10:25
    From: chapman%aitg.DEC@decwrl.dec.com

Before sending this out to X3J13, it would be really helpful if the
formatting could be fixed up.  It's extremely difficult to read text
with right margins that snake halfway across the page, as in:

			    (3)When the situation occurs, the consequences 
			    are defined.
			    Also,
			    no portable program can depend on 
			    the consequences of this
			    situation, and all portable programs are 
			    required to treat the 
			    consequences of the situation as undefined.
			    Implementations can do anything in this situation. 

Now to a technical comment:

    CONSEQUENCES ARE UNSPECIFIED The consequences are unpredictable but can
			    potentially lead to bad effects since subsequent
			    control flow may depend on the unspecified data
			    flow. The debugger is not entered automatically
			    in this situation, and normally is not entered at
			    all.
			    Implementations are allowed to specify the 
			    consequences of this situation.
			    Implementations are allowed to detect this situation and
			    signal an error, but no implementation is required 
			    to detect the situation.
			    No conforming program may depend on the effects of this
			    situation, and all conforming programs are required to 
			    treat the effects of this situation as unpredictable.

I used to think I understood what the UNSPECIFIED situation meant.  But
this description is extremely confusing.  I don't understand the part of
the first sentence after "but" at all.  The second sentence says that
the debugger ISN'T entered, but the fourth sentence says that
implementations are allowed to signal an error; this seems like a
contradiction, since the default action when an error is signaled is to
enter the debugger.  Does this mean that if the implementation signals
an error in this situation it must have a default handler for that
condition that doesn't enter the debugger?  If so, why would this be
useful?

And it still doesn't give a good idea of the difference between this
situation and UNDEFINED (and I still hate giving the synonyms
"undefined" and "unspecified" different meanings in the standard, but
I've given up on that issue).

                                                barmar

∂04-Feb-89  2258	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I think the description of the error terminology could be improved.  There
seems to have been some explanatory commentary added that seems to confuse
the issues. I think explanatory information is important and will try to
retain it. 

After having compared my rewording to the original, I have to say that I
am not prepared to accept the original. There were several places where the
sense of the definitions were altered from what I thought had been agreed
to. In some cases we will need to work on further definitional material. I
think we should not confuse being precise with being specific. Terms like
``unspecified'' enable us to be precise while being unspecific. Similarly,
we should not shy away from using informal terms to get across the meaning
of a term that will be used precisely. There is nothing inherently wrong
with leaving some things to later interpretation, especially when we
cannot and do not wish to predict implementation technology. This is the
hardest lesson to learn in writing standards documents.

Below is my re-wording of the definitions. In [square brackets]
are my reasons.

CONFORMING PROGRAM (*)	

A program whose code adheres to the requirements of conforming code:  (1)
Conforming code shall not use any constructions that are prohibited by the
standard.  (2) Conforming code shall not depend on extensions included in
an implementation.

SAFE CODE (*)

Code processed with the SAFETY optimization at its highest setting. SAFETY
is a lexical property of code.

UNSAFE CODE  (*)

Code processed with lower safety levels.

Note: Unsafe code is not necesarily code that does not do error
checking. In many cases it may do less error checking, but no guarantee
that error checking will be less in unsafe code is expressed or implied.
Implementations are permitted to treat all code as safe code all the time,
by simply ignoring the SAFETY quality or the entire OPTIMIZE declaration.

IS SIGNALLED 

An error is signalled in both safe and unsafe code.  A conforming program
may rely on the fact that the error will be signalled in both safe and
unsafe code.  Every implementation is required to detect the error in both
safe and unsafe code.  For example, ``an error is signalled if UNEXPORT is
given a symbol not accessible in the current package.''

SHOULD BE SIGNALLED

An error will be signalled in safe code, and an error might or might not
be signalled in unsafe code.  A conforming program may not rely on an
error being signalled.  Every implementation is required to detect the
error at least in safe code.  When the error is not signalled, the
``consequences are undefined'' (see below).  For example, ``an error
should be signalled if ENDP is given a non-list argument.''

Note: The situation that has been identified as an error is illegal in all
implementations, but some implementations might not detect the situation.
A conforming program known to be safe may rely on the error being
signalled.

[The explanatory information seemed to get in the way of the real
definition.]

CONSEQUENCES ARE UNDEFINED 

The consequences are unpredictable. The consequences may range from
harmless to fatal.  A conforming program may not depend on the results or
effects.  A conforming program must treat the results and effects as
unpredictable.

In places where the words ``must'', ``must not'' or ``may not''
are used, ``the consequences are undefined'' if the stated requirement
is not met and no specific consequence is explicitly stated.

For example: CLtL currently says:  (page 69) ``Once a name has been
declared by DEFCONSTANT to be constant, any further assignment or binding
of that special variable is an error.''  This statement would be
transformed to: ``Once a name has been declared by DEFCONSTANT to be
constant, any further assignment or binding of that special variable has
undefined consequences.''

Note: A result or effect is unpredictable if it might vary among
implementations or separate invocations within a single implementation.
The definition of a harmless effect is difficult to specify precisely.  It
is intended that printing error messages on the stream *error-output* or
modifying implementation data during normal operations are harmless.
Allocating storage, invoking a garbage collector, and re-hashing are
prototypical examples of things that have harmless effects.  In general,
an effect is harmless if it does not cause the implementation to halt or
otherwise enter an inconsistant state. 

An effect is fatal if it causes the implementation to halt or destroys
user, implementation, or system data.  For example, leaving the file
system in an inconsistent state is considered fatal. Other unpredictable
effects include entering the debugger or destroying a user data structure.

If a program depends on a harmless effect, then the result can be fatal.
This is why conforming programs may not depend on such effects.

Implementations are permitted do anything in this situation.

[I think ``harmless'' is important to try to delineate, and I would not
accept the definition of ``undefined'' without that possibility. The
original version seemed to have had it dropped. It isn't ``go boom''; it's
``might go boom.'']

RETURN VALUES ARE UNDEFINED 

Only the number and nature of the return values of a construct are not
well defined but any side-effect and transfer-of-control behavior is well
defined.  For example, if the return values of some function F are
undefined, then an expression such as (length (list (F))) is still
well-defined because it does not rely on any particular aspect of the
value or values returned by F.

CONSEQUENCES ARE UNSPECIFIED 

The consequences are unpredictable but harmless.

Implementations are permitted to specify the consequences of this situation.
A conforming program may not depend on the results or effects of this
situation, and a conforming program is required to treat the results and
effects of this situation as unpredictable but harmless.

For example, ``the effects of the garbage collector when invoked is
unspecified.''

[This is not an error term per se. It is used to allow us to be precise
when we do not want to be specific. It is wrong to imply that a debugger
might enter the scene or that an implementation should try to detect this
situation.]

IMPLEMENTATIONS MAY BE EXTENDED 

An implementation is free to treat the situation in ANY ONE of the
following ways:  (1) When the situation occurs, an error is signalled at
least in safe situations, OR (2) When the situation occurs, the
consequences are undefined, OR (3) When the situation occurs, the
consequences are defined.  Also, a conforming program may not depend on
the results or effects of this situation, and a conforming program must
treat the results and effects of the situation as undefined.

Implementations are permitted do anything in this situation.

For example, ``implementations may be extended to define other type
specifiers to have a corresponding class.''

Note: Users should consult the implementation reference manual to
determine the result or effect of this situation, but should never depend
on the results or effects of this situation in code to be run on other
implementations.

[The description of how to handle this situation seemed to boil down
to the above note.]

FREE TO EXTEND THE SYNTAX 

Implementations are permitted to define unambiguous extensions to the syntax
of the construct being described.  A conforming program may not depend on this
extension. A conforming program is required to treat the syntax as
meaningless.  The standard may disallow certain extensions while allowing
others.  For example, ``no implementation is free to extend the syntax of
DEFCLASS.''

WARNING IS ISSUED

A warning is issued, as described in WARN, in both safe and unsafe code
and when the situation is detected by the compiler.  A conforming program
may rely on the fact that a warning will be issued in both safe and unsafe
code and when the situation is detected by the compiler.  Every
implementation is required to detect this situation in both safe and
unsafe code and when the situation is detected by the compiler.  The
presence of a warning will in no way alter the value returned by the form
which caused the situation to occur. That is, the effects of a warning are
harmless.  For example, ``a warning is issued by the compiler if a
declaration specifier is not one of those defined in Chapter 9 of CLtL and
has not been declared in a DECLARATION declaration.''

WARNING SHOULD BE ISSUED 

A warning may be issued.  A conforming program may not rely on the fact
that a warning will be issued.  If the situation is detected by the
compiler, a warning may or may not be issued, depending on the
implementation.  The presence of a warning will in no way alter the value
returned by the form which caused the situation to occur.  That is, the
effects of a warning are harmless.  For example, (paraphrasing from CLtL,
p. 160) ``a warning should be issued by a compiler if a variable declared
to be ignored is ever referred to or is also declared special, or if a
variable is lexical, never referred to, and not declared to be ignored.''
(see Chapter 9, CLtL)


∂04-Feb-89  2312	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


Barmar writes:

``and I still hate giving the synonyms "undefined" and "unspecified"
different meanings in the standard, but I've given up on that issue.''

This point is important. In looking over all intended uses of one over the
other, almost all the time we will be saying that something is undefined
when we want people to not use it because the effects could get you, while
we will be saying that values are unspecified. Other times we will be
saying that whether or not something happens is unspecified.

I doubt we will be able to settle this without fine tuning as we see
the effects in the document.

			-rpg-

∂05-Feb-89  1137	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


The proposal states:

``The draft standard we submit to ANSI contains *no* subsets. In the section
on "subsetting" it should be mentioned that Lisp is a "small" language
with a "big" library and that the conventional mechanism for allowing
small memory images is auto-load.''

It is probably worthwhile to break the document into core and library
parts. This is posssibly pretty easy since it generally corresponds
to a breakdown in a typical CL compiler. (Though some compilers will
treat a complex operation as primitive for optimization.)

I think it is a mistake to distinguish autoload when the real concern
today is for small deliverable applications. I might favor a discourse on
such concerns, though it might expand the bulk of the document. If we had
more manpower (feminists note: sic) we could write a rationale document to
accompany the standard.

One point worth making might be that a conforming program that is
delivered may not also be a conforming implementation. This point was
understood with difficulty at the last IEEE Scheme meeting (last friday).
The issue was that IEEE Scheme was proposing a series of subsets mostly
having to do with numeric capabilities. The idea was that if a computer
did not have floating point capabilities, that it should be possible to
write a conforming program that did not use floating point and be able to
deliver that program on that computer. Some felt that in order to deliver
a conforming program, a conforming implementation had to be present, which
meant that subsets must be mandated. When I argued against this, the
response was to argue that test suites would be developed for Scheme and
show such deficient implementations (via the applications) are
non-conforming. It took a while to convince them that one could produce a
linkable version of the application which would include almost no part of
the Scheme environment.

If this point is difficult enough for some smart Scheme hackers to
misunderstand, maybe it's worth elaborating it somewhere.

			-rpg-

∂05-Feb-89  1151	CL-Editorial-mailer 	Issue: EXTENSIONS-POSITION   
To:   CL-Editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I believe that it might be best to precisely define ``conformance''
and maybe portability, and to leave it up to free enterprise to
settle handling extensions.

My understanding is that a conforming program is automatically
portable in that the results are well-defined in all implementations
and the same up to hardware-differences that are recognized. For example,
floating-point computations might have different convergence properties
in different implementations, though we want to declare such programs
conforming. (Possibly we could state that the results of floating-point
operations are correct with an error term that is unspecified, and therefore
programs that depend on these terms are non-conforming.)

A portable program is one that doesn't comform, but which has provisions
to make it conforming for all target implementations. One might be able to
argue that a portable program paired with a conforming implementation
results unambiguously in a conforming program, but this is too esoteric to
consider seriously.

In short, I favor remaining mute on this topic in the standard.

			-rpg-

∂05-Feb-89  1204	CL-Editorial-mailer 	Issue: SUBSETTING-POSITION   
To:   CL-Editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I think KMP's statement is accurate but does not belong in the document
anywhere. Possibly a rationale document could contain it. I think it
isn't too important why we chose to do one thing instead of another at the
level of making it part of an official document.

Maybe someone should note this historical item in the official minutes of
X3J13.
			-rpg-

∂05-Feb-89  1956	CL-Editorial-mailer 	Issue: EXTENSIONS-POSITION   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 5 Feb 89  19:55:57 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Sun, 5 Feb 89 22:44:20 EST
Received: by kulla.think.com; Sun, 5 Feb 89 22:51:51 EST
Date: Sun, 5 Feb 89 22:51:51 EST
From: barmar@Think.COM
Message-Id: <8902060351.AA16112@kulla.think.com>
To: RPG@sail.stanford.edu
Cc: CL-Editorial@sail.stanford.edu
In-Reply-To: Dick Gabriel's message of 05 Feb 89  1151 PST <$kZKM@SAIL.Stanford.EDU>
Subject: Issue: EXTENSIONS-POSITION   

    Date: 05 Feb 89  1151 PST
    From: Dick Gabriel <RPG@sail.stanford.edu>

    A portable program is one that doesn't comform, but which has provisions
    to make it conforming for all target implementations.

Huh?  I thought our current definitions said that portable is a subset
of conforming.  A conforming program is just one that only uses
well-defined operations, but a portable program returns the same
result in all implementations.  My understanding is that

	(defun foo ()
	  *most-positive-fixnum*)

is a conforming, non-portable program.

						barmar

∂05-Feb-89  2139	CL-Editorial-mailer 	What is Portable?  
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I have a program that runs in all Common Lisp systems. It is a set
of floating point routines. These routines first run a series of
implementation-dependent code (usually in LAP or C) that determine
the floating point hardware characteristics. Then some constants are
selected so that the convergence is the same in all implementations.
Is this program portable? If it is, then portable is not a subset of
conforming and conforming is not a subset of portable. 

PCL is an example of a non-conforming program.

I think this is why we need to define conforming and leave portable
alone.

			-rpg-

∂06-Feb-89  0136	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Feb 89  01:36:11 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA29982; Mon, 6 Feb 89 01:34:31 PST
Message-Id: <8902060934.AA29982@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Feb 89 04:28
To: cl-editorial@sail.stanford.edu, sandra%defun@cs.utah.edu
Subject: Issue: ERROR-TERMINOLOGY

Issue:        ERROR-TERMINOLOGY
References:   Chapter 5, Section 5.1, Working draft of the standard
	      CLOS Chapter 1
	      CLtL Chapter 1, Section 1.2.4
              Condition System, Version 18
Category:     Clarification
Edit history: 27-DEC-88, Version 1 by Chapman
              31-JAN-89, Version 2 by Chapman
              6-FEB-89, Version 3 by Chapman, RPG and Barmar comments included
 
Problem Description:
In CLtL, CLOS and the Condition System, similar but slightly
different language is used to describe
non-normal actions by CL operators. The X3J13 committee needs to
agree on a standard set of terms and their meanings.
 
Proposal (ERROR-TERMINOLOGY:STANDARD TERMS)

TERM			MEANING (including CLtL -> standard conversion)
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
CONFORMING CODE (*)	Code that adheres to the following requirements:
			(1) Conforming code shall not use any constructions 
			that are prohibited by the standard.
			(2) Conforming code shall not depend on extensions 
			included in an implementation.

SAFE CODE (*)		Code processed with the SAFETY optimization at its
			highest setting. SAFETY is a lexical property of code.

UNSAFE CODE  (*) 	Code processed with lower safety levels.
		        Note: Unsafe code is not necesarily code that does not 
			do error checking. In many cases it may do less error 
			checking, but no guarantee that error checking will be 
			less in unsafe code is expressed or implied. 
			Implementations are permitted to treat all code as safe 
			code all the time, by simply ignoring the SAFETY 
			quality or the entire OPTIMIZE declaration.

IS SIGNALLED   		An error is signalled in both safe and unsafe code. 
			Conforming code may rely on the fact that the error 
			will be signalled in both safe and unsafe code.
     			Every implementation is required to detect the error
			in both safe and unsafe code. For example, "an error 
			is signalled if UNEXPORT is given a symbol not accessible in 
			the current package."

SHOULD BE SIGNALLED 	An error will be signalled in safe code, and an error
		        might or might not be signalled in unsafe code.
			Every implementation is required to detect the error at 
			least in safe code. When the error is not signalled, 
			the "consequences are undefined" (see below).
			Note: The situation which has been identified as an error is
			illegal in all implementations, but some implementations 
			do not actually detect the situation. Conforming code 
			known to be safe may rely on the error's being signalled. 
			For example, "an error should be signalled if ENDP is 
			given a non-list argument."

CONSEQUENCES ARE UNDEFINED The consequences are unpredictable. The consequences
			may range from harmless to fatal. No conforming code can 
			depend on the results or effects. Conforming code must
			treat the results and effects as unpredictable. 
			In places where the words "must", "must not" or "may 
			not" are used, then "the consequences are undefined" 
			if the stated requirement is not met, and no specific 
			consequence is explicitly stated.
			For example: CLtL currently says: (page 69) "Once a 
			name has been declared by DEFCONSTANT to be constant, 
			any further assignment or binding of that special 
			variable is an error." This statement would be 
			transformed to: "Once a name has been declared by 
			DEFCONSTANT to be constant, any further assignment or 
			binding of that special variable has undefined consequences." 
			Note: A result or effect is unpredictable if it might
			vary among implementations or separate invocations
			within a single implementation. The definition of
			a harmless effect is difficult to specify precisely.
			It is intended that printing error messages on the
			stream *ERROR-OUTPUT* or modifying implementation
			data during normal operations are harmless. Allocating
			storage, invoking a garbage collector, and re-hashing
			are prototypicl examples of things that have harmless
			effects. In general, an effect is harmless is if does
			not cause the implementation to halt or otherwise enter
			an inconsistent state.
			An effect is fatal if it causes the implementation to
			halt or destroys user, implementation, or system data.
			For example, leaving the file system in an inconsistent
			state is considered fatal. Other unpredictable effects
			include entering the debugger or destroying a user data
			structure.
			If code depends on a harmless effect, then the result
			can be fatal. This is why conforming code may not
			depend on such effects.
			Implementations are permitted to do anything in this 
			situation.

RETURN VALUES ARE UNDEFINED Only the number and nature of the return values 
			of a construct are not well defined but any side-effect 
			and transfer-of-control behavior is well defined. For 
			example, if the return values of some function F are 
			undefined, then an expression such as 
			(length (list (F))) is still well-defined because it 
			does not rely on any particular aspect of the value or 
			values returned by F.

CONSEQUENCES ARE UNSPECIFIED The consequences are unpredictable but harmless.
			Implementations are permitted to specify the 
			consequences of this situation. No conforming code may 
			depend on the results or effects of this situation, 
			and all conforming code is required to treat the results 
			and effects of this situation as unpredictable but 
			harmless. For example, ``the consequences of the garbage 
			collector when invoked are unspecified.''

IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat
			the situation in ANY ONE of the following ways:
			(1)When the situation occurs, an error is signalled at 
			least in safe code,
			OR
			(2)When the situation occurs, the "consequences are 
			undefined", 
			OR
			(3)When the situation occurs, the consequences are 
			defined.
			Also, no conforming code can depend on the results or
			effects of this situation, and all conforming code must
			treat the results and effects of the situation as 
			undefined. Implementations are permitted to do anything 
			in this situation. For example, "implementations may be 
			extended to define other type specifiers to have a 
			corresponding class."
			Note: Users should consult the implementation reference 
			manual to determine the results or effects of this 
			situation, but should never depend on the results or 
			effects of this situation in code to be run on other 
			implementations.

FREE TO EXTEND THE SYNTAX Implementations are permitted to define unambiguous 
			extensions to the syntax of the construct being 
			described. No conforming code can depend on this 
			extension. All conforming code is required to treat 
			the syntax as meaningless. The standard may disallow 
			certain extensions while allowing others. For example, 
			"no implementation is free to extend the syntax of 
			DEFCLASS."

WARNING IS ISSUED	A warning is issued, as described in WARN, in both safe 
			and unsafe code and when the situation is detected by 
			the compiler. Conforming code may rely on the fact 
			that a warning will be issued in both safe and unsafe 
			code and when the situation is detected by the compiler.
			Every implementation is required to detect this 
			situation in both safe and unsafe code and when the 
			situation is detected by the compiler. The presence of 
			a warning will in no way alter the value returned by 
			the form which caused the situation to occur. For 
			example, "a warning is issued by the compiler if a 
			declaration specifier is not one of those defined in 
			Chapter 9 of CLtL and has not been declared in a 
			DECLARATION declaration."

WARNING SHOULD BE ISSUED A warning may be issued. Conforming code may not rely 
			on the fact that a warning will be issued. If the 
			situation is detected by the compiler, a warning may or 
			may not be issued, depending on the implementation.
			The presence of a warning will in no way alter the 
			value returned by the form which caused the situation 
			to occur. For example, (paraphrasing from CLtL, p. 160)
			"a warning should be issued by a compiler if a variable 
			declared to be ignored is ever referred to or is also 
			declared special, or if a variable is lexical, never 
			referred to, and not declared to be ignored." 


(*) means this term is used to define other terms in this proposal,
not explicitly used in the standard.
 
Rationale:

For the standard to be an exact specification, terminology must be
defined and agreed upon. 
 
Current Practice:

CLtL uses "is signalled", "should be signalled", "is an error", 
"a warning is issued", and "a warning should be issued". CLOS 
and the Condition System use
"is undefined" "is unspecified", "may be extended", 
"free to extend the syntax", and "return values are undefined". 
The definition of "is an error" in CLtL has come to mean "is allowed"
in places where implementations typically extend the language. 

Adoption Cost:

The cost of adopting this terminology will be mostly associated with the 
change from "is an error" to some other more specific terminology
from the above list (typically "is an error" -> "is undefined").

Benefits:

Specific terminology will disambiguate function descriptions which
will save implementor's time and decrease user frustration. Users should
be able to write more portable code if the specification is exact. 
 
Conversion Cost:

See Adoption Cost.
 
Aesthetics:

None.
 
Discussion:

Barmar comments:
"... I still hate giving the synonyms "undefined" and "unspecified"
different meanings in the standard, but I've given up on that issue."
RPG responds: 
"This point is important. In looking over all intended uses of one over the
other, almost all the time we will be saying that something is undefined
when we want people to not use it because the effects could get you, while
we will be saying that values are unspecified. Other times we will be
saying that whether or not something happens is unspecified.
 
I doubt we will be able to settle this without fine tuning as we see
the effects in the document."
 

∂06-Feb-89  0220	CL-Editorial-mailer 	cut off dates 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Feb 89  02:19:56 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA01746; Mon, 6 Feb 89 02:18:19 PST
Message-Id: <8902061018.AA01746@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Feb 89 04:57
To: cl-editorial@sail.stanford.edu
Subject: cut off dates

I haven't heard from any of you on the recent versions of the issues
CUT-OFF-DATES and TOC. Do you need any more info to analyze these proposals?
I'm more than willing to change these proposals if you have better ideas.

It will be almost impossible for us to come to closure on this document
unless we agree among ourselves to freeze certain parts of it at scheduled
times. The times really don't matter (if we don't care about in what year
or century we finish), but I believe that establishing them does. What
do you think? 

There is no time factored in for rearranging the standard significantly to 
reduce its size. We should form a mini-subcommittee to study that now to
come up with coherent recommendations for the March meeting. Any volunteers
to write the first proposal? 

Just a reminder that comments for the 2/21 letter ballot will be taken until
2/19. The contents of the 2/21 letter ballot will be:

Issues: CUT-OFF-DATES, ERROR-TERMINOLOGY, FONTS, TOC
Parts of standard: 1.8, 2.3, 2.4, 2.5, 6.1

You have received and will receive electronic versions of the issues; 
you can access
the parts of the standard on hudson.dec.com, ftp_user merrychristmas,
files s1800.*,s2300.*,s2400.*,s2500.*,s6100.*
I will be creating a DVI file with just those parts next week called
letter-ballot-feb-21.dvi.


It would really be nice if you all could somehow endorse (or change
them so that you will endorse) the things in the letter ballot so that
the rest of X3J13 has some idea of how we feel about these things.
Any comments I receive from you will be included in the cover letter
as guidance to the rest of the committee.

If I didn't already mention it, I have requested a room for an editorial
committee meeting on Monday afternoon (3/27). Any problems with that?

Thanks for your help. 
kc

∂06-Feb-89  0622	CL-Editorial-mailer 	What is Portable?  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Feb 89  06:05:34 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 533970; Mon 6-Feb-89 09:03:34 EST
Date: Mon, 6 Feb 89 09:03 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: What is Portable?  
To: RPG@SAIL.Stanford.EDU
cc: cl-editorial@SAIL.Stanford.EDU
In-Reply-To: <8kc2N@SAIL.Stanford.EDU>
Message-ID: <890206090308.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

I've been talking about this a bit with Kathy. Here's my position...

As you know, I wrote a paper on portability for the last Lisp Conference
that was rejected as being "too unscientific". In that paper, I
established the concept of "semi-portable" programs. I described that
to be programs like Macsyma which have a non-portable component to help
them get over the rough spots, but which are essentially otherwise portable.
Normally such programs are partitioned into a portable component and a
non-portable component for easier maintenance; hence the name.

I believe that "portable" must be a subset of "conforming" because I
think the important part of a portable program is that produces usefully
equivalent results in all conceivable implementations, and since any
non-conforming aspect of a program could be exposed by some conceivable
conforming processor.

I believe that "conforming" can be rigorously defined, although I do not
believe it can be rigorously tested for (due to halting problem effects
and the use of EVAL). I believe any claims we made about the ability to
distinguish conforming and non-conforming programs should be limited to
programs which do not coerce data to program (via EVAL, COMPILE, etc.).
Also, it must be clear that conformance is defined on structure and not
on read syntax, since the readtable may be redefined in a way that makes
many apparently non-conforming programs actually conform.

I believe that it is permissible for "conforming" to span that set of
programs which use system-dependent extensions, since there is nothing
non-conforming about the use of extensions. If there were, you would not
be able to write a single named function or create a single named package
and use it later without failing to conform.

I believe that we should not attempt to rigorously define "portable", but
rather that we should attempt to informally characterize it. It's one of
those terms like "correct" or "efficient" where you can't write an easy
proof for how to tell when it's true, but you can attach a meaning such
that it's clear how you meant the term to be applied. I believe that the
concept of "portable" depends partly on the documentation. For example,
Macsyma's $RANDOM function (which returns a random number) will return
different random series' on different machines, yet it will live up to
its contract on all machines because it is defined using a primitive 
documented to satisfy its needs. On the other hand, if you write a program
called PRINT-THE-FOOBAR-SERIES which calls RANDOM because it knows a 
particular implementation of RANDOM really prints a series of numbers
called the Foobar Series, then that program is not portable because not
all RANDOM functions may be implemented to print that same series. So it
is not possible to tell just from looking at the code if the program is
portable. "Portability" is a claim the programmer makes about a conforming
program.

I believe PCL and your C/LAP routines are not portable. In my
terminology, they are semi-portable. That isn't at all to say that
either of these programs is not useful. Some (perhaps most or all) of
the important programs that get ported around are only semi-portable.

∂06-Feb-89  0637	CL-Editorial-mailer 	Issue: EXTENSIONS-POSITION   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Feb 89  06:37:22 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 533982; Mon 6-Feb-89 09:34:55 EST
Date: Mon, 6 Feb 89 09:34 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTENSIONS-POSITION   
To: barmar@Think.COM
cc: RPG@sail.stanford.edu, CL-Editorial@sail.stanford.edu
In-Reply-To: <8902060351.AA16112@kulla.think.com>
Message-ID: <890206093425.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Sun, 5 Feb 89 22:51:51 EST
    From: barmar@Think.COM

    ... I thought our current definitions said that portable is a subset
    of conforming.  A conforming program is just one that only uses
    well-defined operations, but a portable program returns the same
    result in all implementations.  My understanding is that

	    (defun foo ()
	      *most-positive-fixnum*)

    is a conforming, non-portable program.

Hmm. Although I'm sure it's unintentional, this is a good example to
look at. :-) *most-positive-fixnum* is obviously a user variable, since
the system variable has no stars. Presumably you've DEFVAR'd it somewhere
so you can use it free as you have. That means its value could change,
either dynamically [if you didn't use DEFCONSTANT to define it] or in
some conditional initial value setup.  eg,

 (defvar *most-positive-fixnum*
	 #-ACME (random most-positive-fixnum)
	 #+ACME 'YOW)

or

 (defun bar () (let ((*most-positive-fixnum* (random most-positive-fixnum))) (foo)))

or even

 (defun bar (*most-positive-fixnum*) (foo))

As an aside, the program you cite is a DEFUN, not a function call. DEFUN
has a well-defined return value regardless of its body. As such,
executing that DEFUN in any implementation should yield the same result.
The thing returned by your example is the symbol FOO. I think it should
be possible to talk usefully about portable program fragments, but we
must be very careful about our terminology.

 - It is clear that (DEFUN FOO1 () MOST-POSITIVE-FIXNUM) returns
   the same value in all implementations: FOO1.

 - It is clear that (DEFUN FOO2 () *MY-VAR*) returns the same value
   in all implementations: FOO2.

 - It is clear that both (FOO1) and (FOO2) might return different
   values in different implementations [unless more preconditions are
   specified].

 - It is clear that we want to say that definition FOO1 is portable
   and definition FOO2 is not, but to do so we must use much more careful
   wording than just "the results are the same".

    - The results should be the same for the same inputs, but in this
      "the results" must be defined to include side-effects (I/O, file
      system, heap, ...) [though perhaps explicitly exclude GC, stack
      growth, ...]. 

    - For different inputs, the results might differ. Consider:
      (DEFUN MYABS (X) (IF (< X 0) (- X) X))
      Note that (MYABS 3) returns something different than (MYABS 5),
      but the same as (MYABS -3) yet MYABS is portable. But
      (DEFUN MPF (X) MOST-POSITIVE-FIXNUM)
      (MPF -3) == (MPF 3) yet MPF not portable.

 - No code in this message is non-conforming.

Most of this is obvious and non-controversial, I think. I'm just trying
to establish some ``tests cases'' for testing any terminology we come up
with which claims to describe "portable" and "conforming".

∂06-Feb-89  1614	RPG 	
 ∂05-Feb-89  2321	chapman%aitg.DEC@decwrl.dec.com 	  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 5 Feb 89  23:21:08 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for rpg@sail.stanford.edu; id AA25612; Sun, 5 Feb 89 23:19:29 PST
Message-Id: <8902060719.AA25612@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Feb 89 02:16
To: rpg@sail.stanford.edu
Subject: 

>Subj:	Issue: EXTENSIONS-POSITION   
>
> 
>I believe that it might be best to precisely define ``conformance''
>and maybe portability, and to leave it up to free enterprise to
>settle handling extensions.
Then I don't believe we can use the word `extended' in the standard.
That's where the issue came from to begin with. We tried a simple
explanation in the first draft of the error terminology. It was too
simple. The issue EXTENSIONS-POSITION may be withdrawn in favor of
the ones it spawned, i.e. EXTRA-SYNTAX, EXTRA-OPTIONAL-KEYWORD-ARGUMENTS,...

What do you think of that?
kc

Who is closer to submitting the standard that ISO really wants to 
WG16, us or Scheme?
kc

∂06-Feb-89  1640	RPG 	CLOS review    
 ∂06-Feb-89  0158	chapman%aitg.DEC@decwrl.dec.com 	CLOS review 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Feb 89  01:58:27 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for rpg@sail.stanford.edu; id AA01192; Mon, 6 Feb 89 01:56:53 PST
Message-Id: <8902060956.AA01192@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Feb 89 04:39
To: rpg@sail.stanford.edu
Subject: CLOS review

Dick,

Have you received the CLOS concept info I sent for your review? It's
been a week now since you should've gotten it. I'll send another
copy if you haven't received it. 

I am planning to include the stuff you are reviewing in the 2/21 letter
ballot since it is so close to something that the committee has already
approved. Do you have any problem with that? Will you have had time
to do a proper review by, say, 2/9? I can't send it out as is because
there are still some unanswered questions (annotated in the text you have).

I think Linda and I have pretty much completed the CLOS chapter 2 rewrite.
I'll send a hardcopy to her this week.

According to my little schedule, you and Masinter are the first of the
important six people to review the `complete' standard. I am preparing
that copy for you now. It will not include most of the issues passed in
Jan., Loop, or a clean version of the condition system (i.e. the condition
system is included but I'm still waiting for comments from KMP on the
concept section (a section in Chapter 5) and about half of the functions.
Obviously it won't include any changes from the character committee or 
issues that haven't been passed. The issues that have been included are
clearly annotated (annotations will be removed for final copy, of course).
So are you ready, or do you think it's not worth your time to review now?

I'd really appreciate it if you reviewed now, even though there is much
to be added. The sooner I can work in the important comments, the better
the final product will be. You will have 3 weeks to review. I'll have
one week to incorporate your comments. Then I will send that document,
plus any things I've been able to incorporate while you've had the document
to the next two important reviewers (Moon and Pitman). They'll have
the same amount of review time. By the time I incorporate their comments
I will also be incorporating decisions made at the March meeting (characters
and other issues, presumably). Then the document will go to GLS, van Roggen,
and deMicheal. That will be early May if everything goes as planned (HA!).
You suggested JonL as a reviewer. I'd prefer he reviews early, if he can.
Do I approach him directly?

Thanks for your time and help.

Did the ISO people actually agree to meet on Saturday?
kc

∂06-Feb-89  1644	CL-Editorial-mailer 	cut off dates 
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


Nothing in this proposal looked bad to me.

``If I didn't already mention it, I have requested a room for an editorial
committee meeting on Monday afternoon (3/27). Any problems with that?''

As someone on the West Coast whose family is active on Easter, I will
probably not be able to make any but an evening meeting on Monday.

			-rpg-

∂06-Feb-89  1707	CL-Editorial-mailer 	What is Portable?  
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


KMP writes:

``I believe that "portable" must be a subset of "conforming" because I
think the important part of a portable program is that produces usefully
equivalent results in all conceivable implementations, and since any
non-conforming aspect of a program could be exposed by some conceivable
conforming processor.''

Because I worry about making too many claims about ``conceivable''
technology, I take this point to argue against saying too much about
portability, though some discussion might be useful.

KMP writes:

``I believe that "conforming" can be rigorously defined, although I do not
believe it can be rigorously tested for (due to halting problem effects
and the use of EVAL). I believe any claims we made about the ability to
distinguish conforming and non-conforming programs should be limited to
programs which do not coerce data to program (via EVAL, COMPILE, etc.).''

If it can be rigorously (but not effectively) defined, why should we worry
about whether data is coerced to program? That is, why can't we just
say something like (eval <form>) conforms if and only if <form> conforms
in the appropriate context? It isn't an effective definition, but who cares?
We can extend this basic approach as needed. Also, I think we're best off not
talking too much about halting problems and the like in the document.

KMP writes:

``Also, it must be clear that conformance is defined on structure and not
on read syntax, since the readtable may be redefined in a way that makes
many apparently non-conforming programs actually conform.''

This is a good point, but we should be careful to try to avoid inventing new
semantic models for the standard. Ordinary denotational semantics is pretty
involved with the surface syntax of the language specified. I suspect we
cannot define everything with a high degree of specificity and will need
to finesse some things.

KMP writes:

``I believe that it is permissible for "conforming" to span that set of
programs which use system-dependent extensions, since there is nothing....''

I take this to mean that one could regard the program that may or may not
conform to be the user's program with the implementation extensions
appended. I think these depend on the extensions. Certainly a user program
that defines extensions and then uses them is clearly differentiated from
the case KMP mentions: No other standards document worries about
the definition of extensions merely to capture the normal case of a
programmer defining a routine and then using it.

I think there is no problem with stating that a conforming program may
include references to defined functions and macros.  I would not want to
include syntactic extensions, such as multi-armed IF forms for example.
That is extensions to syntax should not be allowed in conforming programs,
nor any extensions to the n symbols in the Lisp package (in today's terms,
to the 775 CLtL symbols.). 

KMP writes:

``I believe that we should not attempt to rigorously define "portable", but
rather that we should attempt to informally characterize it.''

My budget for such a characterization would be 1 or 2 sentences, a short
paragraph at most.

				-rpg-

∂06-Feb-89  1904	CL-Editorial-mailer 	What is Portable?  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Feb 89  19:03:55 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534666; Mon 6-Feb-89 22:01:50 EST
Date: Mon, 6 Feb 89 22:01 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: What is Portable?  
To: RPG@SAIL.Stanford.EDU
cc: cl-editorial@SAIL.Stanford.EDU
In-Reply-To: <xlu3T@SAIL.Stanford.EDU>
Message-ID: <890206220123.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

I just don't want us to guarantee (as other compilers do) that the
compiler can detect arbitrary non-conforming programs.

I think that Lisp programmers do not view EVAL as something which does a
fun trick with data that makes it look like the data is executing. I
think they think the data is really executing.

As long as any claims we make about conformance checkability are explicitly
qualified with some remarks about EVAL, COMPILE, etc. clearly identifying
the issue, I will be happy.

This may save some implementors a few sleepless nights, and may keep
programmers from mistakenly believing too heavily in the myth that the
compiler can somehow do more of the error-checking job than it can. 

-----

By the way, a gray area is APPLY. Consider:
 (DEFUN FOO () (BAR #'(LAMBDA (X) X)))
 (DEFUN BAR (X) (APPLY X '(1 2)))
 (FOO)

Is this program conforming? If so, what general mechanism can detect
this?  If not, what if FOO is PROCLAIM'd INLINE?  (And then what if the
implementation ignores the INLINE declaration.)

Perhaps APPLY just needs to be in the pile with EVAL and COMPILE. It's
effectively a matter of delayed linking, not of delayed semantic analysis.

-----

Also, regarding user-defined extensions,... 

    ... No other standards document worries about the definition of
    extensions merely to capture the normal case of a programmer defining
    a routine and then using it. ...

In most other standards, it is very hard for users to write the kinds of
extensions the system provides. (Perhaps this is part of the motivation for
the system providing the extensions in the first place.) The kinds of 
extensions I'm thinking about are not extensions to the 775 CLtL symbols,
they are things like SYS:WITHOUT-INTERRUPTS, DW:ACCEPT, TV:MENU-CHOOSE,
FS:DIRECTORY-LIST, etc. Certainly in my experience in porting Macsyma to CL,
and then porting CL Macsyma between implementations, thes were the kinds of
extensions that were the hardest to spot and fix in a timely fashion because
the compiler really had no sense of the fact that FS:DIRECTORY-LIST was 
something provided by Genera but CLIMAX:MACSYMA-TOPLEVEL was provided by me.
As far as it was concerned, there were two non-Common Lisp symbols, and for
all it knew I planned to have both of them available in my porting environments.
Certainly this would have been the case for LOOP:LOOP even though it happened
to be provided by the system.

    I think there is no problem with stating that a conforming program may
    include references to defined functions and macros.

It is a possible and defensible thing to say. I just happen to think based on
very serious experience that it makes any claims about "conforming" just about
useless.

    I would not want to
    include syntactic extensions, such as multi-armed IF forms for example.

I'm personally happy with this position, but as I say, it's extremely small
consolation given the gaping hole you just left above.

    That is extensions to syntax should not be allowed in conforming programs,
    nor any extensions to the n symbols in the Lisp package (in today's terms,
    to the 775 CLtL symbols.).  ...

There's something I don't understand here. Do you mean "... in conforming
processors ..." or do you mean to suggest that programs might even consider
adding more symbols to CLtL? I can't imagine what class of things you're trying
to exclude in the second half of the "nor".

∂06-Feb-89  2108	CL-Editorial-mailer 	What is Portable?  
To:   kmp@STONY-BROOK.SCRC.SYMBOLICS.COM
CC:   cl-editorial@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


``I just don't want us to guarantee (as other compilers do) that the
compiler can detect arbitrary non-conforming programs.''

I agree.

``As long as any claims we make about conformance checkability are explicitly
qualified with some remarks about EVAL, COMPILE, etc. clearly identifying
the issue, I will be happy.''

I think all we should say about checkability is that checkability has
nothing to do with conformance. Perhaps we should say nothing. 

``  I think there is no problem with stating that a conforming program may
    include references to defined functions and macros.

It is a possible and defensible thing to say. I just happen to think based on
very serious experience that it makes any claims about "conforming" just about
useless.''

Ok, then let's say that any program that invokes a function or macro whose
definition does not accompany that program is non-conforming. This is fine
with me. This renders non-conforming a program that uses any extension
whose definition is not available as source.

``There's something I don't understand here. Do you mean "... in conforming
processors ..." or do you mean to suggest that programs might even consider
adding more symbols to CLtL? I can't imagine what class of things you're trying
to exclude in the second half of the "nor".''

Since we've agreed that no extensions can be used by conforming programs,
my attempt to allow some extensions is not relevant anymore.

In summary:

1. Conformance will not be machine-checkable.

2. Conforming programs can only use the functions, macros, special forms,
and symbols defined by the standard. The definitions of all other
functions, macros, or symbols must accompany the program.  

3. Conforming will only be defined for program structure, which we
will need to define.

			-rpg-

∂07-Feb-89  0319	CL-Editorial-mailer 	editorial committee meeting  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 7 Feb 89  03:19:09 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA18005; Tue, 7 Feb 89 03:17:30 PST
Message-Id: <8902071117.AA18005@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 7 Feb 89 05:45
To: cl-editorial@sail.stanford.edu
Subject: editorial committee meeting

Would it be better for the people on the west coast if the editorial
committee meeting were held Monday night? Please suggest convenient
times.

kc

∂07-Feb-89  0810	CL-Editorial-mailer 	What is Portable?  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Feb 89  08:08:50 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 7 Feb 89 10:50:47 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 7 Feb 89 11:03:20 EST
Date: Tue, 7 Feb 89 11:04 EST
From: Barry Margolin <barmar@Think.COM>
Subject: What is Portable?  
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: RPG@sail.stanford.edu, cl-editorial@sail.stanford.edu
In-Reply-To: <890206220123.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890207160456.7.BARMAR@OCCAM.THINK.COM>

    Date: Mon, 6 Feb 89 22:01 EST
    From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>

    By the way, a gray area is APPLY. Consider:
     (DEFUN FOO () (BAR #'(LAMBDA (X) X)))
     (DEFUN BAR (X) (APPLY X '(1 2)))
     (FOO)

    Is this program conforming? If so, what general mechanism can detect
    this?  If not, what if FOO is PROCLAIM'd INLINE?  (And then what if the
    implementation ignores the INLINE declaration.)

It is obviously not conforming.  A language processor that performs full
type propogation could determine that.  In BAR, X is implicitly defined
as a function that can take two arguments.  Therefore, BAR is implicitly
defined to take such a function as an argument, but in FOO BAR is called
with a function that requires exactly one argument.  Since the effect of
calling a function with the wrong number of arguments is undefined, this
program is not conforming.

                                                barmar

∂07-Feb-89  1244	CL-Editorial-mailer 	Editorial Committee Meeting  
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I could probably attend a 5pm meeting.

			-rpg-

∂07-Feb-89  1349	CL-Editorial-mailer 	Re: cut off dates  
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 89  13:49:05 PST
Date: 7 Feb 1989 16:46-EST
Sender: ROSENKING@A.ISI.EDU
Subject: Re: cut off dates
From: ROSENKING@A.ISI.EDU
To: chapman%aitg.DEC@DECWRL.DEC.COM
Cc: cl-editorial@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 7-Feb-89 16:46:11.ROSENKING>
In-Reply-To: <8902061018.AA01746@decwrl.dec.com>

← I agree with the CUT-OFF-DATES proposal and believe that a
strict adherence to it may allow us to complete the standard in
the desired time frame.  If an exception situation arises then
the exception clause may be voted on by the editorial committee
and/or X3J13 as a whole; I think this provides enough room for
modification, if it is needed.

One concern I have is on the cut-off-date for the Format of tool
descriptions.  The apparent need to modify (shorten) the standard
will most likely require a change in the tool description format.
I personally favor having the present format that we adopted, if
I was drafting the standard for my own use.  BUT, since I am not
the only intended user of this standard and since we are not the
only group (country) I agree that we have to consider the
feelings of all those who may use this document.

I will support a modification to the tool formats to extract the
examples field and put them in a library or appendix section.  If
addiontal measures need to be taken to "trim" the standard we may
want to limit the tool formats to just include a DESCRIPTION,
SYNTAX, ARGUMENTS and VALUES field, with the other fieldsput into
supplementary volumes of the standard.  Perhaps the Japanese, and
also the Germans, English and French, will provide alternative
methods for making the standard more concise.  Their input and
agreement, on ANSI Common LISP, will make the standard much more
valuable.

   Jeff Rosenking

∂14-Feb-89  0323	CL-Editorial-mailer 	Issue: EXTRA-SYNTAX
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Feb 89  03:23:38 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA07053; Tue, 14 Feb 89 03:21:21 PST
Date: Tue, 14 Feb 89 03:21:21 PST
Message-Id: <8902141121.AA07053@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTRA-SYNTAX

Issue:        EXTRA-SYNTAX
References:   Chapter 1, Section 1.5, Working draft of standard
Category:     Clarification
Related Issues: ERROR-TERMINOLOGY, EXTENSIONS-POSITION
Edit history: 8-JAN-89, Version 1 by Masinter
	      13-JAN-89, Version 2 by Chapman
	      3-FEB-89, Version 3 by Chapman
 

Problem: is it OK to extend Common Lisp macros and special forms to take
additional syntax not specified?
 
Proposal:  EXTRA-SYNTAX:NO
 
It isn't allowed, the conseqences are unspecified.
 
Rationale:

It would be very difficult for a program-analyzing-program to detect 
such an extension. Non-portable programs could easily result.

Current Practice:


Adoption Cost:

No cost to implementors, possibly a documentation change.

Benefits:



Conversion Cost:

Potentially some cost could be incurred, but none is required.

Aesthetics:

None.

Discussion:

∂14-Feb-89  0325	CL-Editorial-mailer 	Issue: UNSPECIFIED-DATATYPES 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Feb 89  03:24:57 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA07093; Tue, 14 Feb 89 03:22:44 PST
Date: Tue, 14 Feb 89 03:22:44 PST
Message-Id: <8902141122.AA07093@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: UNSPECIFIED-DATATYPES

Issue:        UNPSECIFIED-DATATYPES
References:   Chapter 1, Section 1.5, Working draft of standard
Category:     Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
	      6-FEB-89, Version 2 by Chapman
 


Problem: Is it OK to define the behavior of functions on datatypes not
explicitly permitted in the standard?  
 
Proposal: UNPSECIFIED-DATATYPES:NO-EXCEPT-AS-EXPLICITLY-ALLOWED

A conforming implementation does not define the behavior of functions
on data types not explicitly permitted in the standard. 

Example: A conforming implementation is not allowed to define + as
operating on vectors.
 
Rationale: 

While the original intent of CL designers was that
implementations be permitted to do these things, they get in the way of
portability when they're done, since it is nearly impossible to detect when
a program has used one of these features. It is simple to define a new
function 
acme-common-lisp:+ which has the behavior of the "portable" + plus all the
new whizzy features, too.
 
Current Practice:



Adoption Cost:

Implementors would have to determine which functions had been allowed
to operate on data types not explicitly allowed in CLtL and rewrite those
functions. The implementation's documentation would have to change.

Benefits:

Portability.

Conversion Cost:

See Adoption Cost.

Aesthetics:

None.

Discussion:

"The suggestion that implementations can shadow standard functions to
provide these features has been made before, and I'll repeat my standard
objection.  The behavior of a standard function is also apparent when
calling a portable function that is defined to use that function.  A
good example is FORMAT: a portable subroutine library would be quite
likely to define functions that take FORMAT-style argument lists
(Pitman's portable condition system defines several).  If an
implementation extends FORMAT, these extensions should be reflected in
the behavior of these functions.  But if the extensions are hidden in
ACME:FORMAT and the library calls LISP:FORMAT, this won't happen, and
there's no way to make it happen without modifying the library's source."
 

 

∂14-Feb-89  0324	CL-Editorial-mailer 	Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Feb 89  03:24:14 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA07068; Tue, 14 Feb 89 03:21:59 PST
Date: Tue, 14 Feb 89 03:21:59 PST
Message-Id: <8902141121.AA07068@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS

Issue:        EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
References:   Chapter 1, Section 1.5, Working draft of standard
Category:     Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
	      3-FEB-89, Version 2 by Chapman
 
Problem:
 
Is it OK to define Common Lisp functions with extra optional or named arguments
with system-dependent meanings?  
 
Proposal: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS:NO-EXCEPT-AS-ALLOWED
 
Unless explicitly allowed in the standard, the consequences of defining
Common Lisp functions with extra optional or named arguments with
system-dependent meanings are undefined.

When extra optional or named arguments are allowed in the
standard, they will be annotated as follows:
functions that may be
extended to take implementation-specific optional arguments are indicated
by an &REST IGNORE in their argument list; functions that may be extended
to take additional keyword parameters are indicated by &ALLOW-OTHER-KEYS. 
 
Rationale:

The goal is not to outlaw any extensions currently offered by
implementors, but to make the range of extensions to functions defined in
the standard well documented in the standard.  Implementations that want to
extend functions that aren't explicitly allowed to be extended can instead
shadow them.
 

Alternate proposal: NOT-IN-STANDARD-PACKAGE
 
Like NO-EXCEPT-AS-ALLOWED, except that an implementation may always
provide additional named arguments to a function if the names are not in
the LISP or KEYWORD packages.
 
Current Practice:

Most implementations extend function syntax with extra 
optional and named arguments.

Adoption Cost:

Implementors will be required to determine which parts of their implementations
are conforming and which parts aren't.
Implementors will have to provide a candidate list of exceptions to the
editorial committee.

Benefits:

It will be more possible to write portable programs. Also, future standards
will be less likely to make changes that are incompatible with current 
implementations.

Conversion Cost:

See Adoption Cost.

Aesthetics:

None.

Discussion:

∂14-Feb-89  0325	CL-Editorial-mailer 	Issue: EXTRA-RETURN-VALUES   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Feb 89  03:25:27 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA07129; Tue, 14 Feb 89 03:23:14 PST
Date: Tue, 14 Feb 89 03:23:14 PST
Message-Id: <8902141123.AA07129@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTRA-RETURN-VALUES

Issue:        EXTRA-RETURN-VALUES
References:   Chapter 1, Section 1.5, Working draft of standard
Category:     Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
	      3-FEB-89, Version 2 by Chapman
 

Problem: Is it OK to return extra values from Common Lisp functions?
 
Proposal: EXTRA-RETURN-VALUES:NO
Unless it is explicitly allowed in the standard,
if a standard function
returns a different number of return values from the number
specified by the standard, the results are unspecified.

 
Rationale:

The reason is that
additional arguments are visible to otherwise portable programs. "For
instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
will try to pass the wrong number of arguments to CONS if FLOOR returns an
extra value."                        

Current Practice:

Adoption Cost:

Implementations and their associated documentation that now contain 
functions that return extra values will have to change.

Benefits:

Programs will potentially become more portable.

Conversion Cost:

See Adoption Cost.

Aesthetics:

None.

Discussion:

∂14-Feb-89  0326	CL-Editorial-mailer 	Issue: MACRO-AS-FUNCTION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Feb 89  03:26:34 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA07149; Tue, 14 Feb 89 03:24:22 PST
Date: Tue, 14 Feb 89 03:24:22 PST
Message-Id: <8902141124.AA07149@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: MACRO-AS-FUNCTION

Issue:        MACRO-AS-FUNCTION
References:   Chapter 1, Section 1.5, Working draft of standard
Category:     Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
	      6-FEB-89, Version 2 by Chapman
 


Problem: 

May operators defined in the standard as "macros" and
"special forms" be implemented as functions instead? PROG1 is the main
example, but there might be others.
 
Proposal: MACRO-AS-FUNCTION:YES
 
Operators that are defined in CL as "macros" may be defined as functions
instead if the semantics can be preserved. 

This is rare, perhaps only
restricted to
 
(defun prog1 (value &rest ignore) value)
(defun prog2 (value1 value2 &rest ignore) value2)


Operators defined as "special forms" may also be defined as functions.


Alternate Proposal: MACRO-AS-FUNCTION:STATUS-QUO

The standard will remain silent on the issue of whether or not is
is legal for an implementation to implemention "macros" and 
"special forms" as functions.

Alternate Proposal: MACRO-AS-FUNCTION:DISALLOW

A conforming implementation does not define "macros" and "special forms"
as functions.

Rationale: 

There isn't a good reason to disallow "macro" and "special form" function
definitions. It doesn't interfere with portability.
 
 
Current Practice:

One implementation defines PROG1 as a function.

Adoption Cost:

None for :YES; some for :DISALLOW.

Benefits:

Increased implementation flexibility.

Conversion Cost:

None.

Aesthetics:

None.

Discussion:

∂14-Feb-89  0326	CL-Editorial-mailer 	Issue: UNSOLICITED-MESSAGES  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Feb 89  03:25:58 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA07134; Tue, 14 Feb 89 03:23:49 PST
Date: Tue, 14 Feb 89 03:23:49 PST
Message-Id: <8902141123.AA07134@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: UNSOLICITED-MESSAGES

Issue:        UNSOLICITED-MESSAGES
References:   Chapter 1, Section 1.5, Working draft of standard
Category:     Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
	      6-FEB-89, Version 2 by Chapman
 


Problem: Is it legal for an implementation to produce unsolicited output,
e.g., GC notifications, autoload heralds, and progress messages from
COMPILE-FILE or LOAD?
 
Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS
 
Unsolicited messages, such as GC notifications and autoload heralds, if
they are produced by an implementation, should not be directed to
*STANDARD-OUTPUT*, *ERROR-OUTPUT*. If an implementation produces them, they
may be produced on a stream that is not "shared" with any of the streams
that a user might redefine or redirect. (This really means that it is OK to
direct such notifications to *TERMINAL-IO* since a user may not redirect
*TERMINAL-IO*.)
 
Messages such as progress reports from LOAD and COMPILE are "solicited",
and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.
 
 
Rationale:

This proposal has very little impact on implementations, but helps the
user by explicitly stating the disposition of unsolicited messages.

Current Practice:

Adoption Cost:

Small. Implementations and their documentation may have to change slightly.

Benefits:

Portability.

Conversion Cost:

See Adoption Cost.

Aesthetics:

None.

Discussion:

∂14-Feb-89  0930	CL-Editorial-mailer 	Issue: EXTRA-SYNTAX
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Feb 89  09:30:35 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 14 Feb 89 12:22:24 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 14 Feb 89 12:24:36 EST
Date: Tue, 14 Feb 89 12:27 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: EXTRA-SYNTAX
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902141121.AA07053@decwrl.dec.com>
Message-Id: <19890214172735.1.BARMAR@OCCAM.THINK.COM>

    Date: Tue, 14 Feb 89 03:21:21 PST
    From: chapman%aitg.DEC@decwrl.dec.com

    Issue:        EXTRA-SYNTAX
    References:   Chapter 1, Section 1.5, Working draft of standard
    Category:     Clarification
    Related Issues: ERROR-TERMINOLOGY, EXTENSIONS-POSITION
    Edit history: 8-JAN-89, Version 1 by Masinter
		  13-JAN-89, Version 2 by Chapman
		  3-FEB-89, Version 3 by Chapman
 

    Problem: is it OK to extend Common Lisp macros and special forms to take
    additional syntax not specified?
 
    Proposal:  EXTRA-SYNTAX:NO
 
    It isn't allowed, the conseqences are unspecified.
 
The consequences of what?  I thought that Lisp programs, not
implementations, have consequences.

                                                barmar

∂14-Feb-89  0944	CL-Editorial-mailer 	Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Feb 89  09:44:09 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 14 Feb 89 12:35:33 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 14 Feb 89 12:37:28 EST
Date: Tue, 14 Feb 89 12:40 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902141121.AA07068@decwrl.dec.com>
Message-Id: <19890214174026.2.BARMAR@OCCAM.THINK.COM>

    Date: Tue, 14 Feb 89 03:21:59 PST
    From: chapman%aitg.DEC@decwrl.dec.com

    Issue:        EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
    References:   Chapter 1, Section 1.5, Working draft of standard
    Category:     Clarification
    Edit history: 8-JAN-89, Version 1 by Masinter
		  3-FEB-89, Version 2 by Chapman
 
    Problem:
 
    Is it OK to define Common Lisp functions with extra optional or named arguments
    with system-dependent meanings?  
 
    Proposal: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS:NO-EXCEPT-AS-ALLOWED
 
    Unless explicitly allowed in the standard, the consequences of defining
    Common Lisp functions with extra optional or named arguments with
    system-dependent meanings are undefined.

The wording of this isn't right.  It sounds like it is prohibiting users
from defining CL functions with extra arguments, but users are already
prohibited from defining CL functions in the first place.  It should say
that it is disallowing implementations from including such definitions.

Also, as I said in my previous message, "consequences are undefined" is
a phrase we use for describing the result of a CL program, not an
implementation.
 
    Rationale:

    The goal is not to outlaw any extensions currently offered by
    implementors, but to make the range of extensions to functions defined in
    the standard well documented in the standard.  Implementations that want to
    extend functions that aren't explicitly allowed to be extended can instead
    shadow them.
 
Well, unless someone comes up with the list of allowable extensions, it
sure sounds like we're disallowing lots of extensions currently offered.
I know Symbolics has extended many functions in this way.  I'm not sure
I would feel comfortable voting on this without knowing which extensions
will get a reprieve.

    Alternate proposal: NOT-IN-STANDARD-PACKAGE
 
    Like NO-EXCEPT-AS-ALLOWED, except that an implementation may always
    provide additional named arguments to a function if the names are not in
    the LISP or KEYWORD packages.
 
Or USER package?  This list of protected packages has come up before,
and we should probably come up with a single term to denote the packages
that implementors are allowed to put their extensions in.  How about
"implementation-specific package", which would currently be defined as
"any package other than LISP, KEYWORD, and USER".  It might be further
restricted if a package registry were ever set up, but this wouldn't
require changing all the references in the standard.

                                                barmar

∂16-Feb-89  2357	CL-Editorial-mailer 	Re: Issue: CONFORMANCE-POSITION   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Feb 89  23:57:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 FEB 89 23:51:29 PST
Date: 16 Feb 89 23:50 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CONFORMANCE-POSITION
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Thu, 2 Feb 89 09:51:51 MST
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu
Message-ID: <890216-235129-4932@Xerox>

I have a copy of the C standard ("Draft Proposal, American National
Standard Programming Language C") and the definition of compliance is
different than the characterization here. It defines a "strictly conforming
program" and a "conforming program", two forms of "conforming
implementations" (both "conforming hosted implementation" and "conforming
freestanding implementation".)

It says "A conforming implementation may have extensions (including
additional library functions), provided they do not lter the behavior of
any strictly conforming program."

There's also definitions of "Unspecified behavior" vs "Undefined behavior"
vs "Implementation-defined behavior" vs "Locale-specific behavior". 

Under "Future directions", it talks not about "deprecation" but rather
"Certain features are obsolescent, which means that they may be considered
for withdrawal..."

I think we should pay more attention to the C standard than some of the
older standards just because it is more "current".

I have the May 13, 1988 DRAFT. I'm sorry this is such a poor summary. Can
we get copies directly from X3J11?

David F. Prosser ("Redactor, X3J11") is listed with address AT&T; 190 River
Rd. Summit NJ 07901. Perhaps we could make some direct contact with those
who were working on the conformance/compliance section.


 

∂24-Feb-89  0354	CL-Editorial-mailer 	editorial committee meeting  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 89  03:54:48 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA03048; Fri, 24 Feb 89 03:52:55 PST
Message-Id: <8902241152.AA03048@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA03048; Fri, 24 Feb 89 03:52:55 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 24 Feb 89 06:52
To: cl-editorial@sail.stanford.edu
Subject: editorial committee meeting

 
A few things:
 
A suggestion has been made that we meet Monday night (3/27) at a Turkish
restaurant at 6:00 PM. We would have a private room and would be able
to work there until the place closes (9-10? Do you know, Bob?).
1. How many of you could come to that meeting?
2. If you don't like the suggestion, where/when would you rather meet?
 
In light of the current push to reduce the size of the standard, and due
to the fact that by the end of our standard-creation we will have many
proposed additions that we will not incorporate, I propose we create two
appendices to the standard - one that houses the non-essential parts of the
standard (TBD later), and the other that houses our "recommendations" for
future standards committees (that will include things we wanted to add but
didn't feel they were ready, and also things we took out or deprecated).
What do you think?
 
Do you have suggestions for agenda items for our meeting?
 
kc
 
========================================================================
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA02457; Fri, 24 Feb 89 03:46:24 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for aitg::chapman; id AA02457; Fri, 24 Feb 89 03:46:24 PST

∂24-Feb-89  0922	CL-Editorial-mailer 	editorial committee meeting  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 24 Feb 89  09:22:33 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 24 Feb 89 12:03:54 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 24 Feb 89 12:02:05 EST
Date: Fri, 24 Feb 89 12:05 EST
From: Barry Margolin <barmar@Think.COM>
Subject: editorial committee meeting
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <8902241152.AA03048@decwrl.dec.com>
Message-Id: <19890224170504.5.BARMAR@OCCAM.THINK.COM>

    Date: 24 Feb 89 06:52
    From: chapman%aitg.DEC@decwrl.dec.com
 
    A few things:
 
    A suggestion has been made that we meet Monday night (3/27) at a Turkish
    restaurant at 6:00 PM. We would have a private room and would be able
    to work there until the place closes (9-10? Do you know, Bob?).
    1. How many of you could come to that meeting?

I can.  I'm trying to book a flight Monday morning, so I can also make
an meeting that starts in the middle of the afternoon.

What's Turkish food like?

                                                barmar

∂25-Feb-89  0212	CL-Editorial-mailer 	editorial committee meeting  
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 25 Feb 89  02:12:46 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab04504; 24 Feb 89 23:33 EST
Received: from utokyo-relay by RELAY.CS.NET id ab14896; 24 Feb 89 23:27 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
	id AA24858; Sat, 25 Feb 89 11:13:12 JST
Received: from kepa.cc.aoyama.junet by aoyama.cc.aoyama.junet (4.0/6.4J.BETA2-agu1)
	id AA22002; Sat, 25 Feb 89 11:02:58 JST
Received: by kepa.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA05492; Sat, 25 Feb 89 11:03:17 JST
Date: Sat, 25 Feb 89 11:03:17 JST
From: Masayuki Ida <ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@cc.aoyama.junet>
Message-Id: <8902250203.AA05492@kepa.cc.aoyama.junet>
To: chapman%aitg.DEC@DECWRL.DEC.COM
Cc: ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET, cl-editorial@SAIL.STANFORD.EDU
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 24 Feb 89 06:52 <8902241152.AA03048@decwrl.dec.com>
Subject: editorial committee meeting

Dear Kathy Chapman,

I did arrange to attend the X3J13 march meeting.
And I will fly to Fairfax from Boston in the afternoon of 27th.

   >>From: chapman%aitg.DEC@decwrl.dec.com
   >>Date: 24 Feb 89 06:52
   >>A suggestion has been made that we meet Monday night (3/27) at a Turkish
   >>restaurant at 6:00 PM. We would have a private room and would be able
   >>to work there until the place closes (9-10? Do you know, Bob?).
   >>1. How many of you could come to that meeting?
I hope to attend if I can find the Turkish restaurant.
(It's first time for me to visit Fairfax)
6:00PM is fine for me, but where the restaurant is ?
   >>kc
Masayuki Ida


∂03-Mar-89  1111	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Mar 89  11:11:47 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 550264; Fri 3-Mar-89 14:08:58 EST
Date: Fri, 3 Mar 89 14:08 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-TERMINOLOGY
To: RPG@Lucid.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Editorial@SAIL.Stanford.EDU
In-Reply-To: <8903031755.AA20493@challenger>
Message-ID: <19890303190851.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

I have lingering objections which I consider essential. These have 
been conveyed previously to Kathy with other comments; she's improved
the document a lot, but there's still a way to go before I can say
it is acceptable.

 - I think "should signal" should say that conforming code may rely
   on the fact that the error will be signalled in safe code.

 - The example of "should signal" (ENDP) is not something that we
   have agreed "should signal." Right now, ENDP is in the "is
   undefined" camp.

 - I would prefer that both "consequences are unspecified" and 
   "consequences are undefined" refer to "direct consequences" rather
   than just "consequences". I believe this avoids the issue that I've
   raised previously that there may be second-order effects of "unspecified"
   which are not harmless (due to the unpredictability part).

 - For "Implementations may be extended" I would add:
   "All conforming implementations are required to document for each such
     case which of these options they have chosen."

 - For "Free to extend the syntax, I would add:
   "All conforming implementations are required to document each such
     extension."

 - For both "Warning is issued" and "Warning should be issued", I am
   concerned about the use of the term "the compiler". In compiled only
   implementations, if "(FOO)" is a form form which a warning "is issued"
   then must (DOTIMES (I 5) (FOO)) warn 5 times? Can an interpreted only
   implementation never warn? If so, then of what value is it to define
   that this will "always happen," or even "always happen in safe code"?
   We need to be more explicit or this is a joke.

 - The example for "warning is issued" amounts to a change in semantics.
   We have never voted that a warning must be issued in this case.

 - The example for "warning should be issued" amounts to a change in
   semantics. We have never voted that a warning "should be" (in the formal
   sense) issued in this case.

Until these issues are dealt with, my personal recommendation to Moon
will be that Symbolics vote `No with comments' on this issue.

∂04-Mar-89  0844	CL-Editorial-mailer 	voting   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Mar 89  08:44:53 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA28918; Sat, 4 Mar 89 09:42:48 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA04953; Sat, 4 Mar 89 09:42:45 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903041642.AA04953@defun.utah.edu>
Date: Sat, 4 Mar 89 09:42:44 MST
Subject: voting
To: chapman%aitg.dec@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu

This probably sounds like a dumb question, but...

What exactly does voting on sections of the standard document mean?

I have been slogging through the material to be voted on at the March
meeting (I'm about a third of the way through it now) and it's
apparent to me that it still needs a lot of work.  In some places it
says things that are just plain wrong, in other places the wording or
organization is confusing, and in still others important concepts have
been left out.  I have been keeping notes on all of these things
(which I will send you as soon as I've finished), but I can't see that
it would be very productive to spend a lot of time at the meeting
presenting these as amendments or having protracted discussions about
wording.  On the other hand, I can't in good conscience vote for
either the language in its current form, or for fixed-up language that
I haven't seen. 

What this all boils down to is that I think the schedule needs to be
adjusted to allow time for a review cycle between the time each
section is first distributed to X3J13 and the time it is voted on.
Or, perhaps we should dispense with voting entirely, and make the
deadlines you've set for "voting" actually be deadlines for reviewing
and commenting upon each section.  Basically I trust you to make the
right decisions about the suggestions you receive.  If people still
have problems with the wording after that, I think it would be
appropriate to resolve them with a specific cleanup issue. 

-Sandra
-------

∂04-Mar-89  2051	CL-Editorial-mailer 	What is a FUNCTION?
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Mar 89  20:50:55 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 550888; Sat 4-Mar-89 23:48:29 EST
Date: Sat, 4 Mar 89 23:48 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: What is a FUNCTION?
To: sandra%defun@cs.utah.edu
cc: CL-Editorial@SAIL.Stanford.EDU
In-Reply-To: <8903032337.AA04478@defun.utah.edu>
Message-ID: <890304234830.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Fri, 3 Mar 89 16:37:14 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    To me, it seems like the definition of the FUNCTION type ought to
    incorporate at least the following four notions:

``If it walks like a duck, ...''

To me, the only important part about a function is that it behaves like
a function.  Functions defined in C, Pascal, or Fortran should not be
considered second class citizens as long as they behave correctly under
all the defined operations.

    - encapsulation of process as object

I have trouble thinking of an `accessor' as a `process.' Certainly the
process is trivial.

Inline functions also make me wonder about this. A function might get
compiled away altogether, leaving no trace of `process' ...

    - capture of lexical environment 

I could imagine `functions' that were defined in a language that captured
little or no lexical environment.

    - generalization via parameters

Even though some functions take arguments, others do not. As such, the
ability to `take arguments' is not criterial to being a function.

    - evaluation of body delayed until funcall

Some functions might have been defined by generating an instruction or
instruction stream directly, without ever going through the lisp abstraction.
As such, the concept of a `body' may be ill-defined.

    Also I would expect to see a statement that FUNCTION objects are
    created by the evaluation of a (FUNCTION (LAMBDA ...)) form.

They might be created in other ways.

    Would anybody like to take a stab at putting together a better
    definition?

I'm writing this at a time when I don't have the definition you're
referring to handy, so I'm only reacting to what you wrote in your
message. But from what you included, the definition doesn't sound so bad.

∂04-Mar-89  2223	CL-Editorial-mailer 	comments on various sections of the draft   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Mar 89  22:22:52 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA09446; Sat, 4 Mar 89 23:20:49 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA05294; Sat, 4 Mar 89 23:20:43 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903050620.AA05294@defun.utah.edu>
Date: Sat, 4 Mar 89 23:20:40 MST
Subject: comments on various sections of the draft
To: chapman%aitg.dec@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu

Here's the promised comments on the sections of the document that were
indicated as coming up for a vote at the upcoming meeting.  Some of
these things are just nit-picking about typography or diction, but
others reflect serious inaccuracies, or problems with terminology or
organization that I think need to be addressed before I can put my
stamp of approval on this material. 

Lest you all think I have nothing positive to say about what's been
done so far, I think things are overall in pretty good shape.  This
document is turning into a massive undertaking and it's understandable
that it would be a little rough around the edges at this stage.


Section 1.1
-----------

Perhaps I'm being chauvinistic here, but I think that the history section
ought to include a paragraph on Standard Lisp.  After all, it *was* the
only standard dialect of Lisp in existence before the advent of Common
Lisp.  How about:

  Meanwhile, researchers at the University of Utah began the first
  efforts towards standardization of Lisp.  The goal was to arrive at a
  minimal common subset of the various Lisp dialects then in existence
  to use as a basis for implementing the REDUCE algebra system.  The
  specification for this subset, known as Standard Lisp, was first
  published in 1969 and revised in 1978.  There followed a compiler (the
  Portable Lisp Compiler) and a full implementation (Portable Standard
  Lisp), which was first released in 1982.


Section 1.3
-----------

Here is the bibliography entry for the Standard Lisp report:

@Article{Marti-sigplan79,
	key={Marti},
	author={Marti, J.B. and Hearn, A.C. and Griss, M.L. and Griss, C.},
	title={Standard LISP Report},
	journal={SIGPLAN Notices},
	volume={14}, number={10},
	Month={October}, year={1979},
	pages={48-68}
	}


Section 1.4
-----------

I have been having a hard time making sense of the use of the various
fonts throughout the document.  For example, names of functions and
constants appear in a typewriter font in tables, but in a boldface
Roman font in running text.  But, names of variables appear in
boldface Roman font in tables.  Let's try to be consistent -- either
use boldface all the time for everything or put everything in the
tables in typewriter font. 

I've also found it distracting when practically every word in a
sentence is in a different font -- it reminds me of a pasted up ransom
note!  I've noted some things that seemed particularly bothersome as
I've run across them, but I don't pretend that my list is exhaustive.
I have some suggestions for more general guidelines when the special
fonts should *not* be used for words which are type names or in the
glossary:

 - when they are used as adjectives, unless the glossary defines the
   term as an adjective and not a noun.  For example, "package name"
   or "type upgrading" or "type information".

 - when they are qualified with a type name.  This applies especially
   to the word "object".  I don't think it needs to be italicized when
   one refers to "a pathname object" or "an object of type pathname".

 - when it refers to a specific named object ("the KEYWORD package",
   "the TYPEP function").

 - when it is used in a different or more general sense than what 
   the glossary defines (using "function" in its mathematical sense,
   "type" used to mean "kind").

A more radical suggestion would be to only italicize words in the
glossary when they are first introduced in a particular section, or to
use some less intrusive way of indicating them (such as putting a list
of the glossary words that are used on each page at the bottom of the
page). 

TeX hint: There seems to be some problems with spacing around items
printed in one of the slanted fonts.  Remember to add \/ at the end to
leave the right amount of space. 


Section 1.5
-----------

I don't see much point in finalizing this until issue CONFORMANCE-POSITION
is resolved.


Section 1.6
-----------

Values, page 1-11 to 1-12: In items 2 and 3, shouldn't names of
arguments be in the slanted sans-serif font that is used in other
places? 


Data Representation and Typing, page 1-13:

Item 2: This doesn't make sense.  Do you mean that if the type
specifier is a specialized array type, the implementation is allowed
to "upgrade" the array element type?  Was this covered under whatever
cleanup issue dealt with array upgrading?

Item 3: This has nothing to do with data representation or typing.
Move it to the "Miscellaneous" section.


Numerical Calculations:

Item 2: This could be stated more clearly:  Whether or not two numbers or
characters that are EQL are necessarily EQ....

Item 3:  This is bogus.  If the numbers are of different types, they
can't possibly be EQL.  I believe that what you really want to do is
put an item under the "Data Representation and Typing" heading that
states:  Whether or not the types SHORT-FLOAT, SINGLE-FLOAT, LONG-FLOAT,
and DOUBLE-FLOAT are disjoint is implementation-dependent.


Input/Output:

Item 5:  It seems like we should also add something about the range of
numbers that can be correctly formatted in English and Roman formats
using ~R being implementation specific.  Also the exact format of the
output may vary; for example, the British use "milliard" instead of
"billion".

Item 6:  "is distinguished" => "is distinguished by LOAD" ??

Item 9:  Items b and c seem to contradict each other.  Is signalling
an error for one of the things specified in item b "reasonable"?  I'd
throw out item b.

Item 12:  "Typed" => "printed"?

Items 16,17:  These are affected by the character set proposals.


Compiling:

Item 3:  We have a proposal, CONSTANT-COLLAPSING, that would generalize
this.  Also, we've started calling this "coalescing" instead of 
"collapsing".

Item 4:  This doesn't make much sense.  What "object"?  I'd delete this
entire item.


Section 1.7
-----------

Again, it seems premature to finalize this section until the issues
it depends on are resolved.


Section 2.1
-----------

Page 2-3:

First paragraph, "(a type)" => "(or simply, a type)"

The third sentence of the first paragraph is confusing.  How about:
"TYPEP, a set membership test, is used ..."

Second paragraph:  "a type declaration (such as a TYPE declaration)"
seems unnecessarily redundant.  How about some mention of the THE
special form here, too?

Third paragraph:  the last sentence doesn't belong here.  It has nothing
to do with the rest of the paragraph.


Section 2.2
-----------

First, some general remarks.

One thing I noted that happens all over this section is saying that
an object of type <foo> is called a <foo>.  Is it really necessary to
repeat this for every type?  I don't think it really adds anything.
A couple of other people here have also indicated that they think
this sounds really stupid.

There are two big omissions from this section:

- Where do the instance, class, method, generic-function types fit into
  the type hierarchy? 

- Where is CONDITION and all of the condition subtypes?

These things are just as much part of standard Common Common Lisp as
every other type and deserve equal treatment.

Page 2-5, last paragraph: The definition of COMMON needs to be updated
to include the CLOS and condition types. 

Page 2-6: What do the little tick marks all over the graph mean?


Data Type Definition:

T type, page 2-7: the caption "t" => "T" (other captions are
capitalized). 

NUMBER type, page 2-7: I am confused by the use of italics here.  In
the first bullet, why is "shorter" italicized but not "longer"?  Why
is "function" italicized in the second bullet but not in the paragraph
following the bulleted list? 

FIXNUM type, page 2-11: issue FIXNUM-NONPORTABLE put some additional
restrictions on fixnum range.

FLOAT type, page 2-11: I think the information about the four
different subtypes could be arranged a little better.  I would delete
the first sentence and the last four sentences of the first paragraph,
and the first sentence of the last paragraph on this page, and replace
it with something like: "Four subtypes of FLOAT are defined:
SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, and LONG-FLOAT."

Throughout this section there are problems with the font used for
"floating-point".  Most of the time both words are in slanted font,
but sometimes only "floating" and sometimes neither word.  More
generally, why can't we just call an object of type FLOAT a "float"
instead of a "floating-point number"?  This is what C does. 

CHARACTER type: obviously a lot of this will change as a result of
the character set proposals.

SYMBOL type, page 2-16: We had a discussion about terminology for
symbols on the cl-compiler mailing list some time ago.  The consensus
was that it is very misleading to describe things like the property
list as "components" of a symbol (among other reasons, because it
conjures up possibly inaccurate mental images about the internal
representation of symbols).  Could you please use words like
"attribute" or "associated with" instead of "component" or "composed
of"?  Likewise, I would like to banish the term "package *cell*" and
instead just call it the symbol's home package. 

There are numerous inaccuracies throughout this whole section; for
instance, "package name" is incorrect in the first sentence, the
description of interning in the second and third paragraphs is not
quite right, the escape characters mentioned at the top of page 2-17
are attributes of the reader and printer and not the print name, etc. 

Finally, the phrase "interning a symbol in a package" is extremely
confusing and I think it should not appear at all in the standard.
CLtL defines it as "making an existing symbol accessible in a
package", but it's commonly used to mean "calling the function
INTERN".  Rather than using this confusing phrase, let's just say
what we mean instead.

I would replace the entire section with something like:

  Symbols are used to name variables and functions in Common Lisp.
  Symbols have other attributes associated with them, including a print
  name, a home package, and a property list.  

  A symbol is uniquely identifiable by its print name from any package
  in which it is accessible; see [wherever the package system is
  talked about].  A symbol is said to be interned in a package if it is
  accessible in that package and also has a home package (which may not
  be the same).  If a symbol has no home package, then it is said to be 
  uninterned.  

  The function INTERN is used to create interned symbols.  The functions
  IMPORT and SHADOWING-IMPORT are used to make symbols accessible from a
  package, while the function UNINTERN is used to make a symbol
  unaccessible from a package.  Calling UNINTERN to remove a symbol from
  its home package causes it to become uninterned.

  Symbols have the following user-visible attributes:

  Property list [is there a more general section on property lists anywhere?]

    A symbol's property list effectively provides it with many modifiable
    named attributes.  A property list is represented as an even-length
    list, the even-numbered elements of which are keys or indicators, and
    whose odd-numbered components are arbitrary Lisp objects associated
    with the immediately preceeding indicator; indicators must be unique.
    A property list is an object with a unique identity and operations for
    adding and removing entries are normally destructive operations.
    Common Lisp provides operations both for direct manipulation of property
    list objects and for implicit manipulation of the property lists associated
    with symbols.

    The property list associated with a symbol is initially empty.

  Print name

    The print name is a string used to identify the symbol.  Every symbol
    has a print name, and that name cannot be altered.  The print name is
    used as part of the external, printed representation of the symbol;
    see [wherever read/print syntax is described]. 

  Home package

    When an interned symbol is created by INTERN, the package in which it
    is initially interned becomes that symbol's home package.  A symbol's 
    home package can be accessed using the function SYMBOL-PACKAGE.  If a 
    symbol is uninterned (has no home package), SYMBOL-PACKAGE returns NIL.

  Symbols may also have other attributes for use by the implementation.
 
Page 2-17:  Why are the tools for symbols not placed in tables like
all the other lists of tools?

STRING type, page 2-19: The third paragraph disagrees with what CLtL
says on this issue (page 299): "[Any of these functions] will accept a
symbol instead of a string as an argument -provided- that the
operation never modifies that argument."  My interpretation is that it
is acceptible to pass a symbol only to functions that aren't
permitted do destructive operations on that argument.  The wording here
says something else entirely.

CONS type, page 2-21: It ought to be mentioned that a CONS has a CAR
and a CDR component.

ARRAY type, page 2-21: ARRAY also has subtypes STRING, BIT-VECTOR,
etc.  If you don't want to name all the built-in array subtypes here,
fine, but instead of saying "has subtypes" use "has subtypes
including" or something like that.

ARRAY type, page 2-22: The use of the slanted font for the word "array"
is very inconsistent in the sixth paragraph.

HASH-TABLE type, page 2-24: 

"contains keys and values" => "contains pairs of keys and values".

I don't think the word "symbols" (at the bottom of page 2-24 and top
of 2-25) should be italicized.

page 2-26, third paragraph: I know this is exactly what CLtL says, but
I think it's inaccurate.  First of all, the hash table always has a
"size", not just when it's first created.  Second, it's not the
maximum number of entries it can hold, it's the maximum it can hold
without collisions.

PACKAGE type, page 2-25:  Last sentence, "representation" => "printed
representation".

page 2-26: 

First paragraph, last sentence: "appear in EXPORT" => "have been
exported from that package". 

Second paragraph, last sentence -- this is not because "of the
presence of package qualifiers (: and ::)", but because the way in
which symbols are printed depends on whether or not they are
accessible in *PACKAGE*. 

Third paragraph -- being able to refer to a symbol without a package
qualifier seems more like a consequence of it being accessible than
a condition.  A symbol becomes accessible in a package if that is its
home package when it is created; if it is imported into that package;
or by inheritance via USE-PACKAGE.

Next to last paragraph -- same problem; the key point is not that you
don't need a package qualifier, but that the symbol becomes accessible.
Also, the use of slanted font for "package" is inconsistent here. 

PATHNAME type, page 2-29/2-30: What happened to :UNSPECIFIC as a
pathname component?  We voted on that at the last meeting. 

Page 2-31, second paragraph:  The first sentence doesn't make sense.
Under what circumstances does parsing and merging take place, and
what are the pathnames merged with?  Delete it.

FUNCTION type, page 2-32:  This is really a terrible definition.  I've
raised this as a separate issue on the mailing list.

COMPILED-FUNCTION type, page 2-32: This section will have to be
rewritten to reflect the outcome of issue COMPILED-FUNCTION-REQUIREMENTS.
Basically we are going to try to get an explicit statement that functions
compiled with COMPILE or loaded from a file compiled with COMPILE-FILE
are of type COMPILED-FUNCTION.  We may or may not assign some other 
attributes to COMPILED-FUNCTIONs as well.

COMMON type, page 2-32: It seems like you should repeat the
enumeration of what types are in COMMON that was stated on page 2-5
here, or at least put in a reference to it.  Also "objects required by
the Common Lisp language" is a little unclear; how about "datatypes
required to be supported by every Common Lisp implementation"?

NIL type, page 2-32: Why the boldface NIL?


Type specifiers

Page 2-32, "There are two reasons....": Actually, there are more than
two reasons.  A couple other reasons are to allow increased error
checking and to allow the use of more compact specialized
representations.  Anyway, I don't really understand what this has to
do with what a type specifier is.  Before we voted to remove the idea
of different semantics between declaration and discrimination, it
might have made sense to talk about what made the two situations
different here, but as things stand, this text ought to be removed.

Pages 2-32 to 2-34: The text describing the three figures is a mess,
partly because it's spread over three pages.  To me it seems like
figure 2-31 should logically come before figure 2-30.  Also, it's not
clear that these figures describe only the syntax of built-in type
specifiers and that it is possible to extend the syntax. 

Let's combine the text into one paragraph that comes before any of the
figures:

"Type specifiers in Common Lisp may be either symbols or lists.  Figure
2-31 gives the syntax for all built-in Common Lisp type specifiers.
Figure 2-30 lists symbols which are built-in Common Lisp types, and
Figure 2-32 gives other definitions applicable to the syntax for
type specifiers.  Note that it is possible to define new type specifiers."

Page 2-33: Why is MOD in this table and not MEMBER, NOT, AND, OR,
and VALUES (these being the remaining standard list type specifiers)?

Page 2-34: Where did the list form of the FIXNUM type specifier come
from?  Also, VALUES is missing.

Page 2-36, first paragraph:  "predicate-name, lambda-expressions" =>
"predicate-name; lambda-expressions".

Page 2-36, under INTEGER:  instead of "smallest" and "largest", why 
not use the constants MOST-NEGATIVE-FIXNUM and MOST-POSITIVE-FIXNUM?

Page 2-38, next to last paragraph:  "including for example arrays" =>
"including, for example, arrays"

Page 2-40 to 2-41, under FUNCTION:  Oops, I guess we need to talk about
"for discrimination" and "for declaration" after all.  Didn't we vote
on a cleanup issue at the last meeting to clarify what a FUNCTION
declaration really means?  Also a formatting problem: all of the text
under this heading ought to be indented and isn't. 

Page 2-42, figure 2-33:  shouldn't TYPEP and SUBTYPEP be listed in this
table?


Type Ugrading:

Page 2-42:  All the different fonts are confusing here.  I don't think
"Type" needs to be italicized where it appears as the first word of 
the 4th paragraph, or in the first sentence of the 6th paragraph.


Section 5.1
------------

Error Terminology:

I don't see much point in trying to finalize this section until the
ERROR-TERMINOLOGY issue is resolved. 


Condition System Concepts:

Condition System Data Types:

Don't all the type definitions in this section really belong in
section 2.2?  

Page 5-7, typo in heading ("Condtion" => "Condition")

Page 5-7, first paragraph:  Replace first sentence:  "This document
describes only the standard set of condition types.  Other condition
types may be defined using DEFINE-CONDITION."

Page 5-10: There's a problem with the indentation here.  The text
beginning "For example..." doesn't really belong under the
PACKAGE-ERROR heading, right?  I read all the way through the example
wondering what on earth it had to do with packages....

Page 5-12:  More problems with fonts.  I don't think you need to use
the slanted font for "condition" when it is used as an adjective, as
in "condition system".

Page 5-12, figure 5-3: WARN and *BREAK-ON-WARNINGS* are missing.  Also
you've lost the caption to this figure on the top of the next page. 

Page 5-16 to 5-18, Printing Conditions: I had a hard time
understanding this section. 

First, there is not enough context for the discussion to make sense.
How about adding to the end of the first sentence: "... when an
attempt is made to print the condition object".  Also, "This" as the
subject of the next sentence is too vague.  I'd say something like:
"Conditions are normally printed automatically by functions...."

Second, all the stuff about the form of text for report methods seems
very useless without some hint as to why users need to concern
themselves with it.  You need to say that users can specify a report
method for a condition type (when it is defined with DEFINE-CONDITION?
I don't have my copy of the error proposal handy to check on the
details). 

Page 5-18, Assertions:  The document ought to say what an assertion is.

Page 5-18, Restarts: 

In first paragraph, avoid use of passive voice: "Control can be
transferred..." => "A condition handler can transfer control to other
points in the program, however, by invoking specially established
restarts."

The indentation of the example needs help.

Page 5-20:  More indentation problems in the examples.

Page 5-21, next to last paragraph:  "the options are keyword-style and are" =>
"the options are keyword/value pairs".  

Page 5-22, first paragraph, the last "sentence" doesn't make sense.
Try replacing it with something like "For example, suppose file space
is exhausted and the following is done:".  Also, the indentation of
the example needs to be fixed again. 

Page 5-22, Warnings:  Aha, here's the missing information about signalling
warnings.  Since you don't have anything special to say about warnings
anyway, merge this with the previous section on "Signalling".



Section 5.2
-----------

First paragraph, page 5-24: There are a zillion reasons why it may not
be possible to perform I/O to a device that have nothing to do with
Lisp (device requires special privileges for access, device is full,
device is turned off, somebody just poured coffee into the disk drive,
etc.).  Also I don't know what "external data sources" are treated
"specially", or what "specially" means in this context.  Can't we just
say that this section describes the Lisp interface to the file system
and leave it at that? 


Files, p 5-24

First paragraph:  "the names can be fit into a pathname" => "the
names can be represented by a pathname object".

Second paragraph: "all manipulations of files can be expressed in
machine-independent terms" is wishful thinking.  How about saying
something like "Pathnames provide a means for expressing many
operations which manipulate files or file names in a manner that does
not depend on the specific format of file names on a particular file
system."

Rules concerning file i/o: (eof-error-p and recursive-p):  These two
things have nothing to do with files specifically and only relate to
input, not output.  They really belong in the next section.  Also:

- Why is "form" being used here instead of "function call"?  I tend to
think of "form" as being a more general term for when it might be any
evaluable data object, but here you definitely do know that it is
a function call. 

- I don't think you really want to italicize "top level" in any of the
places where it is used under recursive-p.  In fact, you probably want
to use some other term like "outermost".  I'm guessing that the "top
level" you put in the glossary will be as in "top level form", which
is an entirely different concept. 


Section 5.3
-----------

Top level loop, page 5-27

If this section is called "top level loop", why does it talk only
about a "read-eval-print" loop?  I like "top-level loop" better,
because it's conceivable that you might interact with a Lisp system in
such a way that the reading of forms is entirely separate from
indicating you want them evaluated (for instance, a structured editor
might provide this interface).

I would replace the first paragraph with something like:

  The top-level loop is the mechanism by which one normally interacts
  with the Lisp system.  This is sometimes referred to as a
  "read-eval-print" loop because it typically consists of an endless
  loop that reads an expression, evaluates it, and prints the results. 

Decoded time, page 5-28:  "...as a number of components" => "as a set
of values".  Again, the word "components" conjures up a mental image
of some kind of record structure, which is incorrect here.  I think "set"
has fewer connotations about representation.

Time zone, page 5-29: Probably one of the examples should show the use
of a negative number, like -9 for Japan.  It should be mentioned that
fractional time zones can't be represented (Newfies are out of luck). 


Section 5.4
-----------

Page 5-31: The example at the bottom of the page seems out of place
here.  It logically belongs after the simpler example at the top of
the next page. 

Page 5-33: The caption for the last figure is lost on the next page.

-------

∂05-Mar-89  0259	CL-Editorial-mailer 	comments on various sections of the draft   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 5 Mar 89  02:58:57 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Sun, 5 Mar 89 05:54:18 EST
Received: by kulla.think.com; Sun, 5 Mar 89 05:55:59 EST
Date: Sun, 5 Mar 89 05:55:59 EST
From: barmar@Think.COM
Message-Id: <8903051055.AA23133@kulla.think.com>
To: sandra%defun@cs.utah.edu
Cc: chapman%aitg.dec@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 4 Mar 89 23:20:40 MST <8903050620.AA05294@defun.utah.edu>
Subject: comments on various sections of the draft

    page 2-26, third paragraph: I know this is exactly what CLtL says, but
    I think it's inaccurate.  First of all, the hash table always has a
    "size", not just when it's first created.  Second, it's not the
    maximum number of entries it can hold, it's the maximum it can hold
    without collisions.

The precise meaning of the size depends on the hash table
implementation.  If the hash buckets are lists, then you are right.
If it's implemented as an array with linear probing, it's simply the
maximum number of entries it can hold.

						barmar

∂05-Mar-89  1142	CL-Editorial-mailer 	Definition of `Function'
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


KMP writes:

``Inline functions also make me wonder about this. A function might get
compiled away altogether, leaving no trace of `process' ...''

``Some functions might have been defined by generating an instruction or
instruction stream directly, without ever going through the lisp abstraction.''

It is important when defining concepts to ignore possible implementation
techniques, only the pure concept we have in mind. Some implementations
might implement functions in a special way or have facilities for
optimization, but these should have little to do with the definition of
the term `function'.

KMP comments:

``    - generalization via parameters

Even though some functions take arguments, others do not. As such, the
ability to `take arguments' is not criterial to being a function.''

I believe the classic definition of a function is essentially
``abstraction via parameters.''  In a report for DARPA I wrote with some
other folks, the following definition was supplied by Mitch Wand:

``Abstraction in programming is the process of identifying common patterns
that have systematic variations; an abstraction represents the common
pattern and provides a means for specifying which variation to use.  The
most familiar example of this is procedural or functional abstraction, in
which the common pattern is a computation which varies according to input
values. The abstraction is called a procedure, and is applied by supplying
actual input values.''

			-rpg-

∂05-Mar-89  1604	CL-Editorial-mailer 	Re: What is a FUNCTION? 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Mar 89  16:04:37 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA01379; Sun, 5 Mar 89 17:02:28 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA05584; Sun, 5 Mar 89 10:20:50 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903051720.AA05584@defun.utah.edu>
Date: Sun, 5 Mar 89 10:20:49 MST
Subject: Re: What is a FUNCTION?
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Sat, 4 Mar 89 23:48 EST

I think you misunderstood me.  The passage I quoted was the definition
of what the type FUNCTION means in Common Lisp, that appears in the
"Types" section of the working draft of the standard.  The purpose of
this definition ought to be to explain what makes a FUNCTION object so
unique and interesting that we have created a special type for it.
This has very little to do with inlining of function calls, whether
functions in other programming languages capture the lexical
environment, or some of the other things you mentioned. 

I have actually been looking at some reference books for other
programming languages to see how they define what a function or
procedure is.  Most of them talk only about the syntax for defining
functions and about how you call them, with some mumblage about how
using subprograms makes large programs easier to understand.  So far
the only attempt to define the -concept- of a function I've run across
is from the K&R C book: "A function provides a convenient way to
encapsulate some computation in a black box, which can then be used
without worrying about its innards."

-Sandra
-------

∂05-Mar-89  1624	CL-Editorial-mailer 	Sandra's Comments  
To:   cl-editorial@SAIL.Stanford.EDU  
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


Sandra writes:

``The consensus was that it is very misleading to describe things like the
property list as "components" of a symbol (among other reasons, because it
conjures up possibly inaccurate mental images about the internal
representation of symbols).''

I think the terms `component' and `constituent' are satisfactory as long
as the description of access and alteration of components is sufficiently
abstract. `Associated with' and `attribute' have problems because they
tend to imply a looser connection than does `component'. We had a similar
problem with methods and generic functions where some wanted to simply
associate a method with the name of a generic function while others wanted
to have generic functions be composed of methods (and other things).

The association of the components of a symbol with the symbol is pretty
close since once you make a symbol, it must act as if the components
are attached to it, and breaking the association is done by changing the
associated item, not by removing the association.

One could finesse the whole situation by defining symbols very abstractly:

A symbol is an object that obeys the following:

	(make-symbol <string>) yields a symbol
	(symbol-name (make-symbol <string>)) = <string>

	<followed by the other operations on symbols>

Sandra's rewrite, which seems to be a string-replace of `attribute' for
`component', doesn't appear to alter any false impressions.

By the way, by using the term `component' for CONS cells, do you think
you are implying that a CONS cell is necessarily a vector-like object
whose 0th component is CAR (CDR) and whose 1st component is CDR (CAR)?
I think CONS cells should be treated the same way as symbols.

			-rpg-

∂06-Mar-89  1329	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89  13:28:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551545; Mon 6-Mar-89 16:25:30 EST
Date: Mon, 6 Mar 89 16:25 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-TERMINOLOGY
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: RPG@Lucid.COM, CL-Editorial@SAIL.Stanford.EDU
In-Reply-To: <19890303190851.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890306212512.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 3 Mar 89 14:08 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    I have lingering objections which I consider essential. These have 
    been conveyed previously to Kathy with other comments; she's improved
    the document a lot, but there's still a way to go before I can say
    it is acceptable.
    ....
    Until these issues are dealt with, my personal recommendation to Moon
    will be that Symbolics vote `No with comments' on this issue.

I agree with the general tenor of your comments (for the most part
they point out some things I hadn't noticed when I read Dick's new draft
of the error terminology, such as examples that seem plausible but are
not consistent with Common Lisp as currently defined).  I do not want to
be involved in working out the details.

In any case Symbolics has to vote I on this issue, since the version
that was distributed with the ballot is inadequate.

∂06-Mar-89  1343	CL-Editorial-mailer 	Definition of `Function'
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Mar 89  13:43:19 PST
Received: from fafnir.think.com by Think.COM; Mon, 6 Mar 89 12:36:58 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 6 Mar 89 12:38:32 EST
Received: by verdi.think.com; Mon, 6 Mar 89 12:35:16 EST
Date: Mon, 6 Mar 89 12:35:16 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903061735.AA01842@verdi.think.com>
To: RPG@sail.stanford.edu
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: Dick Gabriel's message of 05 Mar 89  1142 PST <EqpBf@SAIL.Stanford.EDU>
Subject: Definition of `Function'

   Date: 05 Mar 89  1142 PST
   From: Dick Gabriel <RPG@sail.stanford.edu>
   ...
   KMP comments:

   ``    - generalization via parameters

   Even though some functions take arguments, others do not. As such, the
   ability to `take arguments' is not criterial to being a function.''

   I believe the classic definition of a function is essentially
   ``abstraction via parameters.''  ...

Note that the definition of function as abstraction via parameters
is itself an abstraction.  Rather than having separate definitions
of "abstraction with one parameter", "abstraction with two parameters",
"abstraction with two optional and five keyword parameters", and so on,
we can speak simply of "abstraction with n parameters; details at 11:00".
It is then a lovely consequence that n=0 is a useful special case; but
this is hardly a counterexample to the claim that parameters are an
important characteristic of functions in general.

It is good that KMP is carefully criticizing the definition to make
sure it is right.  I happen not to agree with all his positions.

--Guy

∂06-Mar-89  1344	CL-Editorial-mailer 	comments on various sections of the draft   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Mar 89  13:43:50 PST
Received: from fafnir.think.com by Think.COM; Mon, 6 Mar 89 12:21:53 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 6 Mar 89 12:23:29 EST
Received: by verdi.think.com; Mon, 6 Mar 89 12:20:18 EST
Date: Mon, 6 Mar 89 12:20:18 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903061720.AA01692@verdi.think.com>
To: sandra%defun@cs.utah.edu
Cc: chapman%aitg.dec@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 4 Mar 89 23:20:40 MST <8903050620.AA05294@defun.utah.edu>
Subject: comments on various sections of the draft

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Sat, 4 Mar 89 23:20:40 MST
   ...
   Perhaps I'm being chauvinistic here, but I think that the history section
   ought to include a paragraph on Standard Lisp.  After all, it *was* the
   only standard dialect of Lisp in existence before the advent of Common
   Lisp.  How about:

     Meanwhile, researchers at the University of Utah began the first
     efforts towards standardization of Lisp.  The goal was to arrive at a
     minimal common subset of the various Lisp dialects then in existence
     to use as a basis for implementing the REDUCE algebra system.  The
     specification for this subset, known as Standard Lisp, was first
     published in 1969 and revised in 1978.  There followed a compiler (the
     Portable Lisp Compiler) and a full implementation (Portable Standard
     Lisp), which was first released in 1982.

I concur: Standard Lisp and Portable Standard Lisp deserve mention.
While they did not lend many features directly to Common Lisp, they
constituted a valuable existence proff that an effort to define a
Lisp for many machines was feasible.  See CLtL p. 3.
--Guy

∂06-Mar-89  1533	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89  15:33:30 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551705; Mon 6-Mar-89 18:30:22 EST
Date: Mon, 6 Mar 89 18:30 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-TERMINOLOGY
To: chapman%aitg.dec@Decwrl.dec.com
cc: RPG@Lucid.COM, CL-Editorial@SAIL.Stanford.EDU
Message-ID: <890306183018.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

I would like to see the following additional term added:

 MIGHT SIGNAL  means that a particular condition might or might not be
	       signalled. This term is functionally equivalent to 
	       ``is undefined'' but is useful in providing advice to
	       implementors about what condition to signal when an
	       error is to be signalled in an undefined situation.
	       For example, ``OPEN might signal a condition of type
	       FILE-ERROR.''

This term would be useful in some last-minute proposals I'm trying to 
draft to specify what functions signal what kinds of conditions...

∂06-Mar-89  1649	CL-Editorial-mailer 	Issue: ERROR-TERMINOLOGY
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Mar 89  16:49:20 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02685g; Mon, 6 Mar 89 16:41:50 PST
Received: by challenger id AA26505g; Mon, 6 Mar 89 16:37:17 PST
Date: Mon, 6 Mar 89 16:37:17 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903070037.AA26505@challenger>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: chapman%aitg.dec@Decwrl.dec.com, CL-Editorial@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Mon, 6 Mar 89 18:30 EST <890306183018.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-TERMINOLOGY


This is an interesting point. First, let me point out that ``MIGHT
SIGNAL'' (the technical term) means ``might signal'' (the English
phrase). The question becomes whether we need to add this term to the
list of precisely defined terms or whether we could leave the term as
an English phrase that we add to other descriptions.

I think the following description is a little better than the one KMP
suggested (mainly it is shorter):

MIGHT SIGNAL AN ERROR The consequences are undefined, but a particular
               condition might or might not be signalled.  For example, 
               ``OPEN might signal a condition of type FILE-ERROR.''



∂10-Mar-89  1052	CL-Editorial-mailer 	Rational arithmetic
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 10 Mar 89  10:52:20 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA20967; Fri, 10 Mar 89 10:52:23 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA12830; Fri, 10 Mar 89 10:47:41 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA15560; Fri, 10 Mar 89 10:49:27 PST
Date: Fri, 10 Mar 89 10:49:27 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903101849.AA15560@clam.sun.com>
To: chapman%aitg.DEC@decwrl.dec.com
Subject: Rational arithmetic
Cc: cl-editorial@sail.stanford.edu

Hi, I hope this is properly addressed.

In the Dec 6, 1988 draft, p1-12, point 15 appears to be incorrect.
In CLtL, p195 paragraph 2, "if the arguments are all rational, then the
result is rational (except . . . "

Perhaps you simply decided to change the presentation, I don't know.

				-Cris

∂13-Mar-89  0944	CL-Editorial-mailer 	need head count    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Mar 89  09:43:33 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA06054; Mon, 13 Mar 89 03:40:11 PST
Message-Id: <8903131140.AA06054@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for skona%csilvax@hub.ucsb.edu; id AA06054; Mon, 13 Mar 89 03:40:11 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 13 Mar 89 06:39
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: need head count

Please let me know if you plan to attend the Monday night (3/27) editorial
committee meeting.
kc

∂13-Mar-89  2347	CL-Editorial-mailer 	need head count    
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 13 Mar 89  23:47:38 PST
Received: from relay2.cs.net by RELAY.CS.NET id ak07911; 13 Mar 89 23:47 EST
Received: from utokyo-relay by RELAY.CS.NET id ai03712; 13 Mar 89 23:36 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
	id AA04529; Tue, 14 Mar 89 11:22:20 JST
Received: from kepa.cc.aoyama.junet by aoyama.cc.aoyama.junet (4.0/6.4J.BETA2-agu1)
	id AA20772; Tue, 14 Mar 89 09:42:44 JST
Received: by kepa.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA10767; Tue, 14 Mar 89 09:43:09 JST
Date: Tue, 14 Mar 89 09:43:09 JST
From: Masayuki Ida <ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@cc.aoyama.junet>
Message-Id: <8903140043.AA10767@kepa.cc.aoyama.junet>
To: chapman%aitg.DEC@DECWRL.DEC.COM
Cc: cl-editorial@SAIL.STANFORD.EDU, skona%csilvax@HUB.UCSB.EDU
In-Reply-To: chapman%aitg.DEC@DECWRL.DEC.COM's message of 13 Mar 89 06:39 <8903131140.AA06054@decwrl.dec.com>
Subject: need head count

   >>From: chapman%aitg.DEC@DECWRL.DEC.COM
   >>Date: 13 Mar 89 06:39
   >>
   >>Please let me know if you plan to attend the Monday night (3/27) editorial
   >>committee meeting.
   >>
I will.

Masayuki Ida

∂14-Mar-89  0735	CL-Editorial-mailer 	Re: Issue: EXTRA-RETURN-VALUES    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  07:35:31 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 07:24:39 PST
Date: 14 Mar 89 07:24 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXTRA-RETURN-VALUES
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 24 Feb 89 17:35
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu
Message-ID: <890314-072439-22523@Xerox>

Cathy:

I liked my original proposal better than your rewording of it. 

I said:

"Is it OK to return extra values from Common Lisp functions?

No, except where explicitly allowed. 
A function
must return EXACTLY the number of return values specified by the
standard.  Otherwise, an implementation might choose to return trailing
NIL values by not returning those values (since MULTIPLE-VALUE-BIND
would default those values to NIL).
"

i.e., a constraint on conformal implementations.

You said:

"Unless it is explicitly allowed in the standard,
if a standard function
returns a different number of return values from the number
specified by the standard, the results are unspecified.
"

This doesn't make sense to me. We say "the results are unspecified" to
place restrictions on what a conformal program might do. However, the issue
is really one about conformance of implementations. 

In general, when using the phrase

"If situation X occurs, the results are unspecified."


The situation X must refer to a situation in a user-specified program. 

"If a program executes an IF with 17 forms in its body, the results are
unspecified."


The phrase "the results are unspecified" cannot gracefully be used to place
constraints on implementations as readily:

"If CONS returns 3 when the moon is full, the results are unspecified."

∂14-Mar-89  0735	CL-Editorial-mailer 	Re: Issue: UNSOLICITED-MESSAGES   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  07:35:18 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 07:16:45 PST
Date: 14 Mar 89 07:16 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: UNSOLICITED-MESSAGES
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Mon, 13 Mar 89
 13:10 EST
To: Barry Margolin <barmar@Think.COM>
cc: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>,
 chapman%aitg.DEC@decwrl.dec.com, cl-editorial@sail.stanford.edu
line-fold: NO
Message-ID: <890314-071645-22508@Xerox>

I'm not sure why you are talking about LOAD since the proposal attempts
to exclude "progress notes" from those functions such as LOAD that
popularly produce them.

The acceptability of progress notes has a lot to do with the stream that
they are displayed on: *STANDARD-OUTPUT* is not acceptabile. In
addition, "unsolicited" progress notes, even to *TERMINAL-IO*, are
probably a bad idea: if you have an environment where there is more
than one user-visible stream -- e.g., a window system, an implementor
should probably direct "progress notes" to a separate window, such as
a who-line or a scrollable status window or some such; also, good system
engineering would have you not update such messages too frequently,
because it is hard to read & might slow down your system.

Lets do separate out the system engineering issues from the portability
ones. The problem this issue was attempting to address was the one raised
by KMP nearly two years ago, namely:

  "Although there is no standard interface to the garbage collector,
  it is common for there to be a garbage collector in nearly every system.
  In many systems, these do unsolicited typeout which obstructs program
  typeout in unpredictable ways.

  Application programs which do display (especially display which conses)
  need a way of deferring GC warnings that might ruin the display."


.... and the observation that any "solution" should address unsolicited
messages in general and not just those caused by the GC.

I actually had some back mail on the "GC-MESSAGES" issue that I
should have forwarded to CL-editorial and didn't, for which I apologize.


     ----- Begin Forwarded Messages -----

Date: Mon, 14 Nov 88 10:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
References: <870423174645.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        GC-MESSAGES
References:   None
Category:     ENHANCEMENT
Edit history: 23-Apr-87, Version 1 by Pitman
	      14-Nov-88, Version 2 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Although there is no standard interface to the garbage collector,
  it is common for there to be a garbage collector in nearly every system.
  In many systems, these do unsolicited typeout which obstructs program
  typeout in unpredictable ways.

  Application programs which do display (especially display which conses)
  need a way of deferring GC warnings that might ruin the display.

Proposal (GC-MESSAGES:NEW-MACRO)

  Introduce a new macro WITH-GC-STATUS, described as follows:

    WITH-GC-STATUS (&key VERBOSE) &body forms

     Executes the body FORMS sequentially, as if by PROGN, returning the
     value(s) of the last form (or NIL if there were no FORMS).

      If :VERBOSE T is specified in the options list, the implementation
      is encouraged to provide some notice of any GC activity that occurs
      during the execution of the FORMS.
 
      If :VERBOSE NIL is specified in the options list, the implementation
      is discouraged from providing any notice of any GC activity that
      occurs during the execution of FORMS.
 
      If :VERBOSE :DEFAULT is specified (or if a :VERBOSE option is
      not supplied), then the implementation is neither encouraged nor
      discouraged from providing notice about any GC activity that occurs
      during the execution of FORMS.

     Implementations are permitted to extend this form to provide other,
     implementation-specific, GC-related keyword options.

      If :ALLOW-OTHER-KEYS T is specified, any unrecognized options will
      be ignored. For example,

	(WITH-GC-STATUS (:VERBOSE NIL
			 :ACME-GC-OPTION-17 T
			 :ALLOW-OTHER-KEYS T)
	  ...)

      might select GC Option #17 in ACME Common Lisp, but in other Common
      Lisp implementations (where that option presumably would not exist),
      the keyword would be ignored.

      If :ALLOW-OTHER-KEYS NIL is specified (or if the :ALLOW-OTHER-KEYS
      option is not supplied), then an error will be signalled if the
      implementation does not recognize all options in the options list.

Rationale:

  This facility addresses the stated problem in a straightforward way.

Current Practice:

  This functionality is provided in some form or another by a number of
  implementations.

  Zetalisp currently offers SI:GC-REPORT-STREAM which can be set to T, NIL,
  or a stream. It provides useful flexibility and is used by quite a number
  of users.

  Other systems provide ways of enabling or disabling the messages, or of
  customizing the message which is typed out.

Adoption Cost:

  The set of places in which the GC does typeout is probably very 
  restricted, so finding them and changing them to be appropriately
  conditionalized is probably not a lot of work.

Benefits:

  This would allow the user some portable control over a common feature which
  cannot currently be controlled in a portable way.

Conversion Cost:

  This is an upward compatible change.

Aesthetics:

  No significant impact.

Discussion:

  MACSYMA needs this (so it can bind it to NIL). Its display often does
  consing. In some implementations this can cause a GC, which can in turn
  spoil the carefully crafted display.

  Version 1 of this proposal did not fly because it proposed a variable to
  control the behavior, and some people were not convinced that a simple
  variable would be powerful enough in all cases -- some feared a function
  call might be needed to toggle the state. This rewrite addresses those
  concerns.

  Pitman supports this proposal.



     ----- Next Message -----

To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue GC-MESSAGES (Version 2) 
In-reply-to: Your message of Mon, 14 Nov 88 10:13:00 -0500.
             <881114101307.3.KMP@BOBOLINK.SCRC.Symbolics.COM> 
Date: Sun, 20 Nov 88 19:10:53 EST
From: Scott.Fahlman@B.GP.CS.CMU.EDU


Just catching up on old cleanup mail...

If we do want to address the problem of standardizing GC-message typeout, I
prefer the kind of solution that KMP describes for the Symbolics system: a
special variable that directs GC messages to some specified stream, or that
disables them if it is NIL.  The proposed WITH-GC-STATUS macro only lets
you control typeout messages for the things it surrounds; a special
variable would give you global control as well.

-- Scott



     ----- Next Message -----

Date: Fri, 30 Dec 88 19:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881114101307.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

I still think that focussing on GC messages is wrong, and instead there
should be a form that disables unsolicited typeout in general,
regardless of its source.  Of course in some operating systems it might
be impossible to disable some forms of unsolicited typeout, and in other
operating systems unsolicited typeout might not exist (that is,
asynchronous messages might always come out in a separate window).
Thus this facility would just do the best effort appropriate for
the particular implementation.

I think there should be a stream argument, since there might be more
than one possible place for unsolicited typeout.  In other words, 
(WITHOUT-UNSOLICITED-OUTPUT (<stream>) <body>...) means that the output
send by <body> to <stream> should appear as a unit, without other
unsolicited output interspersed with it.

I don't think your :VERBOSE T option to encourage unsolicited typeout
is needed.



     ----- Next Message -----

Date: Fri, 30 Dec 88 19:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 2)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19881231002621.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 30 Dec 88 19:26 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I still think that focussing on GC messages is wrong, and instead there
    should be a form that disables unsolicited typeout in general,
    regardless of its source.  Of course in some operating systems it might
    be impossible to disable some forms of unsolicited typeout, and in other
    operating systems unsolicited typeout might not exist (that is,
    asynchronous messages might always come out in a separate window).
    Thus this facility would just do the best effort appropriate for
    the particular implementation.

    I think there should be a stream argument, since there might be more
    than one possible place for unsolicited typeout.  In other words, 
    (WITHOUT-UNSOLICITED-OUTPUT (<stream>) <body>...) means that the output
    send by <body> to <stream> should appear as a unit, without other
    unsolicited output interspersed with it.

What if the typeout isn't going to a stream? Eg, some implementations might
cheat and do native non-stream-based I/O raw to the terminal during a GC to
avoid the risk of consing. I'm pretty sure I've seen some implementation
do this but I can't remember which.

Also, what if I do
 (WITHOUT-UNSOLICITED-OUTPUT (*TERMINAL-IO*) <body>)
? Does this affect unsolicited output to *STANDARD-OUTPUT*?

Also, what if I do
 (WITHOUT-UNSOLICITED-OUTPUT (*STANDARD-OUTPUT*) <body>)
? Does this affect unsolicited output to *TERMINAL-IO*?

Maybe we'd specify the stream to which unsolicited typeout is supposed to
go to help avoid problems like this. But then why would anyone bother to
use this macro on any other stream.

Without a way to test this property of a stream, no user-created stream
is going to ever respect this form anyway because unsolicited typeout
can't be distinguished from solicited typeout by the low-level printer
routines.

To my way of thinking, the root of this problem is that the system thinks
it is permissible to type on the virtual CL console. Personally, I think
this is a violation of the whole purpose of having stream-based I/O, which
is to keep the output of one program separate from the output of another.
Creating a stream-based abstraction to solve the problem of somebody 
violating the heart of the stream concept does not (without further
justification) seem to me the necessarily best way to proceed.

    I don't think your :VERBOSE T option to encourage unsolicited typeout
    is needed.



     ----- Next Message -----

To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue GC-MESSAGES (Version 2) 
Date: Tue, 03 Jan 89 12:45:14 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    I still think that focussing on GC messages is wrong, and instead there
    should be a form that disables unsolicited typeout in general,
    regardless of its source.  Of course in some operating systems it might
    be impossible to disable some forms of unsolicited typeout, and in other
    operating systems unsolicited typeout might not exist (that is,
    asynchronous messages might always come out in a separate window).
    Thus this facility would just do the best effort appropriate for
    the particular implementation.
    
I agree in general.  I further think that the cleanest way to handle
the problem is by having all such output be signalled.  There is then
a well-defined, portable way for a user to intercept any desired
messages and deal with them in any way.  Now that we have a condition
system, this approach seems much cleaner than another set of ad-hoc
keywords, wrapper forms, functions, etc.

This is the approach I'm pushing for compiler messages in the compiler
committee, but it doesn't seem to be getting very far.



     ----- Next Message -----

Date: Tue, 3 Jan 89 12:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue GC-MESSAGES (Version 2) 
To: Dan L. Pierson <pierson@mist.encore.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8901031738.AA13041@mist.>

    Date: Tue, 03 Jan 89 12:38:44 EST
    From: Dan L. Pierson <pierson@mist.encore.com>

	I still think that focussing on GC messages is wrong, and instead there
	should be a form that disables unsolicited typeout in general,
	regardless of its source.  Of course in some operating systems it might
	be impossible to disable some forms of unsolicited typeout, and in other
	operating systems unsolicited typeout might not exist (that is,
	asynchronous messages might always come out in a separate window).
	Thus this facility would just do the best effort appropriate for
	the particular implementation.
    
    I agree in general.  I further think that the cleanest way to handle
    the problem is by having all such output be signalled.

This can't work for asynchronous, unsolicited typeout.  In a multiprocess
system, the cause of the condition leading to message output may not be
in a "user" process, so signalling in the originating process won't give
the user any control.  Also there may be multiple "user" processes and it
may not be obvious which one should receive the signal.  I shouldn't
have to tell this to someone from Encore, you must have faced all these
issues already!  Also a special form that disables unsolicited typeout
during the dynamic extent of its body could interact with the operating
system to disable or defer operating-system-generated typeout, but in
most operating systems it would be much more difficult to arrange for
the operating system to signal a Lisp condition when it wants to type
something out.

It's too bad it can't work, because it certainly would be cleaner.



     ----- Next Message -----

To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue GC-MESSAGES (Version 2) 
In-Reply-To: Your message of Tue, 03 Jan 89 12:50:00 -0500.
Date: Tue, 03 Jan 89 13:53:40 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    Date: Tue, 3 Jan 89 12:50 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
        Date: Tue, 03 Jan 89 12:38:44 EST
        From: Dan L. Pierson <pierson@mist.encore.com>
    
    	I still think that focussing on GC messages is wrong, and
    	instead there should be a form that disables unsolicited
    	typeout in general, regardless of its source.  Of course in
    	some operating systems it might be impossible to disable some
    	forms of unsolicited typeout, and in other operating systems
    	unsolicited typeout might not exist (that is, asynchronous
    	messages might always come out in a separate window).  Thus
    	this facility would just do the best effort appropriate for
    	the particular implementation.
        
        I agree in general.  I further think that the cleanest way to handle
        the problem is by having all such output be signalled.
    
    This can't work for asynchronous, unsolicited typeout.

Maybe I did tack this on to the wrong message.  GC-MESSAGES may well
have to be a special case, both because they're almost the only truly
asyncronous events that don't invoke a debugger, and because they have
special consing problems as Kent reminded us.  I think that all (or
almost all) other messages can still be treated in one uniform way.

                                                            In a multiprocess
    system, the cause of the condition leading to message output may not be
    in a "user" process, so signalling in the originating process won't give
    the user any control.

Well, the condition system spec doesn't talk about how handlers are or
aren't inherited across processes.  Since handlers are dynamically
scoped, it might be assumed that a process "inherits" all the handers
in existence when it is created.  While this is probably not true in
most (if not all) existing Lisp multiprocessing systems, it's absence
does make it much harder to bullet proof a delivered application.  

In addition, if handlers are inherited, it would be nice for any lisp
system to allow a user to define handlers that will be inherited by
all processes; I realize that this may not be possible for system
processes in a Lisp Machine.

                           Also there may be multiple "user" processes and it
    may not be obvious which one should receive the signal. I shouldn't
    have to tell this to someone from Encore, you must have faced all these
    issues already!

We have, but not in a Lisp context!  In general you can either have a
special signal handling process or let each process do it's best.  It
depends on what the signal and application are trying to do.  A single
signal handing process doesn't scale well, so I wouldn't want to use
it for something like divide by zero execptions (if my code was
prepared to handle those efficiently and I could get them delivered to
the originating process(or)), but that probably doesn't matter for
user interfaces.  On the other hand, scaling doesn't really matter
unless you have several multiple processors.  A Mach approach is to
have one thread with receive rights to a port that gets all errors.

While I'm very concerned about language changes that might make a
parallel lisp harder to create or define, I've been less worried about
user interface issues like this.  All of your hard objections apply
just as much to any error handling (or even invoking the debugger) as
they do to printing a message.  We've adopted a condition system that
doesn't deal with any of these issues because the language standard
doesn't deal with multitasking (e.g. stack groups) at all, let alone
true parallel processing.  If the condition system is going to be
useful to users (and customers), multitasking implementations are
going to have to find answers to many of these problems.  It won't be
easy, but that does that mean that we'd be better off without a
condition system?

                     Also a special form that disables unsolicited typeout
    during the dynamic extent of its body could interact with the operating
    system to disable or defer operating-system-generated typeout, but in
    most operating systems it would be much more difficult to arrange for
    the operating system to signal a Lisp condition when it wants to type
    something out.
    
True, but the stock hardware operating systems I've worked with don't
tend to type things out.  They just signal errors, return a bad status
code, or abort your program.  Of course, linked-in foreign language
code may do such a thing, but that's only a problem for
implementations that use such code themselves.  Any typeout proposal
that we come up with isn't going to control what the user can do to
himself.

    It's too bad it can't work, because it certainly would be cleaner.
    
It can't work for GC-MESSAGES, but does that mean it can't work for
the loader, compiler, etc?  I'm not convinced yet.



     ----- Next Message -----

Date: 9 Jan 89 00:07 PST
From: masinter.pa
Subject: Re: Issue GC-MESSAGES (Version 2) 
In-reply-to: Dan L. Pierson <pierson@mist.encore.com>'s message of Tue, 03
 Jan 89 13:53:40 EST
To: cl-cleanup@sail.stanford.edu

I sent a note to cl-editorial. I had a proposal for "unsolicited messages"
which is handles only those things like auto-load heralds and GC messages.
I think that LOAD and COMPILE progress notices are "solicited", at least by
LOAD. 

Maybe this just subsumes GC-MESSAGES or should be handled under this name?


Issue: UNSOLICITED-MESSAGES
Problem: Is it legal for an implementation to produce unsolicited output,
e.g., GC notifications, autoload heralds, and progress messages from
COMPILE-FILE or LOAD?

Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS

Unsolicited messages, such as GC notifications and autoload heralds, if
they are produced by an implementation, should not be directed to
*standard-output*, *error-output*. If an implementation produces them, they
may be produced on a stream that is not "shared" with any of the streams
that a user might redefine or redirect. (This really means that it is OK to
direct such notifications to *terminal-io* since a user may not redirect
*terminal-io*.)

Messages such as progress reports from LOAD and COMPILE are "solicited",
and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.



     ----- End Forwarded Messages -----

∂15-Mar-89  0854	CL-Editorial-mailer 	Re: Issue: UNSOLICITED-MESSAGES   
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  08:54:26 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via CHAOS with CHAOS-MAIL id 124407; Wed 15-Mar-89 11:41:02 EST
Date: Wed, 15 Mar 89 11:40 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Re: Issue: UNSOLICITED-MESSAGES
To: masinter.pa@xerox.com
cc: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>, chapman%aitg.DEC@decwrl.dec.com,
    cl-editorial@sail.stanford.edu
In-Reply-To: <890314-071645-22508@Xerox>
Message-ID: <19890315164055.7.BARMAR@OCCAM.THINK.COM>

    Date: 14 Mar 89 07:16 PST
    From: masinter.pa@xerox.com

    The acceptability of progress notes has a lot to do with the stream that
    they are displayed on: *STANDARD-OUTPUT* is not acceptabile. In
    addition, "unsolicited" progress notes, even to *TERMINAL-IO*, are
    probably a bad idea: if you have an environment where there is more
    than one user-visible stream -- e.g., a window system, an implementor
    should probably direct "progress notes" to a separate window, such as
    a who-line or a scrollable status window or some such; also, good system
    engineering would have you not update such messages too frequently,
    because it is hard to read & might slow down your system.

Yes, Genera puts these progress notes in the who-line; it is updated
once a second, I believe.  Kent seemed to be saying that the choice of
stream is not the important issue, and that the thing that distinguishes
who-line progress notes is the fact that they are displayed
asynchronously by a background process.

                                                barmar

∂15-Mar-89  1318	CL-Editorial-mailer 	Re: Issue ERROR TERMINOLOGY, dpANS C   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  13:18:05 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA15738; Wed, 15 Mar 89 13:18:12 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA16448; Wed, 15 Mar 89 13:14:17 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA00215; Wed, 15 Mar 89 13:17:51 PST
Date: Wed, 15 Mar 89 13:17:51 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903152117.AA00215@clam.sun.com>
To: chapman@aitg.dec.com, jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: Re: Issue ERROR TERMINOLOGY, dpANS C
Cc: cl-editorial@sail.stanford.edu, kempf@Sun.COM, peck@Sun.COM, rpg@lucid.com

(X3J13 is dropped from the list of addressees)

> Perhaps the problem is that "harmless" is not very well defined.

I'm confident that this is part of the problem.

> Maybe we can convince ourselves that ``the consequences of the garbage
> collector when invoked'' are harmless, but how many other examples can
> we find?

Indeed, there is no way to invoke GC in Common Lisp and with a few
exceptions such as messages, GC must have NO side effects.

> Some things are not immediately harmful but may cause
> trouble later on.

Yes, lots of things are that way.
 
> By ``unpredictable but harmless'', I think we are in effect saying
> ``not completely unpredictable''.  That is, we promise something but
> don't quite say what it is.  For example, Lisp will presumably not
> break off and start playing chess.  But maybe it's harmless to start
> playing chess.

As far as I can see, the only reasonable option is to specify
some range of possible consequences.  The constraints, whatever
they may be, make it possible to reason about what the program
will do.

If we can define some "harmless" side effects, then we can probably
allow some or all Common Lisp functions to have those side effects.

∂15-Mar-89  1339	CL-Editorial-mailer 	Re: Issue: ERROR-TERMINOLOGY 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 Mar 89  13:38:55 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA07806; Wed, 15 Mar 89 13:36:32 PST
Message-Id: <8903152136.AA07806@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA07806; Wed, 15 Mar 89 13:36:32 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 Mar 89 16:32
To: cl-editorial@sail.stanford.edu, kempf@sun.com, peck@sun.com,
        jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk
Subject: Re: Issue: ERROR-TERMINOLOGY

>(X3J13 is dropped from the list of addressees)
I don't think this should be moved back to cl-editorial. The list of 
addressees who are not on cl-editorial is quite long, and I believe
that people on X3J13 should at least be moderately interested in 
monitoring this discussion. Finally, it is extremely important that
this issue be closed or be very close to closing at the March meeting.
Therefore, if there are objections, they should be brought to the
surface now.

∂15-Mar-89  1506	CL-Editorial-mailer 	Re: Issue ERROR TERMINOLOGY, dpANS C   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Mar 89  15:06:13 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa11469; 15 Mar 89 19:24 GMT
Date: Wed, 15 Mar 89 19:21:20 GMT
Message-Id: <2039.8903151921@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue ERROR TERMINOLOGY, dpANS C
To: Cris Perdue <cperdue@sun.com>, chapman <@decwrl.dec.com:chapman@aitg.dec>
Cc: kempf <@sun.com:kempf@clam>, peck <@sun.com:peck@clam>, 
    sgadol <@sun.com:sgadol@clam>, x3j13@sail.stanford.edu, 
    cl-editorial@sail.stanford.edu, rpg <@sail.stanford.edu:rpg@lucid.com>

Perhaps this discussion should be in cl-editorial...

> From: Cris Perdue <cperdue@com.sun>
> The error terminology is OK, except for "consequences
> are unspecified".  That concept is broken, though it
> has serious defenders.  For example, Dick Gabriel says,
> 
>   "If we were to drop this term, then every time we are
>   ``explicitly vague'' a valid possibility is that a fatal
>   error can occur.  How is it any better to say that what happens
>   when some operation happens is ``explicitly vague''."

Perhaps the problem is that "harmless" is not very well defined.
Maybe we can convince ourselves that ``the consequences of the garbage
collector when invoked'' are harmless, but how many other examples can
we find?  Some things are not immediately harmful but may cause
trouble later on.  For example, are the consequences of using EQ to
compare numbers harmless?  Suppose we know that a fatal error will not
immediately occur.  Is that enough to make it harmless (in this case)?
[I know this is most likely to be a case where the ``return values are
unspecified'', but it was the best I could do on short notice, and we
can ask whether these consequences would be ``harmless'' even if they
wouldn't be described as such in the standard.]

By ``unpredictable but harmless'', I think we are in effect saying
``not completely unpredictable''.  That is, we promise something but
don't quite say what it is.  For example, Lisp will presumably not
break off and start playing chess.  But maybe it's harmless to start
playing chess.

> A typical area of "explicit vagueness" is the destructive operations
> on lists.  The explicit vagueness here is quite limited.  For
> some operations any top level cell of certain lists may or may
> not be modified.  Similar statements apply to other operations.
> The consequences are far from being unspecified but harmless.
> They are CONSTRAINED but meaningful.

This is an interesting example.  First, there's the question ``the
consequences of what?''  The consequences of applying the destructive
operation?  The consequences of doing anything that depends on whether
or not cells were modified?  We really have to see how these phrases
are used in the actual description of a function.

Maybe what we want is this:
The result is a list with certain (specified) properties.
The side effects on cells in the argument list are unspecified.

In addition, there might be a general warning that the consequences of
depending on unspecified side effects are undefined.

In an earlier message, Cris Perdue said:

   Let's pick a few actual examples where the language definition is
   proposed to say "consequences are unspecified".  (Go ahead, I
   challenge you.)  I think we will find that the description will
   have to be more specific than that.  It can make sense to say that
   "effect X may or may not occur".  It can make sense to say that
   "data structure Y may be modified arbitrarily".  If we can define a
   set of effects that we consider harmless, and change "unpredictable
   but harmless" to just "harmless", or some such, that could also
   make sense, but not the current language.

I am not quite convinced by this argument.  We have to be careful not
to make too much undefined.  If we consider some operation, some
things may be specified, some things left open, and so on.  The
description may have to be ``more specific'' in that we shouldn't
describe the whole thing as ``unspecified'' when we can instead say
something more precise; but that doesn't show that some parts of the
description cannot reasonably use ``unspecified'' or ``undefined''.

Besides, this argument applies just as well to ``undefined'' as it
does to ``unspecified'' -- there would be the same need to be more
specific.  So again I suspect it is the ``harmless'' that is really at
fault.

Anyway, the draft C standard makes a somewhat different distinction
between ``unspecified'' and ``undefined''.  In particular, correct
programs may have unspecified behavior; those with undefined behavior
are incorrect, or at least nonportable:

  Unspecified behavior -- behavior, for a correct program construct
  and correct data, for which the Standard imposes no requirements.

  Undefined behavior -- behavior, upon use of a nonportable or
  erroneous program construct, of erroneous data, or of
  indeterminately-values objects, for which the Standard imposes no
  requirements.  Permissible undefined behavior ranges from ignoring
  the situation completely with unpredictable results, to behaving
  during translation or program execution in a documented manner
  characteristic of the environment (with or without the issuance of a
  diagnostic message), to terminating translation or execution (with
  the issuance of a diagnostic message).

There is also a category of ``implementation-defined behavior".

An example: in a function call if the argument types or the number of
arguments are wrong [this is said more precisely in the standard]
``the behavior is undefined''.  However:  ``The order of evaluation of
the function designator, the arguments, and subexpressions within the
arguments is unspecified, but there is a sequence point before the
actual call."

The Rationale (a separate document) says:

  The terms unspecified behavior, undefined behavior, and
  implementation-defined behavior are used to categorize the result of
  writing programs whose properties the Standard does not, or cannot,
  completely describe.  The goal of adopting this categorization is to
  allow a certain variety among implementations which permits quality
  of implementation to be an active force in the marketplace, as well
  as to allow certain popular extensions, without removing the cachet
  of conformance to the standard.  An appendix to the standard, A.6,
  catalogs those behaviors that fall into one of these three
  categories.

  Unspecified behavior gives the implementor some latitude in
  translating programs.  This latitude does not extend so far as
  failing to translate the program.

  Undefined behavior gives the implementor license not to catch
  certain program errors that are difficult to diagnose.  It also
  identifies areas of possible conforming language extension: the
  implementor may augment the language by providing a definition of
  the officially undefined behavior.

From all this I conclude that we probably do need both unspecified and
undefined.  However, it is unclear exactly what distinction they
should express.

[The C standard also distinguishes between strictly conforming [more or
less: portable] programs and conforming programs.]

-- Jeff

∂16-Mar-89  0957	X3J13-mailer 	Re: Issue ERROR TERMINOLOGY, dpANS C
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  09:57:06 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via CHAOS with CHAOS-MAIL id 124431; Wed 15-Mar-89 19:28:46 EST
Date: Wed, 15 Mar 89 19:28 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Re: Issue ERROR TERMINOLOGY, dpANS C
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: Cris Perdue <cperdue@sun.com>, chapman <@decwrl.dec.com:chapman@aitg.dec>,
    kempf <@sun.com:kempf@clam>, peck <@sun.com:peck@clam>, sgadol <@sun.com:sgadol@clam>,
    x3j13@sail.stanford.edu, cl-editorial@sail.stanford.edu, rpg <@sail.stanford.edu:rpg@lucid.com>
In-Reply-To: <2039.8903151921@subnode.aiai.ed.ac.uk>
Message-ID: <19890316002837.0.BARMAR@OCCAM.THINK.COM>

A while back I proposed (to the Editorial committee) a definition of
"harmless" that I still like: Equivalent to an arbitrary conforming
program.  The point of this definition is to say that the consequences
of the situation are undefined, but it can't do anything that a valid
program can't do (if we had a denotational semantics, or a virtual
machine specification as I believe the C standard does, we could
probably use that to specify this).  For instance, it won't result in
pointers to unallocated data being stored in the application's data, or
changing components of function objects.  Undefined consequences would
allow such things, and they can result in secondary effects such as
crashing the system or the process dumping core.  Note that my
definition includes signaling an error among the harmless consequences.

Yes, this definition allows such situations to result in playing chess,
and if the computer is controlling a bomb silo it could also result in
starting World War III.  I don't think a general definition of
"unspecified" can possibly disallow these things.  We might want to
rethink the applicability of the word "harmless" in this case.  I think
market forces are adequate to guarantee that the actual results in any
particular implementation will be reasonable, and we won't have
computers all over the country playing chess when you ask them to CONS.

By the way, I've decided that the "consequences of the garbage collector
are unspecified" example is totally bogus.  The garbage collector is
completely transparent to a Common Lisp program.  The usual
counterargument (which I used to give) is that GC usually changes the
output of the ROOM function, but so can CONS, MAKE-ARRAY, etc.; the
language doesn't even guarantee that (PROGN (ROOM) (ROOM)) will print
the same output twice (it probably won't if ROOM conses).  It can also
be argued that GC can be detected by noticing how long operations take,
but on time-sharing systems there are other reasons why an operation may
take a long time.  GC may reorder the elements in a hash table, but we
never guarantee that MAPHASH of a hash table will consistently process
the elements in the same order, and SETF of GETHASH may also rehash the
table.  I challenge someone to write a conforming Common Lisp program
GC-P that takes as an argument a function, applies the function, and
returns a boolean result indicating whether a GC occurred during the
function execution.

If we can't come up with another example of an unspecified situation,
perhaps we should just throw out the term and stop fighting about it.

                                                barmar

∂16-Mar-89  1051	X3J13-mailer 	Re: Issue ERROR TERMINOLOGY, dpANS C     
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89  10:51:31 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA06620; Thu, 16 Mar 89 13:49:18 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA07280; Thu, 16 Mar 89 13:47:38 EST
Message-Id: <8903161847.AA07280@mist.>
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
Cc: x3j13@sail.stanford.edu, cl-editorial@sail.stanford.edu
Subject: Re: Issue ERROR TERMINOLOGY, dpANS C 
In-Reply-To: Your message of Wed, 15 Mar 89 19:28:00 -0500.
             <19890316002837.0.BARMAR@OCCAM.THINK.COM> 
Date: Thu, 16 Mar 89 13:47:36 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    Date: Wed, 15 Mar 89 19:28 EST
    From: Barry Margolin <barmar@FAFNIR.THINK.COM>
    
    A while back I proposed (to the Editorial committee) a definition of
    "harmless" that I still like: Equivalent to an arbitrary conforming
    program.  The point of this definition is to say that the consequences
    of the situation are undefined, but it can't do anything that a valid
    program can't do (if we had a denotational semantics, or a virtual
    machine specification as I believe the C standard does, we could
    probably use that to specify this).  For instance, it won't result in
    pointers to unallocated data being stored in the application's data, or
    changing components of function objects.  Undefined consequences would
    allow such things, and they can result in secondary effects such as
    crashing the system or the process dumping core.  Note that my
    definition includes signaling an error among the harmless consequences.
    
I like this idea.

∂16-Mar-89  1146	X3J13-mailer 	Issue ERROR TERMINOLOGY, dpANS C    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  11:44:03 PST
Received: from fafnir.think.com by Think.COM; Thu, 16 Mar 89 14:40:15 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 16 Mar 89 14:41:04 EST
Received: by verdi.think.com; Thu, 16 Mar 89 14:37:31 EST
Date: Thu, 16 Mar 89 14:37:31 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903161937.AA05048@verdi.think.com>
To: barmar@Think.COM
Cc: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, cperdue@sun.com,
        @decwrl.dec.com:chapman@aitg.dec, @sun.com:kempf@clam,
        @sun.com:peck@clam, @sun.com:sgadol@clam, x3j13@sail.stanford.edu,
        cl-editorial@sail.stanford.edu, @sail.stanford.edu:rpg@lucid.com
In-Reply-To: Barry Margolin's message of Wed, 15 Mar 89 19:28 EST <19890316002837.0.BARMAR@OCCAM.THINK.COM>
Subject: Issue ERROR TERMINOLOGY, dpANS C

   Date: Wed, 15 Mar 89 19:28 EST
   From: Barry Margolin <barmar@Think.COM>

   A while back I proposed (to the Editorial committee) a definition of
   "harmless" that I still like: Equivalent to an arbitrary conforming
   program ...
   Yes, this definition allows such situations to result in playing chess,
   and if the computer is controlling a bomb silo it could also result in
   starting World War III.  I don't think a general definition of
   "unspecified" can possibly disallow these things.  We might want to
   rethink the applicability of the word "harmless" in this case....

How about renaming "harmless" to be "arbitrary"?
--Guy

∂16-Mar-89  1436	X3J13-mailer 	Fatal vesus Harmless 
To:   x3j13@SAIL.Stanford.EDU
CC:   cl-editorial@SAIL.Stanford.EDU 
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


This is my last attempt at making my argument. I don't think there is much
else I can say to persuade you.

I wrote:

``The definition of fatal puts no time constraints on the fatality. Therefore,
neither does its negation.''

Let's define the term ``win'' to mean ``doesn't crash or abnormally
terminate''; basically, it is the bad case that the definition of
``fatal'' talks about.  Let ``lose'' mean ``not win.''

Here are two partially formal definitions of ``fatal'' and ``harmless.''

The program P has consequences that are fatal if there
exists a sequence of conforming programs, P1,...,Pj,Pj+1,...,Pn, where
(progn P1...Pn) wins, but (progn P1...Pj P Pj+1...Pn) loses.

That is, the execution of P eventually leads to fatality in some program.

The program P has consequences that are harmless if
for all sequences of conforming programs, P1,...,Pj,Pj+1,...,Pn, where
(progn P1...Pn) wins, (progn P1...Pj P Pj+1...Pn) also wins.

That is, the execution of P never leads to fatality in any program.

There might be an infinite amount of hair to make this precise, but that's
the idea.  And, there is some question about how different we allow the
behavior of the programs with P to be from the behavior of the programs
without P.  (The language of the definitions of these terms are meant to
warn people to beware that behavior is in jeopardy.)  But, the terms are
related by a negation with respect to the degree to which they are
well-defined.

I think part of the problem of understanding comes from the question of
side effects noticeable to conforming programs. A program with harmless
consequences can have side effects; notice our partly formal definition
doesn't say anything about what the programs do.

We all believe harmless a garbage collector that moves objects from place
to place where the movement is unnoticeable by conforming programs. Probably
most of us believe harmless a garbage collector whose progress is displayed.

I think none of us believes harmless a garbage collector that sets to
NIL all property lists of symbols in the USER package.

I think most of use believe harmful a garbage collector that changes the
order of properties on property lists.

However, consider an implementation of Common Lisp that uses a very hairy
representation for property-list lists. These lists have the feature that
sometimes the garbage collector will re-order their properties according
to some LRU bits to aid performance. Of course, through extreme hair, the
GC won't change the order if some piece of the property list is stored
somewhere other than the property list itself. Think of it as an
optimization that is conservatively performed.

Nowhere does the CL specification state that the order of properties
remains constant if the property list is not explicitly altered.  Do those
of us who believed harmful the GC that changed property list order believe
this GC harmful? Or did some of us change our votes?

Suppose we alter the definition of symbol-plist from this:

``This returns *the* list the contains the property pairs of <symbol>;
the contents of the property-list cell are *extracted* and returned.''

to this:

``This returns *a* list the contains the property pairs of <symbol>;
the contents of the property-list cell are *copied* and returned.''

Now does the order-changing GC seem more harmless? It certainly has
less transparent behavior.

Suppose we explicitly specified that the order of properties on a property
list could change from time to time, possibly by GC actions. We have
defined the GC to be non-transparent, but is it harmless?

The sense of the definitions come from the partially formal definitions.
I think these definitions are pesuasive regarding the usefulness of a
term like ``harmless.''

I believe those definitions are difficult to make formal without some
very detailed computational or semantic model. The series of strange
GC behaviors with respect to property lists should make us leery of
making these definitions too precise at the expense of deciding these
cases one way when in five years we will wish we could decide them
the other way.

Specifications such as the one we are writing are communications
among people, and therefore absolute precision is impossible without
overspecification.

			-rpg-

∂16-Mar-89  2103	CL-Editorial-mailer 	Re: Issue: EXTRA-RETURN-VALUES    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  21:03:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 21:01:00 PST
Date: 16 Mar 89 20:59 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXTRA-RETURN-VALUES
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 16 Mar 89 03:24
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-editorial@sail.stanford.edu
Message-ID: <890316-210100-6700@Xerox>

I'd go along with Moon's changes. You'd need to get the list of I/O
functions excepted. I'm happy having even a large number of exceptions, as
long as they are identified.

∂16-Mar-89  2149	CL-Editorial-mailer 	Re: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  21:49:11 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 21:34:40 PST
Date: 16 Mar 89 21:32 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 9 Mar 89 17:02 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Message-ID: <890316-213440-6743@Xerox>


You say that "Implementors
  will have to provide a candidate list of exceptions to the editorial
  committee." strikes you as a lot of extra work.

How much harder is it to determine what functions have
more optional arguments than specified than it is to
determine what functions return more multiple values?

As to whether this aids in portability, I think the fact
that some implementations extend CL functions to take
extra arguments has been claimed -- by many users -- to
be a source of frustration for people trying to port
CL programs from one implementation to another. They don't
blame the lack of good tools, but rather the fact that
the extensions were done in a way that made it difficult
to tell, from reading the source code, that an extension
was being used.

Use of extensions that are in a different package, that use
different symbols, or even are introduced by named
parameters, are easy to identify; use of those that are introduced
by extra optional arguments or extensions to the range
of values acceptable to a LISP function are hard to
identify.

We need to have some policy on extensions, even if
it is silence. Do we want to 'close off' some classes
of extensions "except where explicitly allowed" or not?
I think it does aid portability, significantly. However,
this may well be an area where implementation flexibility
is more important.

∂17-Mar-89  0909	CL-Editorial-mailer 	Re: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  09:09:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559548; Fri 17-Mar-89 12:06:17 EST
Date: Fri, 17 Mar 89 12:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)
To: masinter.pa@Xerox.COM
cc: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <890316-213440-6743@Xerox>
Message-ID: <19890317170619.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 16 Mar 89 21:32 PST
    From: masinter.pa@Xerox.COM

    You say that "Implementors
      will have to provide a candidate list of exceptions to the editorial
      committee." strikes you as a lot of extra work.

    How much harder is it to determine what functions have
    more optional arguments than specified than it is to
    determine what functions return more multiple values?

I think it's harder because optional and keyword arguments are much more
heavily used than multiple values.  I also think that the work is less
worthwhile for arguments than for values, because the language includes
number-of-arguments checking (probably only in safe code) but explicitly
forbids number-of-values checking.

It may be that I am wrong, and that the right approach is to divide all
functions into two categories: "language" functions (like CONS and
FLOOR) and "environment" functions (like COMPILE and READ-LINE), and say
that "language" functions can't be extended with either arguments or
values, while "environment" functions can be extended both ways.  I
haven't yet thought through the implications of this idea.

It occurs to me that it may not be obvious why I think it's a good idea
to extend "environment" functions.  Take the case of WRITE.  Symbolics
Genera has some more printer control variables than Common Lisp
specifies, partly because it has more data types, in general because
there are more things to control.  There are two ways we could have
implemented this: we could have said that there are two versions of
WRITE, the "compatible" version and the "extended" version, where only
the "extended" version accepts the extra keyword arguments.  This would
have meant that every programmer would have to think about which version
they wanted, based on which features they were using.  You might think
that this would mean that people would always have portability on their
mind, and that that would be good.  But I think in practice they would
almost always use the "extended" version even if they weren't sure they
needed it, and the "compatible" version would just look like a useless
wart.  This would only decrease portability because there would be an
unnecessarily large number of references to the non-portable "extended"
version.  Furthermore, some programs pass around lists of WRITE options,
and if there were two versions of WRITE, they would have to know which
version to apply to these lists.  The essential issue here is whether
implementation-dependent extensions should be done in the style and
vocabulary of Common Lisp, so that the extended language is a consistent
and easy to learn language, or whether extensions should be warts on the
side, which makes the use of extensions easier to notice, but makes the
extended language a bad language.

    As to whether this aids in portability, I think the fact
    that some implementations extend CL functions to take
    extra arguments has been claimed -- by many users -- to
    be a source of frustration for people trying to port
    CL programs from one implementation to another. They don't
    blame the lack of good tools, but rather the fact that
    the extensions were done in a way that made it difficult
    to tell, from reading the source code, that an extension
    was being used.

Then they suffer from a lack of imagination.  They -should- blame the
lack of good tools.  Surely there can be better tools than eyeballing
the source code looking for things that might be problems.  In fact
there are better tools today, but not everyone uses them.

    Use of extensions that are in a different package, that use
    different symbols, or even are introduced by named
    parameters, are easy to identify; use of those that are introduced
    by extra optional arguments or extensions to the range
    of values acceptable to a LISP function are hard to
    identify.

Don't mix up extra optional arguments with extensions to the range of
valid argument values.  Use of the former is easily detected by local
lexical examination, except when APPLY or FUNCALL is used.  Detecting
use of the latter requires flow analysis and type propagation.

    We need to have some policy on extensions, even if
    it is silence. Do we want to 'close off' some classes
    of extensions "except where explicitly allowed" or not?
    I think it does aid portability, significantly. However,
    this may well be an area where implementation flexibility
    is more important.

My belief, which perhaps not everyone shares, is that not all tools for
portability have to be part of the Common Lisp language, and furthermore
that not all techniques for managing programmer teams have to be part of
the Common Lisp language.  Another way of saying the second thing is
that attempting to make it humanly impossible to write a non-portable
program in Common Lisp is unlikely to succeed, so efforts in that
direction are suspect unless they have a direct advantage of benefits
over costs.  I also think it is very much more important to resolve
ambiguities and disagreements in the standard language that is a subset
of everyone's implementation, than to try to make laws about the
non-standard parts of everyone's implementations.  After we finish the
first task is soon enough to start devoting attention to the second
task.

∂17-Mar-89  1110	CL-Editorial-mailer 	Re: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  11:10:08 PST
Received: from Salvador.ms by ArpaGateway.ms ; 17 MAR 89 11:00:08 PST
Date: 17 Mar 89 10:59 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Fri, 17 Mar 89 12:06 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, cl-editorial@sail.stanford.edu,
 skona%csilvax@hub.ucsb.edu
Message-ID: <890317-110008-1401@Xerox>

This is a double negative, but I don't disagree with you.  I like your
arguments.

In fact, what you said at the beginning of the message was what I had in
mind:
divide the functions into two sets: (L) "functions that can't be extended
with either arguments or values" and (E) "functions that can be extended
both ways". 

One way to achieve such a division is to say that "L = every function
except those that anybody wants to put into E." and to designate this in
the manual by saying "No functions can be extended, except those that
explicitly say they're E." and then put an E marker. I thought this was a
good idea because I thought L would be much bigger than E, even if we
pooled everyone's candidates for E. If you think that E is much bigger than
L, then this is a bad idea.

A more subtle division would to be to create a third class "LE" of
"functions that can be extended by adding arguments in particular ways" and
marking them individually: &ALLOW-OTHER-KEYS and &REST IGNORE. Probably
WRITE and OPEN would fit into LE rather than E. We'd mark them just by
adding those keywords in the appropriate pages of the reference.  


This is RPG's argument with respect to the EXTRA-SYNTAX issue; of course
the issues are all related and the decisions made should be consistent.

∂17-Mar-89  2242	CL-Editorial-mailer 	editorial committee meeting, 3/27 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 17 Mar 89  22:42:37 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA29531; Fri, 17 Mar 89 13:03:25 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA29531; Fri, 17 Mar 89 13:03:25 PST
Message-Id: <8903172103.AA29531@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for sandra%defun@cs.utah.edu; id AA29531; Fri, 17 Mar 89 13:03:25 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 17 Mar 89 15:31
To: cl-editorial@sail.stanford.edu, sandra%defun@cs.utah.edu
Subject: editorial committee meeting, 3/27

Following is the location of the editorial committee meeting. Bob 
has arranged for a private meeting room for us.

A proposed agenda for our meeting will be sent next week, but
please feel free to suggest items that we should discuss.

 
6:30pm, Monday, 3/27
Topkai
3529 Chainbridge Road
 
>From the hotel, take 
66 east => Chainbridge Rd. (first exit) south towards Fairfax
Chainbridge => Eaton Place (first stop light) turn left
Eaton Place => take an immediate left onto service road parallel to Chainbridge
You'll see the restaurant from here


See you there.
kc

∂20-Mar-89  1229	X3J13-mailer 	Re:  Fatal vesus Harmless 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89  12:29:29 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA03785; Mon, 20 Mar 89 12:01:45 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA18569; Mon, 20 Mar 89 11:57:53 PST
Received: by clam.sun.com (4.0/SMI-4.0)
	id AA02722; Mon, 20 Mar 89 12:01:32 PST
Date: Mon, 20 Mar 89 12:01:32 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903202001.AA02722@clam.sun.com>
To: RPG@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
Subject: Re:  Fatal vesus Harmless
Cc: cl-editorial@SAIL.Stanford.EDU

Dick Gabriel's discussion of fatal versus harmless made sense
to me.  I'm going to propose here that within that framework
it can make sense to PERMIT certain SPECIFIED side effects.
I still say that "unspecified by harmless" loses.

To paraphrase, a program P "has fatal consequences"
exactly if it can be preceded and followed by conforming code
so that the entire sequence including P may "crash or abnormally
terminate".

The key question remaining in my mind is what side effects
can be considered harmless.  Dick mentioned a property-list-like
data structure.  Let's talk about hash tables and MAPHASH.
Specifically let's talk about the result of

(let ((result (list)))
  (maphash #'(lambda (key value) (push (list key value) result))
           table)
  result)
  
The order of the result of this expression is unspecified for a
given hash table at a given time, but the set of key-value pairs
is specified.

Is it OK for CONS to cause the order of this list to change?  Is it
OK for CAR to cause it to change?

Since we are trying to discuss harmless side effects, suppose we wish
to allow GC to rehash, possibly changing the order.  The answer must
be that CONS can change the list, because it may invoke the GC.

Since we don't specify what operations can allocate storage, it
appears that we will prefer to say that any operation at all
is permitted to change the value of the example expression above.

In either case, we have no "unspecified but harmless" side
effect of some particular Common Lisp operation.  We have a
particular class of side effects that are PERMITTED
in certain circumstances.  We may choose to specify that
certain classes of side effects are ALWAYS permitted.

We may say that certain side effects are permitted -- to certain
operations.  Suppose we wish to permit certain Common Lisp operations
to issue progress messages, but *not* to consider progress messages as
side effects permitted for all Common Lisp operations.  In
that case it appears to me that we specify that certain operations may
issue progress messages.

While agreeing with Dick Gabriel's recent note, nowhere do I see
the concept "unspecified by harmless" as useful to the definition
of Common Lisp.  Some side effects may be PERMITTED.  Some may even
be permitted to ALL COMMON LISP OPERATIONS.  These are specified
effects, not unspecified effects, and "permitted" I think conveys
the concept much more clearly than "harmless".

∂22-Mar-89  1309	CL-Editorial-mailer 	Please ignore this if you ARE attending the edit comm mtg on 3/27    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 22 Mar 89  13:09:09 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA22035; Wed, 22 Mar 89 13:08:13 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA22035; Wed, 22 Mar 89 13:08:13 PST
Message-Id: <8903222108.AA22035@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA22035; Wed, 22 Mar 89 13:08:13 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 22 Mar 89 16:07
To: cl-editorial@sail.stanford.edu, @SKONA@decwrl.dec.com
Subject: Please ignore this if you ARE attending the edit comm mtg on 3/27

Please comment on this agenda before 3/24 so I can give your comments
to the people at the meeting.
kc





               Agenda for Editorial Subcommittee Meeting (3/27)

           The major topics of our discussion at this meeting will be as
      follows:

      1.  Strategy for completing the standard.

      2.  Revising the issues and sections that will be voted on at  the
          meeting  so  that  we  all  support them and will insure their
          passage.

      3.  Size reduction study.

      4.  Letter ballot summary.

      5.  Contents and format of appendices to the standard.


           I propose we tackle the easier problems  and  status  reports
      first  to  get them out of the way, and spend the rest of the time
      on the longer and more difficult problems.  (Time is start time of
      discussion.)

          Letter ballot summary; who voted how and what the votes  mean.
          7:00

          Size reduction study; what I've done so far, what needs to  be
          done.  7:10

          Contents and format of appendices; suggestions received  as  a
          result  of  the  letter  ballot,  and  by Dick Waters and Cris
          Perdue.  7:25

          Issue categorization and revision; report on the  issues  that
          appeared  to  pass with amendments in the letter ballot; study
          latest copies of  issues  that  have  recently  been  revised;
          decide  which  issues  to present for vote, how they should be
          presented, and who should present them.  7:35

          Section categorization and revision; report  on  the  sections
          that  appeared  to  pass with amendments in the letter ballot;
          present revised versions of the sections that  didn't  pass  and
          decide  on  what  to  do  with  them;  decide  what to do with
          sections that are to be presented for  vote  at  the  meeting.
          8:05

          *****Preparing to finish:***** (If we have not gotten to  this
          item  by  9:00,  we  will skip over the other items and tackle
          this one.) The items still missing from the  standard  are  as
!
                                                                Page 2


          follows:   some  January  and  all March and later issues, the
          character proposal, items that will appear in  the  appendices
          (including   MOP   protocol,   Series,   Iterators/Generators,
          anything  extracted  from  the   standard   that   is   deemed
          non-essential, i.e.  examples, notes...  what else?).  Analyze
          the current strategy of letter balloting; suggest better  ways
          to  get  consensus  on  such a large document; decide what our
          approach will  be,  who  will  present  the  approach  to  the
          committee,  how  we will get buy-in from others not present at
          the edit meeting.  9:00


           Please feel free to suggest other agenda items now and I will
      rework the times to make sure the important topics are covered.

∂03-Apr-89  1251	CL-Editorial-mailer 	comments on material for April ballot  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Apr 89  12:51:07 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA19529; Mon, 3 Apr 89 13:51:04 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA18380; Mon, 3 Apr 89 13:50:59 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904031950.AA18380@defun.utah.edu>
Date: Mon, 3 Apr 89 13:50:58 MDT
Subject: comments on material for April ballot
To: chapman%aitg.dec@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu

Here's a bunch of comments on the material that was distributed at
last week's meeting.  I didn't do a real thorough job of reviewing
everything and I might have more to say after it's been through
another round of editing.

Kathy, let me know if you want me to help with rewriting anything.


Sections 3.1 & 3.2
------------------

I don't understand why this material has been broken up into two
sections.  In particular, it seems like the material in section 3.2
that describes the character syntax belongs before the presentation of
the reader algorithm at the beginning of section 3.1, and I don't see
what it has to do with "Object Syntax".

I'd suggest reorganizing all of this material into the following order:

  - character syntax
  - reader algorithm
  - interpretation of tokens (symbol/number syntax)
  - standard macro characters

Specific comments:

Page 3-9, first paragraph:  This entire paragraph probably ought to be
  rewritten since it doesn't do a very good job of introducing the 
  material now in this section and won't make any sense at all if things
  are reorganized.  One particular gripe: instead of talking about
  tokens "being" numbers or symbols, let's talk about them "representing"
  or "being interpreted as" numbers or symbols.

Page 3-9, Reader algorithm:  I wonder if a state diagram might be useful
  here.  If I have time I'll see whether I can put something together.

Page 3-10, item 10:  "an error is signalled".  Interesting -- CLtL
  contradicts itself on this issue.  On p. 338 it says "signal an error"
  but the top of page 341 effectively says "consequences are unspecified".
  Do we need a cleanup issue to resolve this?

Page 3-10, last sentence:  This doesn't make sense.  Whitespace, macro, and
  escape characters can only appear in extended tokens if they have been
  escaped.  When a character is escaped, it is always treated as an
  alphabetic character.  See CltL page 339.

Page 3-11, right after figure 3-1:  "legal" => "valid"

Page 3-11, under Rational:  I believe this section would make more sense
  if it talked about integers and ratios separately.  Also, the business
  about using a radix specifier doesn't really seem to belong here.  How
  about:

    Integers may be written as a sequence of digits, optionally
    preceeded by a sign and optionally followed by a decimal point.

    Ratios may be written as an optional sign followed by two
    non-empty sequences of digits separated by a /.

Page 3-12, first sentence:  "are" => "may be".

Page 3-12, midway down the page: "satisfies the following" => "satisfies
  all of the following".

Page 3-13, figures 3-3, 3-4, 3-5:  The captions on these figures should
  make it more clear that these are only examples.

Page 3-13, first paragraph under Symbols as tokens: "occurs in a
  dotted-list, then no error is signalled".  What happens instead?
  How about replacing this with:

    appears in a situation where dotted list notation is valid, then
    it is accepted as part of such syntax and no error is signalled.

Page 3-14, first paragraph:  Delete all but the first sentence.  This
  material belongs in the section on packages.

Page 3-15, following figure 3-7:  "where nnnnn...." belongs in the 
  caption to the figure.

Page 3-15, in rule 2:  Delete "#:bar ...." to the end of the paragraph.
  This is covered under the #: dispatching macro.

Page 3-15, in rule 4:  "number syntax" => "potential number syntax".
  "in the default package, the value of *package*" => "in the package
  that is the value of *package*".

Page 3-15, in rule 5:  "it is an error" => "unspecified"???

Page 3-16:  "These rules are true regardless of any implicit interning".
  I can't figure out what this means.  Also, "the current package" =>
  "the value of *package*", and "*package*" => "the value of *package*".

Page 3-16, under macro character collection:  Delete the first paragraph.
  (It doesn't add anything.)

Page 3-16, next paragraph:  Add to end
    The function may either return a value (the object whose printed 
    representation was the macro character and any following characters
    read by the function), or no values to indicate that the macro 
    character and whatever it may have read contribute nothing to the 
    object being read.

Page 3-16, bottom of page:  I don't think this example adds anything.
  Delete it.

Page 3-17 "not immediately preceded by an escape character":  change the
  commas to parentheses.

Page 3-17, example about midway down the page:  ZNETS and WOLQ-ZORBITAN
  are likely to confuse non-native English speakers who don't realize 
  that these are just nonsense names.  Either use something more obvious
  or delete this entirely.

Page 3-17, under ):  what does "invalid" mean in the new error 
  terminology?

Page 3-17, under ":  Hmmm.  Here's another place where CLtL contradicts
  itself (page 30 vs. page 347).  I think page 347 (what you have here)
  is probably correct.

Page 3-18, "With the exception...":  Delete this paragraph.  It adds 
  nothing and is only confusing.

Page 3-18, towards the bottom of the page:  "at-sign" => "at-sign (@)".

Page 3-19, under ",":  "invalid" => ???

Page 3-22: Delete everything from paragraph beginning "the font
  attribute" (inclusive) to the paragraph beginning "#\name" (exclusive),
  now that we have voted to remove bits and fonts.

Page 3-23, under #':  Delete the second sentence (it doesn't add anything
  and is only confusing).

Page 3-23, last sentence: "surround" => "are used to notate".

Page 3-25, under #,:  We voted to remove #, from the language at the
  January meeting.  Also the reference to #, under #. should be removed.

Page 3-25, under #nR:  "digits, and it is read in decimal" => "which
  are interpreted as an integer in decimal radix".  Also "legal" =>
  "valid".

Page 3-27, under #s:  "legal" => "valid".

Page 3-27, under #n=: "appear twice" => "be defined twice".

Page 3-28, under #+:  Somehow all the discussion of feature lists
  has gotten lost.

Page 3-29, under #<:  "legal" => "valid".  Also, "It is used" => "This
  syntax is typically used".

Page 3-29, under #<newline> and #): "not legal reader syntax".  What
  does this mean in the new error terminology?

Page 3-29, 3-30.  I'm not sure if the material in the paragraphs
  beginning "To alter or extend" to the end of the section really
  belongs here.  

Page 3-31, "The object the reader returns...":  This sentence doesn't
  make sense.  Objects are not made up of parentheses.  How about
  deleting this sentence and rewording the beginning of the next to read:

    The reader constructs an object from the input text by interpreting...



Section 7.2
-----------

Page 3-37, under ():  Cross-reference to NIL.

Page 3-37, under atom:  The definition contradicts itself.  How about
  just saying "any object which is not a CONS".

Page 3-38, under cons:  "construct" => "object".

Page 3-38, under dotted pair:  Where is this term used?  If it's possible,
  I'd prefer to avoid this term and just use "cons" instead.

Page 3-38, under dynamic extent:  CLtL had a much better definition of
  this term (page 37).  Use it.

Page 3-39, under established:  This definition doesn't make sense.  Where
  is this term used?  Is it really necessary to have a glossary definition
  for it?

Page 3-39, under exit point:  This definition is pretty imprecise.
  I'd have to know what context it's being used in before I could suggest
  something better.

Page 3-39, under fill pointer: Delete the clause beginning "it is
the number..." (it adds nothing that isn't stated more clearly in the
next sentence).  Also change "constitutes" to "indicates".

Page 3-40, under implementation:  "code written to implement" =>
  "a program which implements".

Page 3-40, under implementation-defined:  What does "processor" mean?

Page 3-40, under implementation limits:  "code" => "user programs".

Page 3-40, under keyword:  remove "and is prefixed by :".  You can add
  something else here if you want, as long as it's clear that the colon
  prefix is a property of the printed representation.

Page 3-40, under lambda-expression: add "and follows lambda
expression syntax" and a cross-reference to wherever the material from
section 5.2.2 of CLtL ends up.

Page 3-40, under lambda-list:  This definition is imprecise and 
  confusing.  I suggest replacing it with:

    A list representing the formal parameters to a function.

  and adding another pointer to section 5.2.2.

Page 3-40, under Lisp reader:  is this actually used anywhere?

Page 3-41, under longer:  Is this actually used anywhere?  Same goes
  for "shorter" on the next page.

Page 3-41, under module:  Since we have removed PROVIDE, REQUIRE, and
  *MODULES*, I don't think this term should be used anywhere any more.

Page 3-41, under name:  Things such as BLOCKs also have names.  Is
  this term intended to refer only to names of variables, or was this
  an oversight?

Page 3-41, under plist:  Aha.  I remember asking about plists when I
  reviewed the definition of the symbol data type.  Plist refers to a
  property list in general, and not necessarily a property list 
  associated with a symbol.  How about putting the real definition of
  property list here (the business about it being a list of alternating
  keys and values) and having the symbol definition reference it.

Page 3-41, under predicate:  "Predicates have no side effects".  I think
  you ought to qualify this with "usually".

Page 3-42, under top-level:  We now have a formal definition of what
  top-level is, after passage of issue EVAL-WHEN-NON-TOP-LEVEL.  I was
  anticipating that material would end up in section 4.2.


Section 6.1
-----------

Page 3-45, under Syntax: The actual format of the syntax descriptions
  in chapter 6 looks quite a bit different than what I anticipated from
  this.  In particular, I was expecting that keyword parameters would be
  specified using normal lambda-list syntax and appear in the slanted
  font like other parameters.  Instead, you are generally using the
  actual keywords in boldface font to refer to the formal parameter
  associated with that parameter.  I really encourage you to stick
  with the normal lambda-list syntax and the slanted font.  First, it
  makes the treatment of all arguments more uniform throughout the
  discussion.  Second, using lambda-list syntax might allow you to be
  more concise about specifying default values.

Page 3-46, under values:  After seeing some of the actual tool 
  descriptions, I'm inclined to think that the values should just be
  listed as types.  Special cases are better off being described in
  the description section, instead of duplicated in both values and
  description.

Page 3-47, under Other information: After seeing the glossary and the
  data type definitions, I'm not sure why you need to duplicate
  information that already appears in those places here.  This includes
  things like "array" and "fill pointer".  Perhaps things like
  "arguments to the function", "environment object", and "satisfies the
  test" should be moved to the glossary and the entire list deleted.


CLOS tools
----------

I didn't review this section since I don't consider myself wizardly
enough about CLOS to do a very good job on it.


PREDICATES
----------

General comment #1: A common problem I see in many places here is
saying that "FOO is true if such-and-such, and is NIL otherwise."  It
would be much more accurate to say "FOO returns true (or NIL)", or
"the value of FOO is true (or NIL)".  Nearly all of the functions in
this section are affected by this problem, so I won't repeat myself
individually on each one.

Page 3-152, NIL: This definition makes no sense at all.  Replace it
  with:

    The value of the constant NIL is NIL.  NIL represents both a boolean
    false and the empty list.

Page 3-153, T:  To parallel the definition of NIL, replace with:

    The value of the constant T is T.


Page 3-158:  towards bottom of page, why is NIL in a different font in
  the example?


Page 3-184, EQ:  This definition seems awkward.  The business about
  occupying the same memory locations is really an implementation note
  in CLtL.  How about using the definition from CLtL:

    (eq x y) is true if and only if x and y are the same identical object.

Page 3-186, EQL: This definition also seems awkward.  Part of the
  problem is the way the first sentence is punctuated.  I suggest
  replacing it with:

    The EQL predicate returns true if its arguments are EQ; if they are
    both numbers of the same type and same value; or if they are both
    character objects that represent the same character.  Otherwise, EQL
    returns NIL.

Page 3-188, EQUAL: This is missing a statement that any two objects
  that are EQL are also EQUAL.

Page 3-189, EQUALP:  I can't figure out if this includes changes to
  EQUALP that were approved at the January meeting or not (I'm not sure
  exactly what those changes are).  Anyway, the wording on many of the
  subitems in the description needs help.

Page 3-193, bottom of page:  It should be made more clear that the decision
  to use NOT vs NULL is a matter of style.

Page 3-194, AND:  The presentation of the material in the Values section
  seems awkward here, partly because of the use of the different fonts.
  How about moving the business about (and) to the description section and
  saying it in English, like:

    If no forms are supplied as arguments, AND returns T.

  Also, the first sentence in the description is awkward.  I'd replace it
  with:

    AND evaluates each form one at a time from left to right.

Page 3-196, OR:  Same things apply as to AND.


STRINGS:
--------

General comment #2: In a number of places you have added a note about
  it being an error to destructively modify a constant to the notes
  section.  I believe it would be sufficient to state this once up
  front, probably in section 4.1, instead of trying to duplicate this
  in all the places where it is possible to perform a destructive
  operation.

General comment #3: When you have a group of functions described
  together, the heading would be much more readable if you listed each
  one on a separate line.  If it continues onto multiple pages, I think
  it would be sufficient to name only the first function in the list
  in the heading on the continuation pages.

Page 3-201, about halfway down the page: replace "char<" with "char<
  or char-lessp (as appropriate)".

  Also general comment #1 applies here.

Page 3-209: "non-case-modifiable non-digit".  There are too many 
  negatives here and I'm having a hard time understanding this.  CLtL
  says "non-alphanumeric character" here.


SEQUENCES:
----------

General comment #4:  There are a lot of "it is an errors" in this
  section that need to be updated to use the new error terminology.

General comment #5:
  The "test" argument to the -if and -if-not functions should be renamed
  "predicate".  It's confusing to have two arguments with the same name
  that are used differently but discussed together.

  The type specifiers for the keyword "test" and "test-not" arguments
  are given incorrectly throughout this section.  They should both be
  (function (t t) boolean).

  In a number of places, you have talked about how the key function
  "extracts" a "part" of the sequence element.  I would feel more 
  comfortable with this wording if it were qualified with "typically",
  since in fact the key function may return some object which is not
  a "part" of the sequence element.  This applies to some of the list
  functions as well.

General comment #6:  In many places, you say either: #'EQL is used"
  or "#'EQL is the default used".  Change them both to say: "#'EQL is
  the default test used".

Page 3-224, concatenate:  Is "sequence type specifier" well-defined?

Page 3-226, map etc.:  
  Under arguments, result-type may also be NIL.
  Under values, since NULL is a subtype of sequence, you could simply
  say that MAP returns sequence.  

Page 3-227: under MAPC and MAPL, say that the first list argument
  is returned.

Page 3-228: the last sentence before the Side Effects section should
  be made into a comment on the next-to-last example.  In its current
  location, it's not at all clear what "case" it applies to.

Page 3-230:  The type you've given for the "predicate" argument is
  incorrect.  You could either say what you did for the "function" 
  argument to the map functions, or else say (function (t &rest t) boolean).

Page 3-232: The syntax of the type specifiers given for the "function"
  argument is wrong.  I don't think we have a type specifier to
  describe a function that must be callable with either two arguments
  or none, so probably an English description would be best here.

Page 3-237, last paragraph:  replace second sentence with:
    Elements of the subsequence of sequence-2 specified by start2 and
    end2 are copied into the subsequence of sequence-1 specified by start1
    and end1.

Page 3-240, last paragraph:  delete "but not all".


LISTS:
------

General comment #7:  change EQL to #'EQL when talking about the default
  test function in this section.

Page 3-267, next to last paragraph of description:  Delete the first
  two sentences, which are extremely confusing.  Add to the end of the
  paragraph:

    If list is nil, both car and cdr return nil.

Page 3-268, in notes:  change last two occurrences of "may" to "may also".

Page 3-273:  General comment #1 applies here.

Page 3-276:  Under values, just say T.  You've said what it returns in
  English in the description section.

Page 3-278, 3-279:  why do the symbols V and VI appear in uppercase here?
  Aren't we using lowercase consistently in program examples?

Page 3-280: "means the same" is imprecise.  How about "behaves the
  same" or "is the same function" or "is the same operation"?

Page 3-282: This is described as if the "right" way to implement nthcdr
  is as something like:
    (defun nthcdr (n list)
        (dotimes (i n) (cdr list))
        list)
  A somewhat more accurate description would be:
    NTHCDR returns the Nth successive CDR of LIST.

Page 3-284:  What's listed in the values section contradicts the last
  paragraph of the description section.  The description section wins;
  change values to say an object of type T is returned.

Page 3-286:  delete "not a cons" from last sentence of description.

Page 3-389:  Under syntax, this isn't valid lambda list syntax.  You'll
  have to put some special conditions in the description to constrain
  the types of the arguments.

Page 3-291:  Delete the first sentence of the description.  It adds
  nothing.

Page 3-295:  Change values to indicate object of type T.

Page 3-299:  Under arguments, where is "last-arg"?

Page 3-303:  You are using "cons" as a verb here with italics to indicate
  that it is in the glossary, but the glossary defines it as a noun.
  Perhaps "prepend" would be an alternate word to use here.

Page 3-316 arguments section: General comment #5 applies here.  Also,
  the slanted test function (the one that should be renamed
  "predicate") is described incorrectly in the arguments section (it
  should be a one-argument predicate).

Page 3-316, first paragraph of description:  "satisfies some test condition
  or predicate" => "satisfies the test".

Page 3-317, last paragraph of description:  It's possible that the entire
  tree might be replaced so the result won't necessarily be EQ to the
  original tree argument.

Page 3-319: In third paragraph of description, "with which it is
  associated" => "with which that key is associated".  In fourth
  paragraph, "an element of a-list" => "a key appearing in the a-list".

Page 3-320, last paragraph before examples:  "modifies" => "is permitted
  to modify".

Page 3-322: add "and" before "the second argument" in second paragraph
  of description.

Page 3-322, fourth paragraph of description: "satisfies some test
  condition or predicate" => "satisfies the test".

Page 3-324, in description: "nthcdr n list" => "(nthcdr n list)".

Page 3-331:  delete first sentence of third paragraph of description.

Page 3-333:  delete first sentence of third paragraph of description.

Page 3-335:  "appears in (matches some element of)" => matches some
  element of.

Page 3-337:  I am not sure if "adding" an object "to the front" of a
  list is well-defined.  See my remarks on PUSH above.

Page 3-341:  The description section here makes no sense at all, 
  particularly regarding the handling of the key argument.  Try replacing
  the whole thing with:

    Assoc, assoc-if, and assoc-if-not return the first cons in a-list
    whose car satisfies the test.  If no such cons is found, NIL is
    returned.

    If neither test nor test-not is supplied, #'EQL is used as the default
    test.  

    If key is supplied, it is applied to the car of the a-list
    entries and the result passed to the predicate, test, or test-not
    function instead of the car itself.

Page 3-344:  Same problems here.  Let's try to get the wording of ASSOC
  and RASSOC as similar as possible.

  Why is the business about NIL appearing in an a-list only mentioned
  in the context of RASSOC and not ASSOC?  Wasn't there a cleanup issue
  dealing with this?


NUMBERS:
--------

I haven't looked this over very thoroughly, since I don't consider
myself to be an expert on this stuff either.

General comment #1 applies to the predicates defined here.

General comment #8:  Several of the functions described here talk about
  "necessary type conversions".  Perhaps this ought to be a glossary
  term, or some kind of cross-reference provided to where type 
  conversions are discussed.

General comment #9:  A few of the functions contain implementation notes
  in the description section.  (For example, see ABS).  I think these
  belong in the "notes" section.

Page 3-360:  Somewhere it should be mentioned that
  (1+ x) == (+ x 1)
  (1- x) == (- x 1)

Page 3-364: "if integers contains one integer" => "if only one integer
  is provided".

Page 3-368, first paragraph of description:  "are used for" => "perform".

Page 3-368: there should be no paragraph break between what are now the
  second and third paragraphs.

Page 3-370:  logbasenumber??  Perhaps you mean to put "base" in 
  subscript and insert some whitespace before "number"?

Page 3-374:  There is a stray "%" at the top of the page.

Page 3-395, second paragraph:  Delete from "it is roughly" to end of
  paragraph.  Insert:

    For example, ffloor behaves as if it gives its arguments to floor,
    coerces the first result to be a float, and returns both values.

Page 3-400:  The description section should start out by saying 
  something about how floats are represented and introduce the
  terminology.  In particular, it ought to be mentioned that the
  four attributes combine like
    sign * significand * radix**exponent
  to represent the float.

  Under float-digits and float-precision, "radix digits" => 
  "radix b digits".

Page 3-411:  "are" => "may be".

Page 3-415: It should be mentioned that ASH is defined to behave as if
  integer is represented in 2's complement form, regardless of whether
  that is how it integers are represented internally.

Page 3-430:  "arg" Bytespec?

Page 3-433: in first paragraph of description, change "random number"
  to "pseudo-random number".
  
  The last paragraph of the description really belongs in the Notes
  section.  You might also want to cite Knuth or the article in last
  October's CACM.

Page 3-434:  The second paragraph of the description seems like it belongs
  in the description of the random-state data type, not here.

  The paragraph in the notes section doesn't add anything.  Cut it.

Page 3-435: "the current random number state object (the value of
  *random-state*)" => "the value of *random-state*".

Page 3-436, notes section: In first paragraph, "random-state" =>
  "make-random-state"?

  The remainder looks like it belongs in the description of the
  random-state data type or as an implementation note.

Page 3-436:  I don't understand what the "affected by" section is supposed
  to mean.  Also on pages 3-440, 3-441.














-------

∂06-Apr-89  1035	CL-Editorial-mailer 	Editorial committee notes    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 6 Apr 89  10:35:21 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA05316; Thu, 6 Apr 89 10:36:12 PDT
Message-Id: <8904061736.AA05316@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-editorial@sail.stanford.edu; id AA05316; Thu, 6 Apr 89 10:36:12 PDT
From: chapman%aitg.DEC@decwrl.dec.com
Date: 6 Apr 89 13:32
To: cl-editorial@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Editorial committee notes




                        Editorial Subcommittee Report
                                 March, 1989



      1  INTRODUCTION

           The editorial subcommittee of X3J13 met on  March  27,  1989,
      from  7-10  PM  at  the  Topkai  Restaurant  in Fairfax, Virginia.
      Attendees were:

      Kim Barrett        Kathy Chapman 
      Masayuka Ida       Sandra Loosemore   
      Barry Margolin     Larry Masinter     
      Bob Mathis         David Moon         
      Dan Pierson        Kent Pitman        
      Guy Steele         Dick Gabriel       
      Walter van Roggen  JonL White


           This memo summarizes the important results of the meeting and
      lists  the action items from the meeting.  Some of the information
      in this memo  is  a  result  of  a  follow-up  drafting  committee
      meeting.



      2  SUMMARY

           A status report concerning what has been going on editorially
      was  given.   The  letter  ballot was summarized, a report on size
      reduction was given, and the status of appendices to the  standard
      was discussed.

           The editorial issues were each discussed.

           The attendees felt that it was time to create a  subgroup  of
      the  editorial  committee in order to facilitate completion of the
      standard.  The result was a  "drafting  committee"  consisting  of
      Moon, Gabriel, Steele, Masinter, and Chapman.



      3  LETTER BALLOT SUMMARY

           Following is the summary of who  voted  and  what  the  votes
      mean:

      1.  Thirteen companies voted.

      2.  Sections 2.3, 2.4, and 2.5 passed as amended  (amended  copies
          available  on  request).   CUT-OFF-DATES  and  TOC  passed  as
          amended (amended copies will be sent  electronically).   FONTS
          passed with no amendments.  The list of changes to the amended
          sections is available upon request.
!
                                                                Page 2


      3.  Even though enough votes were received to  pass  these  issues
          and  sections,  it was decided to call for a block vote anyway
          in the general meeting to  allow  time  for  people  to  voice
          objections.

      4.  Bob Mathis was to explain the meaning of a true letter ballot,
          and the importance of voting, in the general meeting.

!
                                                                Page 3


      4  SIZE REDUCTION STUDY

           The  following  statistics  were  gathered  using  Chapter  7
      (original size = 436 pages):

      1.  A 12% reduction was realized when the blank line between  each
          header and the following text was deleted.

      2.  A 22% reduction was realized when new functions  didn't  start
          on new pages.

      These two reductions would be approximately additive,  so  that  a
      total  34% reduction could be realized (so the final size would be
      288 pages).

           The CLOS  functions  were  used  to  experiment  with  moving
      non-requirement parts of the function descriptions to an appendix.
      The contents under the headers labeled Side Effects, Affected  By,
      Examples,   See  Also,  and  Notes  were  removed  from  the  CLOS
      functions, and a 21% reduction was realized.

           The editorial committee was  in  favor  of  implementing  the
      first  two  reduction  steps  immediately,  and  taking  out blank
      sections  after  most  editing  has  been   completed.    However,
      non-requirement, non-blank sections are to be left in the standard
      for now.  It was  suggested  that  headers  and  footers  be  made
      smaller.

           It was decided  that  all  "defined  names"  (new  term  that
      replaces  "tools")  appear  separately  in  alphabetic  order with
      references to their actual descriptions.  This will  increase  the
      size  of  the  standard  slightly,  but  will  improve readability
      greatly.



      5  APPENDICES

           A suggestion was made that  there  be  two  appendices.   The
      first  appendix  will  contain  the list of deprecated and removed
      defined names, as  well  as  section  1.6  (Implementation-defined
      features)  and  other  things  we decide to put there.  The second
      appendix will contain information  about  things  that  should  be
      considered  for  standardization in the next standard.  The things
      will either be pointers to relevant documents or a reproduction of
      the   documents   themselves,  depending  upon  the  size  of  the
      documents.

           The appendices will probably not be submitted  to  ANSI  with
      the  draft standard.  Therefore we should postpone applying effort
      to completion of the appendices until the standard is mostly ready
      for public review.
!
                                                                Page 4


      6  HOW WE SHOULD CONTINUE FROM HERE.

           There was general agreement that the X3J13 votes on  sections
      of the standard should be valued in the following respects:

      1.  Calling for a vote seems to encourage  people  to  review  the
          section on which the vote is taken.  Requests for reviews have
          thusfar not drawn enough  comments  for  the  standard  to  be
          considered  adequately  reviewed.  After calling for the vote,
          many comments, criticisms, and endorsements were received.

      2.  Calling for a vote seems to allow X3J13 to become involved  in
          the  preparation  of the standard so that they are more likely
          to actively buy in to the results.


           Since  calling  for  a  vote  DOES  NOT  provide  a  complete
      technical  sanity  check,  nor  does  it provide any type of final
      closure on a section (the same as for clean-up issues), the burden
      of  technical  correctness,  proper  interpretations,  and clarity
      still resides with the editorial committee.  Since there are  many
      possible  interpretations of certain key features of the language,
      the people in attendance at the editorial committee  meeting  felt
      that  it  was  time  to  decrease the number of people editing the
      standard  and  to  allow  those  editing  to   make   the   proper
      interpretations.   Obviously  the group chosen to do this job must
      be both able to make the interpretations, and recognized by  X3J13
      as  able  to  make  the  interpretations.  The number of people in
      X3J13 with those credentials is  small:   Moon,  Gabriel,  Steele,
      Masinter.   Luckily these people are willing to devote the time to
      the standard to do this job.

           From now on, therefore, the drafting committee will review or
      rewrite  as  necessary  according  to the schedule outlined in the
      issue CUT-OFF-DATES.  If a section is  ready  for  ballot  by  the
      scheduled time of its ballot or any succeeding ballots, it will be
      mailed for vote.  If not, it will be considered at a  later  date.
      The  goal is to complete all sections by the June meeting.  Coming
      to closure on all the sections by the June meeting is not a  goal;
      having all the sections ready for review by X3J13 between June and
      September IS a goal.

           The advice we will give to X3J13 is that they  should  review
      sections  that  we  consider  ready  for  vote, but should wait to
      review all other sections until they have been adequately reworked
      by the drafting committee, but no later than mid- to late-July.

∂06-Apr-89  1140	CL-Compiler-mailer 	section 4.2    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 6 Apr 89  11:40:26 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA12460; Thu, 6 Apr 89 12:40:23 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA00636; Thu, 6 Apr 89 12:40:20 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904061840.AA00636@defun.utah.edu>
Date: Thu, 6 Apr 89 12:40:19 MDT
Subject: section 4.2
To: cl-compiler@sail.stanford.edu
Cc: cl-editorial@sail.stanford.edu

Some time ago, I promised Kathy Chapman that I would prepare a draft
of section 4.2 for the standard.  I've started to outline the
organization and decide which issues go where, which is what follows.
Any comments you have on this before I get started on serious writing
would be welcome.

The issues I've listed are those that are relevant to the discussion,
and I expect that in some cases not all of the material from the issue
will be included directly in that place.  For example, issue
COMPILED-FUNCTION-REQUIREMENTS will probably end up being distributed
between the subsections on COMPILE and COMPILE-FILE in section 4.2,
and the description of the COMPILED-FUNCTION data type in section 2.2.
I haven't yet figured out the details of exactly what sections will be
affected by each of our issues yet, but I do plan to put together a
list eventually (once section 4.2 starts to take shape).

-Sandra

---- cut here -------- cut here -------- cut here -------- cut here ----

Introduction
------------

The compiler is a utility that translates programs into an
implementation-dependent form that can be represented or executed more
efficiently.  Compiling a program involves resolving certain kinds of
references appearing within the code at compiletime, instead of
waiting until the program is actually run. 

In some implementations, compilation may happen implicitly.  For
example, it is permissible to implicitly compile all functions defined
with DEFUN or FUNCTION, or to implement EVAL so that it implicitly
compiles the form and then executes the resulting code.  Common Lisp
also provides tools (the functions COMPILE and COMPILE-FILE) for
explicitly forcing compilation to take place.


Time of Binding
---------------

[OK, we've said that the compiler works by resolving some things in
advance.  Now talk about exactly what those things are.]

[Issues:
  *COMPILE-ENVIRONMENT-CONSISTENCY
   PROCLAIM-INLINE-WHERE
   ALLOW-LOCAL-INLINE
   ]


COMPILE
-------

[What COMPILE is required to/allowed to do.]

[Issues:
   COMPILE-ARGUMENT-PROBLEMS
  *COMPILED-FUNCTION-REQUIREMENTS
   ]


COMPILE-FILE
------------

[Present our model of how the file compiler works.  List all
   the macros that do special compile-time magic.]

[Issues:
   COMPILER-DIAGNOSTICS
   COMPILER-VERBOSITY
   WITH-COMPILATION-UNIT
  *COMPILED-FUNCTION-REQUIREMENTS
   EVAL-WHEN-NON-TOP-LEVEL
   DEFINING-MACROS-NON-TOP-LEVEL
   LOCALLY-TOP-LEVEL
   COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
  *CLOS-MACRO-COMPILATION
  *PROCLAIM-ETC-IN-COMPILE-FILE
   IN-PACKAGE-FUNCTIONALITY
   COMPILE-FILE-PACKAGE
   ]


Compiler/Loader Interface
-------------------------

[How COMPILE-FILE tells LOAD to reconstruct objects appearing in
the source code.]

[Issues:
   CONSTANT-COMPILABLE-TYPES
  *CONSTANT-FUNCTION-COMPILATION
  *COMPILE-FILE-SYMBOL-HANDLING
   LOAD-OBJECTS
   CONSTANT-COLLAPSING
   CONSTANT-CIRCULAR-COMPILATION
   LOAD-TIME-EVAL (?)
   ]
-------

∂06-Apr-89  1931	CL-Editorial-mailer 	Correction    
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 6 Apr 89  19:31:28 PDT
Received: from [128.167.64.2] by RELAY.CS.NET id aa26890; 6 Apr 89 22:31 EDT
Received: from relay.cc.u-tokyo.ac.jp (junet-relay.gw.u-tokyo.ac.jp) by mtfuji.gw.u-tokyo.ac.jp (3.2/WIDE/JUNET-0.9)
	id AA21142; Thu, 6 Apr 89 22:31:17 EDT
Received: from ccut.cc.u-tokyo.junet (ccutrd) by relay.cc.u-tokyo.ac.jp (3.2/6.3Junet-1.0/CSNET-JUNET)
	id AA00717; Fri, 7 Apr 89 11:30:50 JST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
	id AA20218; Fri, 7 Apr 89 11:29:54 JST
Received: from kepa.cc.aoyama.junet by aoyama.cc.aoyama.junet (4.0/6.4J.BETA2-agu2)
	id AA08853; Fri, 7 Apr 89 10:33:35 JST
Received: by kepa.cc.aoyama.junet (4.0/6.3Junet-1.0)
	id AA01026; Fri, 7 Apr 89 10:34:08 JST
Date: Fri, 7 Apr 89 10:34:08 JST
From: Masayuki Ida <ida%cc.aoyama.junet@relay.cc.u-tokyo.ac.jp>
Return-Path: <ida@cc.aoyama.junet>
Message-Id: <8904070134.AA01026@kepa.cc.aoyama.junet>
To: cl-editorial@SAIL.STANFORD.EDU
Subject: Correction


Dear Collegues, especially who attended march 27 editorial meeting

I want to correct my words.
I said at the meeting that we got an Internet address for
a direct link between US and Japan and I am to be possible to
FTP directly.
But, I was taught that We cannot FTP/telnet using the line
until everything is settled, though several sites including 
mine has internet address already.
The link is only used for mail exchange for a while.

Masayuki Ida

∂07-Apr-89  1616	CL-Editorial-mailer 	[eliot%winnie.Princeton:EDU:Xerox: Esoteric DEFTYPE :type  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Apr 89  16:16:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 89 15:59:09 PDT
Date: 7 Apr 89 15:58 PDT
From: masinter.pa@Xerox.COM
Subject: [eliot%winnie.Princeton:EDU:Xerox: Esoteric DEFTYPE :type
 property]
To: cl-editorial@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890407-155909-9865@Xerox>

Is there any way that this could be misinterpreted in the standard? Perhaps
just as there's a section on evaluation, we need at least a few words on
'treatment of type specifiers' that says explicitly that deftype'd defined
types take precidence?

     ----- Begin Forwarded Messages -----

Date:  1 Apr 89 22:04 PST
From: eliot%winnie.Princeton:EDU:Xerox
Subject: Esoteric DEFTYPE :type property
To: kcl%RASCAL.ICS.UTEXAS:EDU:Xerox

Here's a very esoteric property -- I hesiate to call it a bug -- of
TYPEP. 

>(defstruct (quux (:type list) :named) x y)
QUUX

>(deftype quux () '(satisfies quux-p))
QUUX

>(typep (make-quux) 'quux)
NIL

Steele isn't clear on what should happen, but Lucid 2.2 returns T, which
seems to be a more useful value. 

The reason for this behavior is that TYPEP tests first to see if
(make-quux)
is a structure, and tests for a deftype-definition only if it's not. One
fix is to reverse the two cond clauses at the end of the definition
of type in predlib.lsp, if anybody really cares.



     ----- End Forwarded Messages -----

∂07-Apr-89  2113	CL-Editorial-mailer 	[eliot%winnie.Princeton:EDU:Xerox: Esoteric DEFTYPE :type property]  
To:   cl-editorial@SAIL.Stanford.EDU
CC:   masinter.pa@XEROX.COM   
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


Larry writes:

``Is there any way that this could be misinterpreted in the standard? Perhaps
just as there's a section on evaluation, we need at least a few words on
'treatment of type specifiers' that says explicitly that deftype'd defined
types take precedence?''

CLtL is pretty clear on this topic, but it is an obscure one. First,
the bug in KCL has to do with the interpretation of DEFSTRUCT options
and not with DEFTYPE. 

(defstruct (quux (:type list) :named) x y)

This should make a constructor that builds a list exactly like the one
that LIST produces, with QUUX as its car (Page 317, CLtL).

If we define this type:

(deftype quux () '(satisfies quux-p))

then this form

(typep (make-quux) 'quux)

should return precisely what this one does

(typep (list 'quux nil nil) 'quux)

Eliot writes:

``The reason for this behavior is that TYPEP tests first to see if
(make-quux) is a structure, and tests for a deftype-definition only if
it's not. One fix is to reverse the two cond clauses at the end of the
definition of type in predlib.lsp, if anybody really cares.''

The result of MAKE-QUUX should never be a structure, so I assume that
KCL interprets the DEFSTRUCT form as if it were this:

(defstruct quux x y)

Possibly it interprets it as if it were

(defstruct (quux :named) x y)

which is marginally correct syntactically.

			-rpg-

∂11-Apr-89  1233	CL-Editorial-mailer 	comments on material for April ballot  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89  12:32:49 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Tue, 11 Apr 89 15:30:06 EDT
Date: Tue, 11 Apr 89 15:29 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: comments on material for April ballot
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: chapman%aitg.dec@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: <8904031950.AA18380@defun.utah.edu>
Message-Id: <19890411192955.6.BARMAR@OCCAM.THINK.COM>

I've read through the material you distributed in Fairfax, up to (but
not including) the Predicates chapter.  I've also read Sandra's comments
that were mailed last week, and I agree with her on any points that I
don't specifically comment on below.  Sorry I didn't get these comments
in by the 4/10 deadline.

I'll start off by commenting on some of Sandra's comments:

    Date: Mon, 3 Apr 89 13:50:58 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Sections 3.1 & 3.2
    ------------------

    Page 3-9, Reader algorithm:  I wonder if a state diagram might be useful
      here.  If I have time I'll see whether I can put something together.

Well, I'm not a big fan of state diagrams, and I think a diagram of this
algorithm would be a bit unweildy.

    Page 3-10, item 10:  "an error is signalled".  Interesting -- CLtL
      contradicts itself on this issue.  On p. 338 it says "signal an error"
      but the top of page 341 effectively says "consequences are unspecified".
      Do we need a cleanup issue to resolve this?

I don't think these two pages are contradictory.  On p.338, and in the
standard, it says to signal an error if the token is not of legal
syntax.  P.341 is describing part of the determination of whether a
token is of legal syntax.  In particular, if a token is a potential
number but not actually a number, it is implementation-defined whether
it is interpreted as a symbol, some other object, or invalid (in which
case an error is signalled).

    Page 3-16:  "These rules are true regardless of any implicit interning".
      I can't figure out what this means.  Also, "the current package" =>
      "the value of *package*", and "*package*" => "the value of *package*".

In general, I think these paragraphs need some rewording.  The current
wording is in response to comments of mine from the last round of
reviews, but the new wording is extremely hard to parse and understand.

    Page 3-17 "not immediately preceded by an escape character":  change the
      commas to parentheses.

No, the commas should simply be removed.  The above phrase is an
essential modifer of the noun "dot".  It's not just a parenthetical
reminder.  And there's no need for the commas.

    Page 3-17, under ):  what does "invalid" mean in the new error 
      terminology?

Invalid is the same as "is an error".  The new error terminology is
going to have to be determined on a case by case basis.

    Page 3-17, under ":  Hmmm.  Here's another place where CLtL contradicts
      itself (page 30 vs. page 347).  I think page 347 (what you have here)
      is probably correct.

I can't find the contradiction you refer to.

    Section 7.2
    -----------

    Page 3-37, under atom:  The definition contradicts itself.  How about
      just saying "any object which is not a CONS".

Or add "for example".

Now on to my own comments:

Section 3.1
-----------

P. 3-9, first para, last sentence:  This contradicts later statements,
since a token that is not a potential number might be invalid and might
signal an error (e.g. a token consisting only of multiple dots).

P. 3-10, last sentence: The word "unless" should be "when".

P. 3-11: The syntax for integers should be here, probably right before
the Rational section.

P. 3-11, Rational: A better title for this subsection would be "Ratio".
Rational refers to both ratios and integers, but this section only
describes the syntax for ratios.

P. 3-12, item 3: The section that is notated as coming from issue
COLON-NUMBER doesn't belong here.  The way the paragraph was previously
written, tokens beginning with a colon were already excluded.  Since
this cleanup issue was simply a clarification, it should probably turn
into a parenthetical paragraph at the end of the section, or in the
"Symbols as tokens" section.  It's already the case that anything not
satisifying this list of requirements is not a potential number, and it
will seem confusing to mention only one of those counter-requirements
specifically.

Section 7.2
-----------

In general: Why are some letters of the alphabet combined into a single
section?  This makes sense for multi-volume objects such as
encyclopedias, or for thumb-tabs in a dictionary, but I see no
justification for it in this document.

P. 3-37, argument evaluation order: This isn't a definition of the term.

P. 3-39, error: This definition doesn't cover all the uses of the term
"error".  For instance, when we say that something "signals an error",
that isn't considered to be incorrect functioning; in fact, it's is
correct for a function to signal an error when appropriate.

P. 3-39, exit point: The definition given is pretty useless.  How about:

    The named target of a transfer of control established by a BLOCK or
    CATCH form and referenced by THROW or RETURN-FROM.

P. 3-39, extent: "not an error" should be "permitted" (prefer the
positive voice over the negative).

P. 3-39, fill pointer: Add "although many functions ignore them" at the
end of the last sentence.

P. 3-39, form: The definition is incorrect, since symbols and
self-evaluating objects are also forms.  "Form" is actually a hard word
to define usefully, since it's defined by use, not by structure; any
Lisp object you might want to pass to EVAL is a form.  Here's the best
simple definition I can come up with:

    An object representing an expression to be evaluated.

P. 3-39, function: Since the word "function" is in italics, I presume it
refers to the glossary entry.  In that case, this definition is
circular.

P. 3-39, generic function: Add the word "automatically" after "depends".
Many functions depend on the classes or identities of their arguments,
but generic functions do it automatically.

P. 3-41, method: Replace "define" with "an object that defines".

P. 3-41, proper name: It took me ten readings of this sentence to parse
it properly.

P. 3-42, slot: A slot is not an object, it is part of an object (an
instance or structure), and it holds an object.  Also, delete the phrase
"that is syntactically valid for use as a variable name", since it is
meaningless; symbols don't have syntax, they're just objects (even when
they're being read in, all symbols are syntactically valid, because of
escaping).

P. 3-42, t:  It's also the conventional "truth" value.

Section 6.1
-----------

P. 3-46, Conditions, last sentence: "operators" should be "functions".
According to the glossary, "operator" refers to the name, not the
object, but it is the function objects that can be passed and which can
be called.  Operators also includes macros and special forms, and these
can't be called.

CLOS
----

General comment: A number of the generic functions described are only
generic because of meta-objects.  Since we aren't describing the
meta-object protocol in this standard, does it still make sense to
document these functions as generic?  For instance, what's the point of
specifying that ADD-METHOD is a generic function?  We don't provide
documentation to permit a user to define classes of generic functions or
methods, so as far as he is concerned this is just a built-in function.

P. 3-60, CLASS-NAME: Shouldn't it say somewhere in here that the value
is a symbol?

P. 3-70, under Options: The wording of the first sentence is confusing.
It almost seems to say that each option must occur exactly once; I
initially misread it as saying "one of each of the following".  How
about:

    one of the following (a particular option may not be specified
    multiple times):

P. 3-70, under Method-description: "object" should be "list".

P. 3-71, last paragraph: Is there a default for this option?  If so,
what is it?

P. 3-72, second sentence: "declaration is" should be "declarations are".

P. 3-72, third bullet: Is "standard-method" in the right font?  It's not
a glossary item.

P. 3-73, under Side Effects: It should also say that
function-specifier's function cell is modified.

P. 3-75, near bottom, first bullet: This should specify the name of the
documentation type used.

P. 3-78, second-to-last paragraph: This should specify the name of the
documentation type.

P. 3-83: "atom" (appears twice) should be "symbol".

p. 3-83, under Arguments: Is there a reason Declaration and
Documentation aren't listed?

P. 3-83, under Description: The use of the Documentation argument isn't
specified.

P. 3-84, first paragraph, second-to-last sentence: The parenthetical
"(but no keyword arguments)" should be "(but no specific keyword
arguments)".  It just makes the meaning a little clearer.

P. 3-85, under Side Effects, second sentence: add "and assigned to
function-specifier's function cell".

P. 3-87, under Arguments, under Doc-type: Are the first and third lines
in the corret fonts?

P. 3-95, under Conditions: "an an" should be "an".

P. 3-96, FUNCTION-KEYWORDS: Affected By and See Also should mention
DEFMETHOD.

P. 3-98, first sentence: add "generic" after "define".

P. 3-98, second paragraph, second sentence: "of to" should just be "of".

P. 3-102: See above comments about p.3-98.

P. 3-150, first and third lines: Are these in the correct fonts?

∂11-Apr-89  1337	CL-Editorial-mailer 	Re: comments on material for April ballot   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Apr 89  13:36:57 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA22202; Tue, 11 Apr 89 14:35:50 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA02565; Tue, 11 Apr 89 14:35:48 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904112035.AA02565@defun.utah.edu>
Date: Tue, 11 Apr 89 14:35:46 MDT
Subject: Re: comments on material for April ballot
To: Barry Margolin <barmar@Think.COM>
Cc: chapman%aitg.dec@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: Barry Margolin <barmar@Think.COM>, Tue, 11 Apr 89 15:29 EDT

> Date: Tue, 11 Apr 89 15:29 EDT
> From: Barry Margolin <barmar@Think.COM>
> 
>     Page 3-10, item 10:  "an error is signalled".  Interesting -- CLtL
>       contradicts itself on this issue.  On p. 338 it says "signal an error"
>       but the top of page 341 effectively says "consequences are unspecified".
>       Do we need a cleanup issue to resolve this?
> 
> I don't think these two pages are contradictory.  On p.338, and in the
> standard, it says to signal an error if the token is not of legal
> syntax.  P.341 is describing part of the determination of whether a
> token is of legal syntax.  In particular, if a token is a potential
> number but not actually a number, it is implementation-defined whether
> it is interpreted as a symbol, some other object, or invalid (in which
> case an error is signalled).

OK, that makes sense.  However, I still think it would be useful to
gather all the information about errors in the tokenizer in one place,
just to make sure that it is all consistent.  Here is what I've been
able to determine from CLtL:

Page 338 says that an error is signalled if a token is not of valid
syntax. 

Page 341 says that potential numbers that don't conform to number syntax
may or may not be of valid syntax.

Page 342 says that an error is signalled if a token has number syntax
but the corresponding number can't actually be represented. 

Page 343 says that an error is signalled if a token consists entirely of
dots, except for dotted-list syntax.

Page 344 says that the parts of a token representing a symbol that
correspond to the package and symbol names "may not have the syntax of
a number".  It also says that "it is an error" for other combinations
of package markers to appear in a token representing a symbol.  Page
176 says that this is reserved for implementation-dependent use.  (I
suggest the standard say it is unspecified whether such tokens are of
valid syntax, same as for the potential number case.)

Page 175 says that package:name syntax causes a correctable error to
be signalled if the package doesn't exist or if it doesn't have an
external symbol with the given name.  It doesn't say what
package::name syntax does if the package doesn't exist, although
signalling a correctable error seems like the obvious thing. 


>     Page 3-17, under ":  Hmmm.  Here's another place where CLtL contradicts
>       itself (page 30 vs. page 347).  I think page 347 (what you have here)
>       is probably correct.
> 
> I can't find the contradiction you refer to.

Page 30 says that backslash acts as an escape character in a string.
Page 347 says a single escape character may be used.  (It's possible
to mung the readtable so that backslash isn't a single escape
character and some other characters are.) I think page 30 was just
describing what happens with the default readtable, but I was confused
when I saw this in the standard because I remembered page 30 and not
page 347. 

-Sandra
-------

∂17-Apr-89  1320	CL-Editorial-mailer 	more standard comments  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Apr 89  13:20:45 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 17 Apr 89 16:19:51 EDT
Date: Mon, 17 Apr 89 16:19 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: more standard comments
To: chapman%aitg.dec@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, sandra%defun@cs.utah.edu
Message-Id: <19890417201935.2.BARMAR@OCCAM.THINK.COM>

I've now read the Predicates and Strings chapters, and here are my
comments.

Again, I agree with any of Sandra's comments I don't specifically
comment on.

PREDICATES
----------

P. 3-152, NIL, third sentence: This sentence is wrong.  It should either
be:

	NIL is the only object of type NULL.

or

	NIL is a type specifier for the empty type; there are no objects
	of type NIL, and NIL is a subtype of every other type.

(I think the CL designers really screwed up these names, by the way --
in set theory, the empty set is called the null set.)

P. 3-153, T: The Notes section should probably mention the common use of
T as the truth value of predicates, and in macros such as CASE and COND.
The Description section should mention that T is a type specifier for
the universal type, which includes all Lisp objects.

P. 3-154, TYPEP, under Type-specifier: Doesn't CLOS allow a class object
here, in addition to a type specifier?

P. 3-156, TYPEP, under See Also: Add TYPE-OF.

P. 3-157-8, SUBTYPEP: In the last paragraph on p.3-157, "array type-1)"
should be "(array type-1)" (in two places).  Throughout the whole
Description section, "diffrent" should be "different".  In several
places, the description say "(if (UPGRADED-ARRAY-ELEMENT-TYPE 'type1)
and (UPGRADED-ARRAY-ELEMENT-TYPE 'type2) return two different type
specifiers"; the "different" should be deleted (given the consistent
misspelling, I think the phrase "two diffrent type specifiers that
always refer to the same set of" was written once for the first sentence
and then copied).  The same goes for UPGRADED-COMPLEX-PART-TYPE.

P. 3-159, SUBTYPEP, under See Also: Add UPGRADED-ARRAY-ELEMENT-TYPE and
UPGRADED-COMPLEX-PART-TYPE.

P. 3-185, EQ, first paragraph of Notes: "with the same print name"
should be "that print the same".  The new wording distinguishes symbols
in different packages.

P. 3-186, EQL: I agree with Sandra that the wording of the first
paragraph is confusing, but I don't think her replacement of commas with
semicolons helps much.  How about "EQL is true of two objects X and Y if
any of the following conditions are met:" followed by a bullet list of
the conditions?

P. 3-193, NOT: The third sentence of the description doesn't make any
sense.  It is supposed to be talking about the case when X is an object
that is not a boolean.  But since ALL objects are booleans, there's no
such case.  I suggest deleting both the second and third sentences, and
putting "(not x) \equivalent (null x)" at the beginning of the Notes
section.

P. 3-194, AND, under Description: "last of form" should be "last form"
or "last of the forms".

STRINGS
-------

P. 3-199, CHAR,SCHAR, under Notes: "which are self-evaluating forms or
which appear inside of a QUOTE special form" should be "which were
created by evaluating self-evaluating forms or QUOTE special forms".

P. 3-201, STRING=,etc.: In the Values section, STRING-EQUAL returns
boolean.  The Description should mention that all these functions only
operate on the active portion of the string, i.e. they respect the fill
pointer.  In the third paragraph, "The functions return" should be "The
inequality functions return".

P. 3-202, STRING=, etc: In the Examples section, it would be nice if
there were some examples of the inequality functions returning NIL.  The
sixth example, "(STRING= "abcd" "01234abcd9012" :start2 5 :end2 9)" has
the wrong answer; it should be "true", not "4".

P. 3-203, STRING=, etc.: Under See Also, reference CHAR=, CHAR-EQUAL,
CHAR<, CHAR-LESSP, etc.

P. 3-209, STRING-UPCASE, etc.: In the last paragraph of the Description,
I think "destroyed" should be "modified".  I think this is a better term
when describing the behavior of destructive functions that only operate
on arrays, since replacing elements of an array doesn't actually destroy
the array.  When lists are permitted, and the operation can potentially
rearrange the CDR links (as in SORT or NREVERSE), "destroy" is a
reasonable term because the operation can actually cause the conceptual
object to cease to exist.  But there's no way to destroy an array.


P. 3-210, STRING-UPCASE, etc, under See Also: Add CHAR-DOWNCASE.

P. 3-212, STRING: In the last sentence, add WRITE-TO-STRING.

∂19-Apr-89  0907	CL-Editorial-mailer 	Re: Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 19 Apr 89  09:07:01 PDT
Received: by ti.com id AA01548; Tue, 18 Apr 89 21:36:05 CDT
Received: from Kelvin by tilde id AA04512; Wed, 19 Apr 89 11:00:52 CDT
Message-Id: <2817993626-120825@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 19 Apr 89  11:00:26 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, Bartley@mips.csc.ti.com
Subject: Re: Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)
In-Reply-To: Msg of 18 Apr 89 13:19 from chapman%aitg.DEC@decwrl.dec.com

> Issue:        ERROR-TERMINOLOGY
> References:   Chapter 5, Section 5.1, Working draft of the standard

I just noticed that it seems odd to put these definitions in section 5.1
along with the introduction to conditions.  It seems like they more
properly belong in section 1.4 ("definitions") since they relate more to
the terminology used in the standard than to the specification of
conditions.

∂25-Apr-89  0835	CL-Compiler-mailer 	draft of section 4.2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 25 Apr 89  08:34:55 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA29397; Tue, 25 Apr 89 09:35:02 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA11058; Tue, 25 Apr 89 09:34:55 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904251534.AA11058@defun.utah.edu>
Date: Tue, 25 Apr 89 09:34:54 MDT
Subject: draft of section 4.2
To: cl-compiler@sail.stanford.edu
Cc: cl-editorial@sail.stanford.edu

Here's my draft of section 4.2.  There are a couple pieces that are
still missing (due to the issues involved not having been voted on
yet) but I've marked the places that will have to be updated. 

I will make one more round of edits on this (probably in about a week)
if any of you have comments on content or organization, but after that
I'd like to turn it over to Kathy and the drafting committee.  I
understand that some other parts of the standard are being rewritten
by the drafting committee and that this material will probably need
some additional changes to conform to the same style.


Introduction
============

The compiler is a utility that translates programs into an
implementation-dependent form that can be represented and/or executed
more efficiently.  The nature of the processing performed during
compilation is discussed in the "Compilation Semantics" section below.
This is followed by a discussion of the behavior of COMPILE-FILE and
the interface between COMPILE-FILE and LOAD.

% References:
%    CLtL page 143 (next to last paragraph)
%    CLtL page 321 (second paragraph)

The functions COMPILE and COMPILE-FILE are used to explicitly force
compilation to take place.  It is permissible for conforming
implementations to also perform implicit compilation during ordinary
evaluation.  While the evaluator is typically implemented as an
interpreter that traverses the given form recursively, performing each
step of the computation as it goes, a permissible alternate approach
is for the evaluator first to completely compile the form into
machine-executable code and then invoke the resulting code.  Various
mixed strategies are also possible.  All of these approaches should
produce the same results when executing a correct program, but may
produce different results for incorrect programs.

% This paragraph should really conclude with a stronger statement that
% conforming programs must be structured so they will work if implicit
% compilation does take place, but CLtL doesn't come right out and say
% that, and we have never voted on any issue to say that either.


Compilation Semantics
=====================

% References:
%    Issue COMPILE-ENVIRONMENT-CONSISTENCY [pending]
%    Issue COMPILED-FUNCTION-REQUIREMENTS [pending]
% The material in this section will have to be updated to reflect further
% changes to these issues.

Conceptually, compilation can be viewed as a process which traverses a
program, performs certain kinds of syntactic and semantic analysis
using information (such as proclamations and macro definitions)
present in the compile time environment, and produces a modified
program.  As a minimum, the compiler must perform the following
actions:

- All macro calls appearing lexically within the code being compiled
  must be expanded at compile time and will not be expanded again at
  run time.  The process of compilation effectively turns MACROLET
  and SYMBOL-MACROLET constructs int PROGNs, with all calls to the local
  macros in the body replaced by their expansions.

  The compiler must treat any form that is a list beginning with a
  symbol that does not name a macro or special form as a function call.
  (This implies that SETF methods must also be available at compile time.)

- The compiler must capture declarations to determine whether
  variable bindings and references appearing lexically within the
  code being compiled are to be treated as lexical or special.  The
  compiler must treat any binding of a variable that has not been
  declared or proclaimed to be SPECIAL as a lexical binding.

- The compiler must process EVAL-WHEN forms that appear lexically within
  the program being compiled.  Effectively, the compiler must replace
  the EVAL-WHEN form with either a PROGN containing the body forms, or
  a constant NIL.

- The compiler must process LOAD-TIME-VALUE forms that appear lexically
  within the program being compiled.  In the case of COMPILE, evaluation
  of the LOAD-TIME-VALUE form happens at compile time and the resulting
  value is treated as a literal constant at run time.  In the case of
  COMPILE-FILE, the compiler must arrange for evaluation of the form
  to take place at load time.

In addition, the compiler is permitted to incorporate the following
kinds of information into the code it produces, if the information is
present in the compile time environment and is referenced within the
code being compiled.  Except where some other behavior is explicitly
stated, when the compile time and run time definitions are different,
it is unspecified which will prevail within the compiled code.  It is
also permissible for implementations to signal an error at run time to
complain about the discrepancy.  In all cases, the absence of the
information at compile time is not an error, but its presence may
enable the compiler to generate more efficient code.

- The compiler may assume that functions that are defined and
  declared or proclaimed INLINE in the compile time environment will
  retain the same definitions at run time.

- The compiler may assume that, within a named function, a
  recursive call to a function of the same name refers to the
  same function, unless that function has been declared NOTINLINE.
  
- COMPILE-FILE may assume that, in the absence of NOTINLINE
  declarations, a call within the file being compiled to a named
  function which is defined in that file refers to that function.
  (This permits "block compilation" of files.)  The behavior of
  the program is unspecified if functions are redefined individually 
  at run time.
  
- The compiler may assume that the argument syntax and number of return
  values for all built-in Common Lisp functions will not change.  In
  addition, the compiler may treat all built-in Common Lisp functions
  as if they had been proclaimed INLINE.
  
- The compiler may assume that the argument syntax and number of return
  values for all functions with FTYPE information available at
  compile time will remain the same at run time.

% Reference:  CLtL page 69
- The compiler may assume that symbolic constants that have been
  defined with DEFCONSTANT in the compile time environment will retain
  the same value at run time as at compile time.  The compiler may replace
  references to the name of the constant with the value of the constant,
  provided that such "copies" are EQL to the object that is the
  actual value of the constant.
 
% The following paragraph from issue COMPILE-ENVIRONMENT-CONSISTENCY
%    seems likely to change:
 
- The compiler can assume that type definitions made with DEFTYPE 
  or DEFSTRUCT in the compile time environment will retain the same 
  definition in the run time environment.  It may also assume that
  a class defined by DEFCLASS in the compile time environment will
  be defined in the run time environment in such a way as to have
  the same superclasses and metaclass.  This implies that
  subtype/supertype relationships of type specifiers will not 
  change between compile time and run time.  (Note that it is not 
  an error for an unknown type to appear in a declaration at
  compile time, although it is reasonable for the compiler to 
  emit a warning in such a case.)

% Ref:  CLtL page 153
- The compiler may assume that if type declarations are present
  in the compile time environment, the corresponding variables and 
  functions present in the run time environment will actually be of
  those types; otherwise, the run time behavior of the program is 
  undefined.

The compiler *must not* make any additional assumptions about
consistency between the compile time and run time environments.  In 
particular:

- The compiler may not assume that functions that are defined
  in the compile time environment will retain the either the
  same definition or the same signature at run time, except in the
  situations explicitly listed above.

- The compiler may not signal an error if it sees a call to a
  function that is not defined at compile time, since that function
  may be provided at run time.



File Compilation
================

The function COMPILE-FILE performs compilation processing (described
in the previous section) on forms appearing in a file, producing an
output file which may then be loaded with LOAD.

Normally, the top-level forms appearing in a file compiled with
COMPILE-FILE are executed only when the resulting compiled file is
loaded, and not when the file is compiled.  However, it often happens
that some forms in the file must be evaluated at compile time in order
for the remainder of the file to be read and compiled correctly; for
example, forms that change the values of *PACKAGE* or *READTABLE* and
macro definitions.  In such cases, the distinction between processing
that is performed at compile time and processing that is performed at
load time becomes important.

The special form EVAL-WHEN can be used to give explicit control over
the time at which evaluation of a top-level form takes place, allowing
forms to be executed at compile time, load time, or both.  The
behavior of this construct may be more precisely understood in terms
of a model of how COMPILE-FILE processes forms in a file to be
compiled.

Successive forms are read from the file by the file compiler using
READ. These top-level forms are normally processed in what we call
`not-compile-time' mode; in this mode, the file compiler arranges for
forms to be evaluated only at load time and not at compile time.
There is one other mode, called `compile-time-too' mode, in which
forms are evaluated both at compile and load times.

Processing of top-level forms in the file compiler works as follows:

* If the form is a macro call, it is expanded and the result is
  processed as a top-level form in the same processing mode
  (compile-time-too or not-compile-time).

* If the form is a PROGN form, each of its body forms is
  sequentially processed as top-level forms in the same processing
  mode.

* If the form is a LOCALLY, MACROLET, or SYMBOL-MACROLET,
  the file compiler makes the appropriate bindings and recursively
  processes the body forms as an implicit top-level PROGN with those 
  bindings in effect, in the same processing mode.  (Note that this
  implies that the lexical environment in which top-level forms are
  processed is not necessarily the null lexical environment.)

* If the form is an EVAL-WHEN form, it is handled according to
  the following table:

  COMPILE LOAD EVAL compile-time-too  Action
   
     Yes   Yes  --     --             Process body in compile-time-too mode
     No    Yes  Yes    Yes            Process body in compile-time-too mode
     No    Yes  Yes    No             Process body in not-compile-time mode
     No    Yes  No     --             Process body in not-compile-time mode
     Yes   No   --     --             Evaluate body
     No    No   Yes    Yes            Evaluate body
     No    No   Yes    No             do nothing
     No    No   No     --             do nothing

  "Process body" means to process the body (using the procedure 
  outlined in this subsection) as an implicit top-level PROGN.
  "Evaluate body" means to evaluate the body forms as an implicit
  PROGN in the dynamic execution context of the compiler and in the
  lexical environment in which the EVAL-WHEN appears.

* Otherwise, the form is a top-level form that is not one of the
  special cases.  If in compile-time-too mode, the compiler first
  evaluates the form and then performs normal compiler processing
  on it.  If in not-compile-time mode, only normal compiler
  processing is performed.  Any subforms are treated as non-top-level
  forms.

Note that top-level forms are processed in the order in which they
textually appear in the file, and that each top-level form read by the
compiler is processed before the next is read.  However, the order of
processing (including, in particular, macro expansion) of subforms
that are not top-level forms is unspecified.

EVAL-WHEN forms cause compile time evaluation only at top-level.  In
non-top-level locations, both the :COMPILE-TOPLEVEL and :LOAD-TOPLEVEL
situations are ignored and only the :EXECUTE situation is considered.

The following macros make definitions that are typically used during
compilation and are defined to make those definitions available at
both compile time and run time when calls to those macros appear in a
file being compiled.  As with EVAL-WHEN, these compile time
side-effects happen only when the defining macros appear at top-level.

% The specific details of the compile time side effects should go under
% the description of the macro in chapters 6 & 7.
    DEFTYPE
    DEFMACRO
    DEFINE-MODIFY-MACRO
    DEFVAR
    DEFPARAMETER
    DEFCONSTANT
    DEFSETF
    DEFINE-SETF-METHOD
    DEFSTRUCT
    DEFINE-CONDITION
    DEFPACKAGE
    IN-PACKAGE
% These depend on the outcome of issue CLOS-MACRO-COMPILATION
    DEFCLASS
    DEFGENERIC
    DEFMETHOD
    DEFINE-METHOD-COMBINATION
% This depends on the outcome of issue PROCLAIM-ETC-IN-COMPILE-FILE
    DEFPROCLAIM

The compile time behavior of these macros can be understood as if
their expansions effectively include (EVAL-WHEN (:COMPILE-TOPLEVEL)
...) forms.  It is not required that the compile time definition be
made in the same manner as if the defining macro had been evaluated
directly.  In particular, the information stored by the defining
macros at compile time may or may not be available to the evaluator
(either during or after compilation), or during subsequent calls to
COMPILE or COMPILE-FILE.  If the definition must be visible during
compile time evaluation, it should be placed within an explicit
(EVAL-WHEN (:COMPILE-TOPLEVEL) ...) to ensure that it will be fully
defined at compile time.

   Wrong:  (defmacro foo (x) `(car ,x))
    	   (eval-when (:execute :compile-toplevel :load-toplevel)
             (print (foo '(a b c))))

   Right:  (eval-when (:execute :compile-toplevel :load-toplevel)
             (defmacro foo (x) `(car ,x))
             (print (foo '(a b c))))



Compiler/Loader Interface
=========================

% Reference: Issue QUOTE-SEMANTICS

The functions EVAL and COMPILE always ensure that constants referenced
within the resulting interpreted or compiled code objects are EQL to
the corresponding objects in the source code.  COMPILE-FILE, on the
other hand, must produce an output file which contains instructions
tell the loader how to reconstruct the objects appearing in the source
code when the compiled file is loaded.  The EQL relationship is not
well-defined in this case, since the compiled file may be loaded into
a different Lisp image than the one that it was compiled in.  This
section defines a notion of "similarity as constants" which relates
objects in the the compile time environment to the corresponding
objects in the load time environment.

The constraints on constants described in this subsection apply only
to COMPILE-FILE; implementations are not permitted to copy or coalesce
constants appearing in code processed by EVAL or COMPILE.


Terminology
-----------

% Reference:  Issue CONSTANT-COMPILABLE-TYPES

The following terminology is used in this section.

The term "constant" refers to a quoted or self-evaluating constant
or an object that is a substructure of such a constant, not a named
(DEFCONSTANT) constant.

The term "source code" is used to refer to the objects constructed
when COMPILE-FILE calls READ, and additional objects constructed by
macroexpansion during COMPILE-FILE.

The term "compiled code" is used to refer to objects constructed by 
LOAD.

The term "coalesce" is defined as follows.  Suppose A and B are two
objects used as quoted constants in the source code, and that A' and
B' are the corresponding objects in the compiled code.  If A' and B'
are EQL but A and B were not EQL, then we say that A and B have been
coalesced by the compiler.


What may appear as a constant
-----------------------------

An object may be used as a quoted constant processed by COMPILE-FILE
if the compiler can guarantee that the resulting constant established
by loading the compiled file is "similar as a constant" to the
original.

The notion of "similarity as a constant" is not well-defined on all
data types.  Objects of these types may not portably appear as
constants in code processed with COMPILE-FILE.  Conforming
implementations are required to handle such objects either by having
the compiler and/or loader reconstruct an equivalent copy of the
object in some implementation-specific manner; or by having the
compiler signal an error.

For some aggregate data types, being similar as constants is defined
recursively.  We say that an object of these types has certain "basic
attributes", and to be similar as a constant to another object, the
values of the corresponding attributes of the two objects must also be
similar as constants.

This kind of definition has problems with any circular or "infinitely
recursive" object such as a list that is an element of itself.  We use
the idea of depth-limited comparison, and say that two objects are
similar as constants if they are similar at all finite levels.  This
idea is implicit in the definitions below, and applies in all the
places where attributes of two objects are required to be similar as
constants.

% Reference:  issue CONSTANT-CIRCULAR-COMPILATION

Such circular objects may legitimately appear as constants to be
compiled.  More generally, if two constants are EQL in the source code
for a single file being compiled with COMPILE-FILE, the corresponding
constants in the compiled code must also be EQL.

% Reference:  issue CONSTANT-COLLAPSING

However, the converse of this relationship need not be true; if two
objects are EQL in the compiled code, that does not always imply that
the corresponding objects in the source code were EQL.  This is
because COMPILE-FILE is permitted to coalesce constants appearing in
the source code if and only if they are similar as constants, unless
the objects involved are of type SYMBOL, PACKAGE, STRUCTURE, or
STANDARD-OBJECT.


Similarity as constants
-----------------------

Two objects are defined to be "similar as a constant" if and only if
they are both of one of the types listed below and satisfy the
additional requirements listed for that type.

Number

  Two numbers are similar as constants if they are of the same type
  and represent the same mathematical value.
  
Character

  Two characters are similar as constants if they both represent
  the same character.

% Note that this definition has to depend on the results of the
% Character Set proposals.  The intent is that this be compatible with
% how EQL is defined on characters.

Symbol

% Issue COMPILE-FILE-SYMBOL-HANDLING defines how the file compiler
%  and loader handle interned symbols.

  An uninterned symbol in the source code is similar as a constant
  to an uninterned symbol in the compiled code if their print names
  are similar as constants.

Package

  A package in the source code is similar as a constant to a package in
  the compiled code if their names are similar as constants.  Note that
  the loader finds the corresponding package object as if by calling
  FIND-PACKAGE with the package name as an argument.  An error is
  signalled if no package of that name exists at load time.

Random-state

  Let us say that two random-states are functionally equivalent if 
  applying RANDOM to them repeatedly always produces the same 
  pseudo-random numbers in the same order.  
  
  Two random-states are similar as constants if and only if copies of
  them made via MAKE-RANDOM-STATE are functionally equivalent.

  Note that a constant random-state object cannot be used as the "state"
  argument to the function RANDOM (because RANDOM side-effects this
  data structure).

Cons

  Two conses are similar as constants if the values of their respective
  CAR and CDR attributes are similar as constants.

Array

  Two arrays are similar as constants if the corresponding values each
  of the following attributes are similar as constants:

  For 1-dimensional arrays:
  LENGTH, ARRAY-ELEMENT-TYPE, and ELT for all valid indices.

  For arrays of other dimensions:
  ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all valid indices.

  In addition, if the array in the source code is a SIMPLE-ARRAY, then
  the corresponding array in the compiled code must also be a
  SIMPLE-ARRAY.  If the array in the source code is displaced, has a
  fill pointer, or is adjustable, the corresponding array in the
  compiled code is permitted to lack any or all of these qualities.

Hash Table   

  Two hash tables are similar as constants if they meet the following
  three requirements:

  (1) They both have the same test (e.g., they are both EQL hash tables).

  (2) There is a unique one-to-one correspondence between the keys of
      the two tables, such that the corresponding keys are similar as
      constants.

  (3) For all keys, the values associated with two corresponding keys
      are similar as constants.

  If there is more than one possible one-to-one correspondence between
  the keys of the two tables, the results are unspecified.  A conforming
  program cannot use such a table as a constant.

Pathname

  Two pathnames are similar as constants if all corresponding pathname
  components are similar as constants.

Stream, Readtable, Method

  Objects of these types are not supported in compiled constants.

Function

%  Issue CONSTANT-FUNCTION-COMPILATION specifies how the compiler and
%  loader handle constant functions.

Structure, Standard-object

% Reference: issue LOAD-OBJECTS

  Objects of type structure and standard-object may appear in compiled
  constants if there is an appropriate MAKE-LOAD-FORM method defined
  for that type.

  COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
  a constant or as a self-evaluating form, if the object's metaclass is
  STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
  subclass of BUILT-IN-CLASS), or any of a possibly-empty
  implementation-defined list of other metaclasses.  COMPILE-FILE will
  only call MAKE-LOAD-FORM once for any given object (compared with EQ)
  within a single file.

Condition

% This somehow got overlooked.  Are they handled under LOAD-OBJECTS?



Compile Time Error Handling
===========================

% Reference:  Issue COMPILER-DIAGNOSTICS
% The STYLE-WARNING condition needs to be integrated into the section
%     describing the hierarchy of condition types.

Errors and warnings may be issued within COMPILE or COMPILE-FILE.
This includes both arbitrary errors which may occur due to
compile-time processing of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...)  forms
or macro expansion, and conditions signalled by the compiler itself.

Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.

    Examples:
        file open errors
        syntax errors

Conditions of type WARNING may be signalled by the compiler in 
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine 
that a situation with undefined consequences or that would cause
an error to be signalled would result at runtime.

    Examples:
        violation of type declarations
        SETQ'ing or rebinding a constant defined with DEFCONSTANT
        calls to built-in Lisp functions with wrong number of arguments
          or malformed keyword argument lists
        referencing a variable declared IGNORE
        unrecognized declaration specifiers

The compiler is permitted to issue warnings about matters of
programming style as conditions of type STYLE-WARNING.  Although 
STYLE-WARNINGs -may- be signalled in these situations, no 
implementation is -required- to do so.  However, if an 
implementation does choose to signal a condition, that condition 
will be of type STYLE-WARNING and will be signalled by a call to 
the function WARN.

    Examples:
	redefinition of function with different argument list
	calls to function with wrong number of arguments
	unreferenced local variables not declared IGNORE
	declaration specifiers described in CLtL but ignored by 
	  the compiler


Both COMPILE and COMPILE-FILE are allowed to establish a default
condition handler.  If such a condition handler is established,
however, it must first resignal the condition to give any
user-established handlers a chance to handle it.  If all user error
handlers decline, the default handler may handle the condition in an
implementation-specific way; for example, it might turn errors into
warnings.

% Reference:  issue WITH-COMPILATION-UNIT

In some implementations, some kinds of warnings may be deferred until
"the end of compilation"; see WITH-COMPILATION-UNIT.

-------

∂27-Apr-89  1749	CL-Editorial-mailer 	draft of section 4.2    
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 27 Apr 89  17:49:05 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 27 Apr 89 20:48:29 EDT
Date: Thu, 27 Apr 89 20:48 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: draft of section 4.2
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: cl-compiler@sail.stanford.edu, cl-editorial@sail.stanford.edu
In-Reply-To: <8904251534.AA11058@defun.utah.edu>
Message-Id: <19890428004804.4.BARMAR@OCCAM.THINK.COM>

Here are my comments on your draft:

    * If the form is an EVAL-WHEN form, it is handled according to
      the following table:
    
      COMPILE LOAD EVAL compile-time-too  Action

Shouldn't the headings be fixed to use the new keywords?

    Such circular objects may legitimately appear as constants to be
    compiled.  More generally, if two constants are EQL in the source code
    for a single file being compiled with COMPILE-FILE, the corresponding
    constants in the compiled code must also be EQL.

Earlier you gave a specific definition of the term "source code", which
seemed to refer to the top-level forms read by COMPILE-FILE.  "Source
code for a single file" doesn't make sense in this light.  Perhaps "if
two constants contained in source code read from the same source file
are EQL, the corresponding constants in the compiled code must also be
EQL."

    because COMPILE-FILE is permitted to coalesce constants appearing in
    the source code if and only if they are similar as constants, unless
    the objects involved are of type SYMBOL, PACKAGE, STRUCTURE, or
    STANDARD-OBJECT.

I'm not sure what the "unless" means.  This could be saying that when
the objects are of one of these types, the rule for when they may be
coalesced is something other than (and perhaps more leniant than)
"similar as constants".  Or it could be saying that objects of these
types may never be coalesced, even if they are similar as constants.  If
it's the latter case, however, it might be simpler to just incorporate
this into the definition of "similar as constants" (e.g. two non-EQ
symbols are never similar as constants).

                                                barmar

∂10-May-89  1406	CL-Editorial-mailer 	CLOS function description    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 10 May 89  14:06:40 PDT
Received: by ti.com id AA12429; Wed, 10 May 89 16:06:46 CDT
Received: from dsg by tilde id AA26701; Wed, 10 May 89 15:48:55 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 9 May 89  21:11:06 CDT
Message-Id: <2819758328-16389779@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 9 May 89  21:12:08 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu, Bartley@mips.csc.ti.com
Subject: CLOS function description

A few comments on the CLOS functions section of the draft that was
given out at the March meeting:


CALL-NEXT-METHOD [p. 3-56]
  Under "conditions", it says "If CALL-NEXT-METHOD is used in methods
  that do not support it, an error is signalled."  It isn't clear
  whether this is referring to method combinations that don't permit
  CALL-NEXT-METHOD, in which case it should say "... used in methods
  whose method combination does support it ...", or whether it is
  talking about a method that doesn't have a next method, in which case
  it should say "... NO-NEXT-METHOD is invoked" instead of "... an error
  is signalled".

CLASS-NAME [p. 3-60]
  The last line on the page says "The name of the anonymous class is
  NIL."  Shouldn't that be "... of an anonymous ..."?

DEFCLASS, p. 3-68, end of the third line, "method is be" -> "method to be"

DEFGENERIC [p. 3-69]

  "Function-specifier -- (or (and symbol (not null)) list)."
  Since NIL is a list, this type specifier is equivalent to 
  (or symbol list).  Probably should say 
  (or (and symbol (not null)) cons).  
  Likewise for DEFMETHOD on page 3-83.

DEFINE-METHOD-COMBINATION

  Second line on page 3-75:  
	"Predicate -- (function (list) (member t nil))"
  I think that should be "(function (list) boolean)" since there is no
  need to prohibit it from returning a true value other than T.

  On page 3-77, under :ORDER and :REQUIRED, it says "This keyword option
  is a convenience and does not add any expressive power."  It is not
  clear to me what the point of this is.  If the meaning is analogous to
  saying that the function 1+ is a convenience because there is another
  way to do the same thing, then I don't think we want to say that
  everywhere.  Or maybe it is intended to mean something else?

FIND-CLASS [p. 3-92]

  Someone pointed out to me that the CLOS spec doesn't explicitly say
  that (SETF (FIND-CLASS name) NIL) is the way to un-define a class.
  This should be made clearer in the standard.

∂17-May-89  0956	CL-Editorial-mailer 	more CL draft comments  
Received: from Think.COM ([131.239.2.1]) by SAIL.Stanford.EDU with TCP; 17 May 89  09:55:47 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Wed, 17 May 89 12:54:22 EDT
Date: Wed, 17 May 89 12:53 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: more CL draft comments
To: chapman%aitg.dec@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
Message-Id: <19890517165356.0.BARMAR@OCCAM.THINK.COM>

Well, I've finally finished typing in all my comments on the CL draft
that was handed out.  By the way, what ever happened to the April 15
letter ballot?

						barmar

SEQUENCES
---------

General comment #1: Sandra commented about the incorrect function type
specifiers in this section.  There's actually more trouble with
specifying these type specifiers.  In general, they are specified as
something like (function (t t) boolean).  This implies that only
functions that can accept type T arguments may be used as test, key, and
predicate functions.  The actual requirement is only that the key
functions accept all the elements that exist in the selected portions of
the sequences, and that the test functions accept ITEM (if there is one)
and the results of the key functions.  I think the best you can do when
specifying the types of these arguments is to say how many arguments the
specified functions must take, and that the test functions should return
a boolean, but don't try to specify the actual data types of the
arguments and values.

General comment #2: Another problem with the type information for all
the function arguments is that they can also be symbols, according to
the passed cleanup proposal FUNCTION-TYPE:X3J13-MARCH-88.  So, the best
type specifier would be (or function symbol), followed by an English
description of the number of arguments.

General comment #3: The order of the arguments to the two-argument test
functions aren't generally described.

General comment #4: The following wording appears in many of the
descriptions: "{\i Test}, test, and test-not may be executed more than
once, and their side effects can happen in any order."  I found the
place where CLtL says that the order of side effects is unpredictable,
but where did the "more than once" part come from?  I assume that it
means more than once for each sequence element, since the test function
must obviously be executed at least once for each sequence element
processed, but I think it would be best if this were written explicitly.

General comment #5: Nearly all of the examples of destructive functions
use constant arguments.  As is mentioned in some of the entries, the
consequences of using a destructive operation on a quoted or
self-evaluating constant are undefined.  By the way, why is this only
mentioned in SOME of the entries; either it should be in all of the
destructive function descriptions, or it should be in none of them.

General comment #6: In the descriptions of the functions that take a
:KEY argument, a sentence similar to the following usually appears: "The
return value of the KEY function becomes the argument to <function>",
where <function> is the name of the function being described.  It should
say something like "becomes the argument to Predicate", or "becomes the
argument to the Test or Test-not function".

P. 3-216, SUBSEQ, under Notes: In the last sentence, "do not take part
in the operation" would be better as "are not modified".

P. 3-217, COPY-SEQ: In the description, remove the clause "that is
EQUALP to sequence", and add the sentence "The elements of the result
are EQL to the corresponding elements of sequence."  The fact that the
result is EQUALP is not part of the definition of COPY-SEQ, it's merely
a consequence of the definition of EQUALP.  If you want to mention
EQUALP, you can add this to the Notes: "(EQUALP X (COPY-SEQ X)) ->
true".  But since it's already in the Examples, it's not really
necessary.

P. 3-218, LENGTH, under Description: Replace the second paragraph with
"The results are undefined if sequence is a circular list."

P. 3-220, REVERSE,NREVERSE, under Examples: The fourth example is
invalid; the value of STR was created from a self-evaluating form, so
modifying it is not permitted.  It should be preceded by "(setq str
(copy-seq str))".  In the last example, the result specified is likely,
but not required; perhaps it would be wise to add "(probably)" to the
example, or some other similar note.  It would also be nice if the
examples included the use of a list argument, e.g.

	(setq l (list 1 2 3)) -> (1 2 3)
	(nreverse l) -> (3 2 1)
	l -> (1) (possibly)

P. 3-224, CONCATENATE, under Description: The second and third
paragraphs should be combined, and the word "Therefore" should be added
to the beginning of the second sentence of the resulting paragraph.  In
the last paragraph, "can not" should be "cannot".

P. 3-227, MAP, etc: Preface the second sentence with, "Except for MAPC
and MAPL,".  In the middle of the page, where the specific operation of
each function is described, the paragraph on MAPCAR should specifically
mention how the results are accumulated.

P. 3-230, EVERY, etc, under Arguments: The description of the Predicate
is wrong (and contradicts the Description section, which is consistent
with CLtL).  The order of side effects of the predicate are completely
defined by the description.

P. 3-231, EVERY, under Examples: "is true" should be "true" (I've never
seen the "is" used anywhere else).

P. 3-232, REDUCE: In the Values section, replace the entire sentence
with "Object".  The description there now is completely wrong, and
there's actually no more precise description, since REDUCE can return
whatever the function argument returns, which need not be an element of
the sequence (try (reduce #'list "abcdefg")).  In the Description
section, a precise description of the normal operation of this function
needs to be included.  Something like:

    In the normal case, (reduce #'f s) is equivalent to

	  (f ... (f (f (f (elt s 0)
			  (elt s 1))
		       (elt s 2))
		    (elt s 3))
	     ...
	     (elt s (1- (length s))))

P. 3-236, FILL: Under See Also, add NSUBSTITUTE.  Under Notes, add the
following:

	(fill sequence item) \equivalent
	    (nsubstitute-if item (constantly t) sequence)

P. 3-240, REMOVE,etc, under Description, third paragraph: Preface the
first sentence with "By default,".

P. 3-241, REMOVE,etc, under Examples: The last line should be qualified
with a "(possibly)" or "(probably)".

P. 3-243, REMOVE-DUPLICATES, etc., under Description, first sentence:
Replace "an element occuring later in" with "another element occurring
in".  The way it's currently written doesn't describe the :FROM-END T
case.

P. 3-348, SUBSTITUTE,etc., under Examples: The examples of NSUBSTITUTE-xxx
use a constant sequence argument, which is invalid.  They also don't
bother demonstrating the fact that the actual argument has changed,
which is the point of the Nxxx versions.  Replace them with:

    (setq fboundp-tester (list 'a 'car 'b 'cdr 'c)) -> (A CAR B CDR C)
    (nsubstitute-if "function was here" #'fboundp fboundp-tester
		    :count 1 :from-end t)
    -> (A CAR B "function was here" C)
    fboundp-tester -> (A CAR B "function was here" C)
    (setq alpha-tester (copy-seq "ab ")) -> "ab "
    (nsubstitute-if-not #\z #'alpha-char-p alpha-tester) -> "abz"
    alpha-tester -> "abz"

Note that I also changed the second example to use a string rather than
a list.  I did this because it is more common to do character
manipulation on strings, and because I think it's a good idea to show
sequence functions operating on both arrays and lists frequently.

P. 3-251, FIND,etc, first big paragraph: Preface the first sentence with
"By default,".

P. 3-251, FIND,etc.: In See Also, add POSITION, POSITION-IF,
POSITION-IF-NOT.  In Notes, add

	(find item sequence ...) \equivalent
	   (elt sequence (position item sequence ...))

P. 3-252-3, POSITION,etc.:  See above comments about FIND.  Also, in the
Values section, there should be another set of parentheses around
"(length sequence)".

P. 3-254-5, COUNT,etc.: See above comments about FIND.  Also, much of
the descriptions of all the sequence functions is the same; however, in
this one everything is ordered differently (for example, the fact that
it's an error to supply both Test and Test-not is usually in the
paragraph describing the use of Test and Test-not to override the #'EQL
default).  Why the difference?

P. 3-256-7, MISMATCH: See above comments about FIND.

P. 3-257, MISMATCH, under Examples: The value of the second example (the
:FROM-END T example) is incorrect.  It should be 3.

P. 3-259, SEARCH, under Values: There should be another set of parentheses around
"(length sequence)".

P. 3-259-60, SEARCH, under Description: See above comments about FIND.

P. 3-264-5, MERGE: The first sentence says that this is destructive, but
it doesn't say which of the arguments it might modify.  CLtL doesn't
specify, so I think it would be safe to specify that both sequence
arguments may be modified.  Also, the Side Effects section doesn't say
that the sequence arguments may be modified.

P. 3-265, MERGE, under Examples: I don't think it's really necessary to
include the (SETQ *PRINT-ARRAY* T) line.  The function returns the
specified value no matter how that variable is set.

LISTS
-----

P. 3-266-7, CAR, CDR: I don't like the fact that the argument is called
"list".  CAR and CDR are used on arbitrary data structures made up of
conses and NILs, which don't necessarily represent lists.  It would be
better to say "(or cons null)".  In the fourth paragraph of
Description (the one beginning with "If list is not ()"), the third
sentence is superfluous.  And the last paragraph of Description should
be moved to the Notes section.

P. 3-269, CONS: The second sentence of the Description is unnecessary
and misleading; CONS is used for constructing conses, while LIST is
usually used for constructing lists.  If you want to put something in
the Notes section about how CONS is used to build a new list by
prepending an element to an existing list, that's OK, but it doesn't
belong in the Description.

P. 3-271, TREE-EQUAL, under Examples: The last example is incorrect.
Whether or not EQ returns true for small integers is
implementation-dependent.  Use symbols for this example.

P. 3-284, LAST: Under Arguments, I think this is the only place where
you've specified the default for an optional argument in the Arguments
section; in all other entries, the default is described in the
Description.  In the Description, "last n conses" should be
"nth-from-last cons", and "not the last n elements" should be
parenthesized.  In the Notes, fix the indentation of the code.

P. 3-286, LIST, LIST*: Under Description, in the last sentence, "not a
cons" should be in parentheses, and it should be "not necessarily a
cons" (since it would be a cons if object were a cons).  In the
fourth-from-last example, "T" should be "true".

P. 3-289, APPEND, under Description, second sentence: "concatenation of
lists" should be "concatenation of these copies".

P. 3-291, COPY-LIST, under Description, second sentence: Get rid of the
clause "that is EQUAL to list, but not EQ"; this is not part of the
definition, but a consequence of the definitions of COPY-LIST and EQUAL.
You could put it into the Notes section if you want.

P. 3-297, REVAPPEND, under Side Effects: It should say "None", since the
Description says that list-1 is copied, not modified.

P. 3-301, NRECONC: Under Examples, the result of the third example,
"lst1 -> (1 A B C)", is implementation-dependent, since we don't say
precisely how the reversal is done; another potential result is "lst1 ->
(3 2 1 A B C)".  For example, on Symbolics machines, either result is
possible, depending on whether the original LST1 was cdr-coded or not.
Also, there are two "See Also" sections.

P. 3-303, PUSH: Under Description, first sentence, "returns place"
should be "returns the new list".  In the last sentence of the
Description, "any of the place locations" should be "the place
location."

P. 3-305, PUSHNEW, under Description: In the second sentence, "consed"
should be "prepended".  The third sentence should be "PUSHNEW returns
the new list."  In the last sentence, "any of the place locations"
should be "the place location."

P. 3-308, POP, under Description, last sentence: "any of the place
locations" should be "the place location."

P. 3-317, SUBST, etc., under Descrption: It doesn't say that #'eql is
the default Test.

P. 3-319, SUBLIS, NSUBLIS, under Description: Why is this the only entry
that has a paragraph explicitly warning against modifying
self-evaluating forms (I think some entries have it in the Notes
section, but this is the only one with it in the Description)?  Either
this should be in the descrptions of all destructive functions, or it
should only appear in a general location.  Since there are so many
destructive functions, I'd prefer to put it in a general place.

P. 3-321, SUBLIS, NSUBLIS, under See Also: Add SUBST.

P. 3-322-3, MEMBER, etc: Under Description, the default for KEY isn't
described.  Under Examples, the paragraph between the fourth and fifth
example more properly belongs in Notes.  Under See Also, there's a
reference to MEMQ, which doesn't exist in Common Lisp (it was the
MacLisp equivalent to MEMBER).

P. 3-325, ADJOIN, under Description, second paragraph: The default for
KEY isn't specified.  The last sentence should be "The key function
GENERALLY returns a part of its argument."

P. 3-327, UNION, NUNION, under Description: It should say that NUNION is
the destructive version of UNION, and it should say which list may be
modified.

P. 3-340, PAIRLIS, under Side Effects: This should say "None".  The
supplied a-list is not modified; the new elements are prepended to the
front, as if CONS were used.

P. 3-341-2, ASSOC, etc.: Under Description, the sentence added from
ASSOC-RASSOC-IF-KEY is poorly worded.  Under Examples, I don't
understand the example that claims to come from ASSOC-RASSOC-IF-KEY; it
should probably be using the function ASSOC-IF, not ASSOC, but the :key
returns a character, which cannot be given as an argument to EVENP.
If you're looking for an example, here's one:

(setq alist '(("one" . 1) ("2" . 2) ("three" . 3)))
-> (("one" . 1) ("2" . 2) ("three" . 3))
(assoc-if-not #'alpha-char-p alist
	      :key #'(lambda (x) (char x 0)))
-> ("2" . 2)

P. 3-345, RASSOC, etc., under Notes: This should have a sentence about
RPLACA'ing the result, to parallel the first sentence in the Notes from
ASSOC.

NUMBERS
-------

P. 3-360, 1+, 1-, under Notes: Add (1+ x) \equivalent (+ x 1), and add a
sentence about implementors being encouraged to make the performance of
both be the same.

P. 3-361, INCF, DECF, under Description: Since this is describing INCF
and DECF, why does the example in the PUSH-EVALUATION-ORDER stuff use
PUSH?

P. 3-363, CONJUGATE, under Description: The last sentence should be
moved to Notes.

P. 3-370, LOG: Under Description: In the third sentence, why is it only
an error when base is supplied?  Log of 0 is ALWAYS an error.  The fifth
sentence is also wrong; if base is 0, it's an error (actually, CLtL
doesn't specify either of these cases, but there's no mathematical
definition of the log of 0 or a log to the base 0).  Under Notes: the
statement about the result type isn't supported by anything in the
Description section; somewhere in the description it should say that an
implementation may use floating point calculations even if an exact
integer result is possible.

P. 3-372-3, SQRT, ISQRT: Under Examples, there should be an example of
SQRT when given an argument that isn't a perfect square, e.g. before
the (isqrt 12) example, insert "(sqrt 12) -> 3.4641016".  Under Notes,
add: (isqrt x) \equivalent (values (floor (sqrt x))) but it is
potentially more efficient.

P. 3-374, ABS: Under Values, replace "number" with "(real 0 *)".  Under
Description, replace the third through last sentence with:

	If number is complex, the result is a positive real number with
	the same magnitude as number.  The result may be a float even if
	number's components are rational and an exact rational result
	would have been possible.

The formula can be moved to the Notes section.

P. 3-382, ASIN, ACOS, ATAN: Under Arguments, the description of Number1
is wrong; either just say "number", or say: "number (if Number2 is not
supplied); real (if Number2 is supplied)"; the description of Number2
should be "real".  Under Description, fourth paragraph (which describes
ATAN's arguments), third and fifth sentences: "number1" and "number2"
should be interchanged (in CLtL, y is number1 and x is number2).  In the
fourth sentence, "arg number2" should be "number2" in the argument font.

P. 3-386, SINH, etc.: In Figure 3-20: The first three formulas are
missing several "e"s; the ones that are raised to negative powers are
missing.  In the last three formulas, the radical symbol is missing its
horizontal overbar, so it's not clear which parts of the formulas are
inside it.  In the text, there are also some formulas with radical
symbols missing their overbars (gee, I thought TeX was supposed to be
the best formatter for mathematics -- how could it screw these up?).

P. 3-387, SINH, etc., under Description, last two paragraphs: These
paragraphs belong in the Notes; they are suggestions to implementors,
not part of the definition of the functions.

P. 3-389, FLOAT, under Values: Just say "float".

P. 3-390, RATIONAL, RATIONALIZE: Under Arguments, replace it with
"real".  In the Examples, there should be an example that shows the
difference between RATIONAL and RATIONALIZE for the same argument; for
example, on Symbolics (rational .1) -> 13421773/134217728.  Under
Affected By, it should say that RATIONAL is affected by the
implementation.

P. 3-394-6, FLOOR, etc.: Under Description, there's lots of redundancy;
the 10th and 13th paragraphs repeat what was said in the third
paragraph.  Under Notes, replace "floor", "5", and "2" with "func" (in
italics), "x", and "y", respectively, in the textual part (leave the
example part alone).

P. 3-397, MOD, REM, under Values: For MOD, the result is (real 0 *).

P. 3-399, DECODE-FLOAT, etc., under Values:  Wherever you say "xxx or
yyy" you should say "(member xxx yyy)".  In the description of
INTEGER-DECODE-FLOAT's first value, just say "(integer 0 *)"; CLtL is
wrong about the minimum value of this value, because it doesn't account for
denormalized numbers.

P. 3-401, DECODE-FLOAT, etc., under Affected By: How do these constants
"affect" the results of these functions?  The only thing that affects
these functions is the implementation, specifically its representations
for floats.

P. 3-403, COMPLEX, under Notes: "#," should be "#."

P. 3-404, REALPART, IMAGPART: Under Values, "Number" should be "Real".
Under Description, "(* 0 number)" should be "(coerce 0 (type-of
number))".

General Comment #7: In the descriptions of most of the bit-wise logical
functions you are careful to point out that negative integers are
treated as if they are in two's-complement notation.  Why don't they
also say specifically that these functions treat their arguments as if
they were binary?  Perhaps both of these statements should be put in a
more general place, rather than in the description of each function.

General Comment #8: In the Examples of the bit-wise logical functions,
it would be better to use octal or binary instead of decimal.

P. 3-407, LOGAND, etc., under Notes: delete the word "non-negative";
there's no such thing as a negative number of arguments.

P. 3-408-9, BOOLE.  Under Arguments, "can be" should be "must be the
value of".  Under Description, you don't mention that negative numbers
are treated as if they were two's-complement.  In Figure 3-23, on the
second line, "always 1" should be "always -1".

P. 3-411, BOOLE-CLR, etc., under See Also: Replace "logand" with
"boole".

P. 3-422, BYTE, etc., under See Also: Add LDB, DPB, and other functions
that take byte specifiers.

P. 3-423, LDB.  The description is much too terse; it doesn't say what
"extracted part" means.  How about something like:

	LDB returns an integer in which the bits with weights 2↑(s-1)
	through 2↑0 are the same as those in integer with weights
	2↑(p+s-1) through 2↑p, and all other bits 0, where s is
	(byte-size bytespec) and p is (byte-position bytespec).

P. 3-432, RANDOM:  Under Arguments, replace the description of Number
with "(real 0 *)".  Under Description, there's a cross-reference to
CLtL; this should be moved to Notes, since it's an implementation
suggestion, not a definitional element.

P. 3-434, *RANDOM-STATE*, under Description: The first paragraph is
wrong.  Replace it with "The value of *RANDOM-STATE* is the default
random-state used by RANDOM and MAKE-RANDOM-STATE.

∂26-May-89  1232	CL-Editorial-mailer 	Re: CONFORMANCE-POSITION     
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 26 May 89  12:32:48 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 26 May 89 15:32:21 EDT
Date: Fri, 26 May 89 15:32 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Re: CONFORMANCE-POSITION  
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: <1Md9G7@SAIL.Stanford.EDU>
Message-Id: <19890526193213.3.BARMAR@OCCAM.THINK.COM>

    Date: 25 May 89  1039 PDT
    From: System Files <SYS@sail.stanford.edu>

    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
    Date: Thu, 25 May 89 11:34:34 MDT

    > Processor: A system or mechanism that accepts code as input, prepares
    > it for execution, and executes the process so defined with data to produce
    > results.

    This doesn't make sense.  What "process so defined"?  Defined where?
    Is this referring to the process or algorithm embodied in the code, or
    to the process of evaluating the code that is specified in the
    standard?  If the latter is the intent, I'd suggest some wording like
    "executes it as specified in the standard" instead.  Where does the
    data come from?  Finally, some code may have no observable results or
    side-effects. 

The confusing wording is trying to define a general term that refers to
the various potential combinations of hardware, OS, interpreters,
compilers, runtime systems, etc., that are needed in order to execute
code.

Saying "executes it as specified in the standard" would not be
appropriate here.  "as specified in the standard" is not necessary for a
processor in general, it's only a requirement on a CONFORMING processor.

                                                barmar

∂12-Jun-89  0621	CL-Editorial-mailer 	Re: Issue: EXTRA-RETURN-VALUES    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Jun 89  06:21:49 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA16984; Mon, 12 Jun 89 07:22:12 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA21505; Mon, 12 Jun 89 07:22:10 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8906121322.AA21505@defun.utah.edu>
Date: Mon, 12 Jun 89 07:22:09 MDT
Subject: Re: Issue: EXTRA-RETURN-VALUES
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com, 12 Jun 89 07:52

I don't understand why I/O functions like PRINT and TERPRI should be
permitted to return extra values.  More generally, there is nothing in
the rationale section that explains why any of the functions listed
are permitted to return extra values.  I think this writeup needs
another iteration before it's ready to be voted on. 

-Sandra
-------

∂20-Jun-89  0740	CL-Editorial-mailer 	SYMBOL-MACROLET    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 20 Jun 89  07:39:54 PDT
Received: by ti.com id AA13263; Tue, 20 Jun 89 07:17:41 CDT
Received: from dsg by tilde id AA11382; Tue, 20 Jun 89 07:01:26 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 19 Jun 89  15:00:22 CDT
Message-Id: <2823278540-9339186@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 19 Jun 89  15:02:20 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: CL-editorial@SAIL.Stanford.edu
Subject: SYMBOL-MACROLET

Looking at the description of SYMBOL-MACROLET in the June 12 draft of
chapter 6, I see several problems.

Under "Values" should make clear that the value(s) returned is the value(s)
returned by the last of the body forms.

The sentence taken from LISP-SYMBOL-REDEFINITION is incomplete and hence
misleading.  From looking at what that proposal says about "where
explicitly allowed", the real effect on SYMBOL-MACROLET is:

  The consequences are undefined if a _symbol_ in the COMMON-LISP package
  which is globally defined as a variable or a constant is used as the
  _symbol_ argument.

The second example should be deleted; it is no longer valid as a
consequence of SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM.

Under "Conditions", instead of just saying type ERROR, it seems like this
fits the description of what a PROGRAM-ERROR condition is supposed to be
used for.

There needs to be some reference here to how SYMBOL-MACROLET interacts
with MACROEXPAND.  [I don't have the section on MACROEXPAND to see how
much of this is covered there.]

∂23-Jun-89  0832	CL-Editorial-mailer 	declarations  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Jun 89  08:32:15 PDT
Received: by ti.com id AA10072; Wed, 21 Jun 89 20:02:51 CDT
Received: from Kelvin by tilde id AA27664; Wed, 21 Jun 89 19:56:37 CDT
Message-Id: <2823468963-4322833@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 21 Jun 89  19:56:03 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: CL-Editorial@SAIL.Stanford.edu
Subject: declarations

I was just taking a quick look at the June 12 draft of the
"declarations" section of chapter 6.  I continue to be confused by the
review schedule; the latest version of issue CUT-OFF-DATES that I have
says that this section was to have been voted on 5/14/89, but I see that
it is still in very rough shape, not even really ready for preliminary
review.  Is there a newer schedule somewhere that I should be looking at
to know what is appropriate to review?

Some particular things I noticed:

DECLARE

  Under Arguments, says that the car of decl-spec can be <type>
  [italics], but does not specify what <type> can be.

  The figure that lists forms that may include declarations needs to be
  put into some some kind of comprehensible sort order.  It is difficult
  to check it for completeness as it is.

  The excerpt from issue DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES doesn't
  seem to be in quite the right place.  Seems like it belongs under
  discussion of TYPE declarations.

  The statement that "TYPE declarations can only be bound declarations"
  has been obsoleted by issue DECLARE-TYPE-FREE.

  The statement that "FTYPE and FUNCTION declarations can only be free
  declarations" is contradicted [correctly] later on the same page.

SPECIAL

  The excerpt from issue LISP-SYMBOL-REDEFINITION is incomplete -- where
  is it "explicitly allowed"?

OPTIMIZE

  Does not include the new DEBUG quality from proposal
  OPTIMIZE-DEBUG-INFO:NEW-QUALITY.

PROCLAIM

  Saying that "macros can expand into PROCLAIM forms" seems unnecessary.
  Of course a macro can expand into a function call.

THE

  Fails to specify that the <value-type> argument is not evaluated.

  Should note that a type-error might be signalled if the value does not
  conform to the specified type.

∂04-Jul-89  0910	CL-Editorial-mailer 	issue COMPILED-FUNCTION-REQUIREMENTS   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Jul 89  09:10:38 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA09900; Tue, 4 Jul 89 10:11:07 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA00545; Tue, 4 Jul 89 10:11:04 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907041611.AA00545@defun.utah.edu>
Date: Tue, 4 Jul 89 10:11:03 MDT
Subject: issue COMPILED-FUNCTION-REQUIREMENTS
To: cl-editorial@sail.stanford.edu
Cc: cl-compiler@sail.stanford.edu

I just sent out the amended version of this issue from the last
meeting to X3J13.  However, looking over my notes, it seems like there
is still some confusion over the relationship between issues
COMPILE-ARGUMENT-PROBLEMS and COMPILED-FUNCTION-REQUIREMENTS.  I hope
we can agree to resolve this through the editorial process.

COMPILE-ARGUMENT-PROBLEMS says "it is an error" to pass COMPILE a
function defined in a non-null lexical environment.
COMPILED-FUNCTION-REQUIREMENTS says COMPILE "must" produce a
COMPILED-FUNCTION.  I believe that the only interpretation of this
that is consistent with translating "is an error" to "is undefined" is
that the restriction on what COMPILE produces only applies when it is
passed a valid function to compile.  In other words, we have not
lifted or modified the restriction on user programs that was imposed
in COMPILE-ARGUMENT-PROBLEMS.  This might not be what some people
intended when we voted, but I think it's what the proposals we
actually passed said.

-Sandra
-------

∂06-Jul-89  1205	CL-Editorial-mailer 	COMPLEX type specifier  
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 6 Jul 89  12:05:35 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 6 Jul 89 15:06:03 EDT
Date: Thu, 6 Jul 89 15:04 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: COMPLEX type specifier
To: jonl@lucid.com, cl-cleanup@sail.stanford.edu
Cc: cl-editorial@sail.stanford.edu
Message-Id: <19890706190422.5.BARMAR@OCCAM.THINK.COM>

I'm a little confused by the intention of a portion of the
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING cleanup proposal,
which I noticed when I saw it incorporated into the Working Draft.
Here's the quote:

    (COMPLEX <type>) refers to all complex numbers that can result from 
    giving numbers of type <type> to the function COMPLEX, plus all other 
    complex numbers of the same specialized representation.  Remember that
    both the real and the imaginary parts of any such complex number must 
    satisfy:
                (TYPEP <real-or-imag-part> '<type>). 

The two sentences seem contradictory; perhaps the problem is that the
antecedent of "any such complex number" is ambiguous.  It looks like the
second sentence is saying that

	(typep x '(complex <type>))

implies

	(and (typep (realpart x) '<type>)
	     (typep (imagpart x) '<type>))

But this contradicts the first sentence, which says that the (COMPLEX
<type>) specifier refers to all complex numbers of the upgraded type.
Also, there is no such similar wording in the new ARRAY type specifier
description.

Assuming (upgraded-complex-part-type 'bit) => integer, the first
sentence specifies that

	(typep #c(100 200) '(complex bit)) => true

while the second sentence implies that it is false.

What was the intent of the second sentence?

                                                barmar

∂06-Jul-89  1215	CL-Cleanup-mailer 	Discrimination vs declaration  
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 6 Jul 89  12:15:50 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 6 Jul 89 15:16:33 EDT
Date: Thu, 6 Jul 89 15:14 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Discrimination vs declaration
To: cl-editorial@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Message-Id: <19890706191457.6.BARMAR@OCCAM.THINK.COM>

Do we or do we not still have a distinction between type specifiers that
may be used for discrimination and those that may be used for
declaration.  In the June 16 Working Draft (the big one that was handed
out in Palo Alto last month), on p.2-36, the sentence "Type specifiers
are used for two different purposes: declaration and discrimination" is
marked for deletion, per issue
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING.  However, on p.2-44
the description of the FUNCTION type specifier says that the list form
can only be used for declaration; this comes from issue FUNCTION-TYPE.

Since FUNCTION-TYPE was passed after
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING, I suppose it has
precedence, so the sentence on p.2-36 should not be deleted (and a
description of the distinction should be added).  In effect, what
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING did was get rid of the
discrimination/declaration distinction for the ARRAY and COMPLEX types,
but not for all types in general.

Does this seem right?

                                                barmar

∂06-Jul-89  1310	CL-Editorial-mailer 	Re: Discrimination vs declaration 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jul 89  13:10:18 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 JUL 89 13:10:52 PDT
Date: 6 Jul 89 13:10 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Discrimination vs declaration
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Thu, 6 Jul 89
 15:14 EDT
To: Barry Margolin <barmar@Think.COM>
cc: cl-editorial@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Message-ID: <890706-131052-9081@Xerox>

"In effect, what
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING did was get rid of the
discrimination/declaration distinction for the ARRAY and COMPLEX types,
but not for all types in general.
"


Yes. The distinction also remains for VALUES, for example.

∂06-Jul-89  1405	CL-Editorial-mailer 	Discrimination vs declaration
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 6 Jul 89  14:05:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 621373; 6 Jul 89 15:36:09 EDT
Date: Thu, 6 Jul 89 15:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Discrimination vs declaration
To: Barry Margolin <barmar@Think.COM>
cc: cl-editorial@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890706191457.6.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890706193553.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 6 Jul 89 15:14 EDT
    From: Barry Margolin <barmar@Think.COM>

    Do we or do we not still have a distinction between type specifiers that
    may be used for discrimination and those that may be used for
    declaration.  

My understanding is that there are no longer any type specifiers that have
different meaning when used for discrimination than when used for declaration.
However, there are still type specifiers that are not allowed to be used
for discrimination (VALUES and the list form of FUNCTION are the two that
come to mind).

"discrimination" = TYPEP
"declaration" = THE plus the TYPE and FTYPE declarations.

∂06-Jul-89  1405	CL-Cleanup-mailer 	COMPLEX type specifier    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 6 Jul 89  14:05:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 621395; 6 Jul 89 16:09:33 EDT
Date: Thu, 6 Jul 89 16:09 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COMPLEX type specifier
To: Barry Margolin <barmar@Think.COM>
cc: jonl@lucid.com, cl-cleanup@sail.stanford.edu, cl-editorial@sail.stanford.edu
In-Reply-To: <19890706190422.5.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890706200913.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 6 Jul 89 15:04 EDT
    From: Barry Margolin <barmar@Think.COM>

    I'm a little confused by the intention of a portion of the
    ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING cleanup proposal,
    which I noticed when I saw it incorporated into the Working Draft.

I think I wrote the first version (v6) of that part, so I'll try to answer.

    Here's the quote:

	(COMPLEX <type>) refers to all complex numbers that can result from 
	giving numbers of type <type> to the function COMPLEX, plus all other 
	complex numbers of the same specialized representation.  Remember that
	both the real and the imaginary parts of any such complex number must 
	satisfy:
		    (TYPEP <real-or-imag-part> '<type>). 

The contorted language here is because there is no :ELEMENT-TYPE argument to
the function COMPLEX.

    The two sentences seem contradictory; perhaps the problem is that the
    antecedent of "any such complex number" is ambiguous.  It looks like the
    second sentence is saying that

	    (typep x '(complex <type>))

    implies

	    (and (typep (realpart x) '<type>)
		 (typep (imagpart x) '<type>))

I agree that this is what the second sentence is saying, and that it is
incorrect.  The second sentence was added by JonL in an attempt to clarify
the first sentence, which was even more unclear at that time than it is
in the current version.  That was a good try, but it turned out not to help.
I think the drafting committee should remove that sentence, rather than
attempting to repair it somehow.

Also the first sentence got broken somewhere along the way.  If you look
at the definition of SUBTYPEP on COMPLEX (later in the same proposal),
(TYPEP <x> '(COMPLEX <type1>)) must imply (TYPEP <x> '(COMPLEX <type2>))
whenever <type1> is a subtype of <type2>, since (COMPLEX <type1>) is a
subtype of (COMPLEX <type2>).  Therefore the first sentence must include
other specialized representations that are "smaller" than the one that
results from giving numbers of type <type> to the function COMPLEX.
Actually the first sentence can be read to include them, but it's
ambiguous, since it can also be read as saying that (COMPLEX <type>)
always refers to just one specialized representation of complex numbers.

Here is one way to redraft it:

  (COMPLEX <type>) is the set of all objects <x> for which the following
  form returns <true>:

    (AND (TYPEP <x> 'COMPLEX)
         (TYPEP (REALPART <x>) (UPGRADED-COMPLEX-PART-TYPE <type>))
         (TYPEP (IMAGPART <x>) (UPGRADED-COMPLEX-PART-TYPE <type>)))

  In other words, (COMPLEX <type>) refers to all the complex numbers in
  any specialized representation that can result from giving numbers of type
  <type> to the function COMPLEX.  (COMPLEX <type>) may refer to more than
  one specialized representation, since it includes all representations
  specialized for any subtype of <type>.

I think the drafting committee should start from this.

Any comments?

∂06-Jul-89  1540	CL-Editorial-mailer 	Editorial ramifications of omitting meta-object protocol   
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 6 Jul 89  15:39:57 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 6 Jul 89 18:40:38 EDT
Date: Thu, 6 Jul 89 18:38 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Editorial ramifications of omitting meta-object protocol
To: cl-editorial@sail.stanford.edu
Message-Id: <19890706223856.8.BARMAR@OCCAM.THINK.COM>

When we were discussing (in March, I believe) whether to try to include
the meta-object protocol in this version of the standard, I mentioned a
concern about whether the CLOS documentation would make sense without
it.  In looking at the current working draft, I can see some general
problems due to its omission.

1) There are references to metafunctions.  For instance, on p.7-195 the
description of SLOT-UNBOUND mentions that it is called by
SLOT-VALUE-USING-CLASS, but that function is not defined by the
standard.

2) There are assumptions that all objects work like STANDARD-OBJECTs.
On the same page, the description of SLOT-VALUE says that SLOT-MISSING
and SLOT-UNBOUND are called if the slot is missing or unbound,
respectively.  However, this is only required if the object is of
metaclass STANDARD-CLASS (this is mentioned in the descriptions of
SLOT-MISSING and SLOT-UNBOUND).

3) There are other meta-assumptions that might be made.  Is it
reasonable to assume that all the CLOS classes specified by the standard
are subclasses of STANDARD-CLASS?  In other words, are conditions,
standard-methods, standard-generic-functions, and method-combinations
all required to be standard-objects?  It's never explicitly specified.
In the case of the CLOS metaclasses this isn't much of a problem,
because users can't do anything portably with them, anyway (although
someone could portably define subclasses of them and write methods that
only use the added slots and methods).  But in the case of CONDITION it
is significant, because the answer implies whether it is valid to use
SLOT-VALUE with a condition object.  Since nothing is said about the
functionality provided by the standard meta-objects there's no reason a
processor couldn't implement them using structures (indeed, this might
be necessary for bootstrapping); since conditions permit multiple
inheritance they obviously can't be structures.  (Actually, is there
anything prohibiting an implementation from allowing multiple
inheritance in STRUCTURE-CLASS, or even making STRUCTURE-CLASS
equivalent to STANDARD-CLASS?).

                                                barmar

∂06-Jul-89  1601	CL-Editorial-mailer 	Section numbers in the standard   
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 6 Jul 89  16:01:06 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 6 Jul 89 19:01:50 EDT
Date: Thu, 6 Jul 89 19:00 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Section numbers in the standard
To: cl-editorial@sail.stanford.edu
Message-Id: <19890706230008.9.BARMAR@OCCAM.THINK.COM>

We may not want to change this at this point, but I've noticed that our
standard is much less liberal in its use of section numbers in the
standard than other standards are.  In general, most standards assign a
section number to every named subsection section.  For instance, in our Section
2.3 (Classes), the subsection Introduction to Classes would be 2.3.1,
Standard Metaclasses would be 2.3.1.1, and Defining Classes would be
2.3.2.  In chapter 6, each name description would be 6.2.n, and each
heading (Syntax, Arguments, etc.) would be 6.2.n.m.

Heavy use of section numbering is useful during the public review
process.  Review comments can refer to section numbers.

However, good section numbering can also be used in other ways.  For
example, when the Symbolics C compiler generates diagnostics it
frequently refers you to the section of the standard that covers the
construct.

Page numbers can be used, but this assumes that everyone will be working
from equivalent printings.  What happens if ANSI decides to allow us to
distribute it online (well, the possibility is so remote that I suppose
it could be ignored)?

                                                barmar

∂07-Jul-89  0255	CL-Editorial-mailer 	COMPLEX type specifier  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jul 89  02:55:11 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA02516g; Fri, 7 Jul 89 02:52:32 PDT
Received: by bhopal id AA04274g; Fri, 7 Jul 89 02:54:45 PDT
Date: Fri, 7 Jul 89 02:54:45 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907070954.AA04274@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: barmar@Think.COM, cl-cleanup@sail.stanford.edu,
        cl-editorial@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 6 Jul 89 16:09 EDT <19890706200913.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: COMPLEX type specifier

Dave, I don't think I added the sentence you refer to -- the second one 
in the paragraph Barry quoted [If I did anything with it, it was to add 
or delete the phrase "Remember that ..."].   More to the point, the last 
version of the proposal I have, dated 8-Oct-88 doesn't have the particular 
wording Barry quoted, which is as follows:

    (COMPLEX <type>) refers to all complex numbers that can result from 
    giving numbers of type <type> to the function COMPLEX, plus all other 
    complex numbers of the same specialized representation.  Remember that
    both the real and the imaginary parts of any such complex number must 
    satisfy:
                (TYPEP <real-or-imag-part> '<type>). 

This looks like a mixture of two different parts of the 8-Oct-88 version.
[If there was a later rewrite, then I'm missing it --  my mail from several 
months around January isn't available right now, due to an unrestored
disk crash].  Anyway, the Oct 8 version reads:

   1. Eliminate references to the distinction ....  Instead, ...
   (COMPLEX <type>) always means all complex numbers that can result by
   giving numbers of type <type> to the function COMPLEX, plus all other
   complex numbers of the same specialized representation.
   . . . 
   3. Change the meaning of (TYPEP <x> '(ARRAY <type>)) to be true if
   and only if <x> is a complex number of the most specialized
   representation capable of  holding parts of type <type>, or if <x> 
   is of any subtype of that representation.  Both the real and imaginary
   parts must satisfy (TYPEP <real-or-imag-part> '<type>).

Possibly the intent of the second sentence of part 3 was:

                  . . . Both the real and imaginary parts must satisfy 
        (TYPEP <real-or-imag-part> (UPGRADED-COMPLEX-PART-TYPE '<type>))

However, even with that fix, I agree that this sentence isn't very clear.
Your wording:

     In other words, (COMPLEX <type>) refers to all the complex numbers in
     any specialized representation that can result from giving numbers of type
     <type> to the function COMPLEX.  (COMPLEX <type>) may refer to more than
     one specialized representation, since it includes all representations
     specialized for any subtype of <type>.

looks good to me, especially the second sentence.  What was missing from 
previous versions was the clear statement that:

    (COMPLEX <type>) may refer to more than
     one specialized representation, since ...

The only pitfall now is whether the phrase  "specialized for any subtype 
of <type>."   will appear to be misleading, since the type also includes
all representations specialized for any subtype of 
(UPGRADED-COMPLEX-PART-TYPE <type>).


-- JonL --

∂07-Jul-89  0300	CL-Cleanup-mailer 	Discrimination vs declaration  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jul 89  03:00:50 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA02523g; Fri, 7 Jul 89 02:58:19 PDT
Received: by bhopal id AA04292g; Fri, 7 Jul 89 03:00:32 PDT
Date: Fri, 7 Jul 89 03:00:32 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907071000.AA04292@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: barmar@Think.COM, cl-editorial@sail.stanford.edu,
        cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 6 Jul 89 15:35 EDT <19890706193553.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Discrimination vs declaration

re: My understanding is that there are no longer any type specifiers that have
    different meaning when used for discrimination than when used for declaration.
    However, there are still type specifiers that are not allowed to be used
    for discrimination (VALUES and the list form of FUNCTION are the two that
    come to mind).

That was certainly the goal.

-- JonL --

∂07-Jul-89  0926	CL-Cleanup-mailer 	COMPLEX type specifier    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 7 Jul 89  09:26:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 621896; 7 Jul 89 12:26:51 EDT
Date: Fri, 7 Jul 89 12:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COMPLEX type specifier
To: Jon L White <jonl@lucid.com>
cc: barmar@Think.COM, cl-cleanup@sail.stanford.edu, cl-editorial@sail.stanford.edu
In-Reply-To: <8907070954.AA04274@bhopal>
Message-ID: <19890707162633.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 7 Jul 89 02:54:45 PDT
    From: Jon L White <jonl@lucid.com>

    the last 
    version of the proposal I have, dated 8-Oct-88 doesn't have the particular 
    wording Barry quoted

He was quoting from the draft documentation handed out at the X3J13 meeting
last week, I believe.  But here is the latest version of the cleanup proposal,
for reference.  The text Barry quoted does appear in here verbatim.  By the
way, all passed cleanup proposals are supposed to be available at arisia.xerox.com.
We keep a local copy at Symbolics to insulate ourselves from network problems,
and probably it would be a good idea to keep a local copy at Lucid as well.

Issue:         ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS

References:    Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
               Functions: TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
                          ARRAY-ELEMENT-TYPE, CLtL p. 291
               The type-specifiers:
                          ARRAY,  SIMPLE-ARRAY,  VECTOR,  SIMPLE-VECTOR
                          COMPLEX

Related Issues: SUBTYPEP-TOO-VAGUE, LIST-TYPE-SPECIFIER

Category:      CHANGE

Edit history:  Version 1, 13-May-88, JonL
               Version 2, 23-May-88, JonL  
                (typo fixes, comments from moon, rearrange some discussion)
               Version 3, 02-Jun-88, JonL  
                (flush alternate proposal ["flush-upgrading"]; consequently,
                 move more of discussion back to discussion section.
               Version 4, 01-Oct-88, Jan Pedersen & JonL
                (reduce discussion, and "cleanup" wordings)
               (Version 5 edit history missing)
               Version 6, 6-Oct-88, Moon
                (fix typos, cover subtypep explicitly, add complex,
                 change name of UPGRADE-ARRAY-ELEMENT-TYPE)
               Version 7, 7-Oct-88, JonL (more name and wording changes)
               Version 8,  8-Oct-88, Masinter (wording, discussion)
               Version 9, 31-Oct-88, JonL (major re-wording to accommodate
		 recent discussion; esp. re-introduce and clarify "upgrading")


Problem description:

 CLtL occasionally draws a distinction between type-specifiers "for
 declaration" and "for discrimination";  see CLtL, section 4.5 "Type 
 Specifiers That Specialize" (p.45 and following)  The phrase 
 "for declaration"  encompasses type-specifiers passed in as the 
 :element-type argument to  MAKE-ARRAY, passed in as the <result-type> 
 argument to COERCE, and used in THE and DECLARE type declarations.  The 
 phrase "for discrimination" refers to the type-specifiers passed in as 
 the <type> argument(s) to TYPEP and SUBTYPEP.

 One consequence of this distinction is that a variable declared to be of 
 type <certain-type>, and all of whose assigned objects are created in 
 accordance with that type, may still have none of its values ever satisfy 
 the TYPEP predicate with that type-specifier.   One type-specifier with 
 this property is  
         (ARRAY <element-type>) 
 for various implementation dependent values of <element-type>.  For
 example, in most implementations of CL, an array X created with an
 element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
 satisfy
        (TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
        (TYPEP X '(ARRAY T)) 
 but (almost) never will it satisfy 
        (TYPEP X '(ARRAY (SIGNED-BYTE 5))).

 This is entirely permissible within the scope of standardization on
 MAKE-ARRAY, where an implementation is required only to construct up the
 result out of "the most specialized [element] type that can nevertheless
 accommodate elements of the given type [the :element-type argument]"
 (see CLtL, p287).  That is, an implementation may in fact only provide a 
 very small number of equivalence classes of element-types for storing 
 arrays, corresponding to its repertoire of specialized storage techniques;
 and it is explicitly permitted to "upgrade" any element-type request into 
 one of its built-in repertoire (see also  CLtL, p45, second and third
 paragraphs under Section 4.5.)

 As a practical matter, almost every existing implementation does some 
 serious upgrading of the :element-type argument given to MAKE-ARRAY.  
 Yet the difference between "for declaration" and "for discrimination" 
 has been very confusing to many people.  Similarly, portability is
 hindered when users do not know just how a given implementation does 
 upgrading.
 
 The type specifier (COMPLEX <part-type>) also falls in the  domain of CLtL
 Section 4.5.  Currently, only one implementation actually provides any kind 
 of specialized storage for complex parts; and in this case, the practical
 matter is less urgent, since the kind of upgrading happening is so obvious 
 as to cause little or no confusion.


Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)

 Short Summary:

  ** Eliminate the distinction between type-specifiers "for declaration" and
     "for discrimination".  In short, change the meaning of array and
     complex type specifiers in favor of the "for declaration" meaning.

  ** Change the meaning of TYPEP to be in accord with "for declaration"
     meaning of type-specifiers.

  ** Add an implementation-dependent function that reveals how a given 
     type-specifier for array element-types is upgraded.  Add another such 
     function that reveals how a given type-specifier for complex parts is
     upgraded.

  ** Clarify that "upgrading" implies a movement upwards in the type-
     hierarchy lattice; i.e., if <type> upgrades to <Type>, then
     <Type> must be a super-type of <type>.

  ** Clarify that upgrading an array element-type is independent of any 
     other property of arrays, such as rank, adjustability, fill-pointers, 
     etc.  

  ** Clarify how SUBTYPEP thus behaves on array type-specifiers.  

  ** Define how SUBTYPEP behaves on complex type-specifiers.  

 Note that despite this issue's name, the detailed specifications herein 
 apply to the type system -- not to the behavior of MAKE-ARRAY, nor to how
 arrays are actually implemented.

 Details:

  First, some definitions: Two type-specifiers <type1> and <type2> are said 
  to be "type-equivalent" if and only if each one specifies a subtype of the
  other one.  For example, (UNSIGNED-BYTE 5) and (MOD 32) are two different 
  type- specifiers that always refer to the same sets of things; hence they 
  are type-equivalent.  But (UNSIGNED-BYTE 5) and (SIGNED-BYTE 8) are not 
  type- equivalent since the former refers to a proper subset of the latter.
  Two type-specifiers <type1> and <type2> are said to be "type-disjoint"
  if their specified intersection is null.  For example, INTEGER and FLOAT 
  are type disjoint by definition (see CLtL p.33), and (INTEGER 3 5) and 
  (INTEGER 7 10) are type-disjoint because the specified ranges have no
  elements in common.

 *. Eliminate the distinction between types "for declaration" and "for 
    discrimination".  In particular, elminate any such reference in the 
    discussion of array and complex type-specifiers; this would include 
    documentation patterned after the discussion in section 4.5, pp. 45-7, 
    especially the example on p.46 that says "See ARRAY-ELEMENT-TYPE".
    Change the meaning of (ARRAY <element-type>), as well as any of the
    subtypes of ARRAY (such as SIMPLE-ARRAY, VECTOR, etc.) in favor of the 
    "for declaration" meaning.  Make the similar simplification for the 
    <part-type> specifiers in the COMPLEX type-specifier.

 *. Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is not 
    *, to be true if and only if <x> is an array that could be the result 
    of giving <type> as the :element-type argument to MAKE-ARRAY.  While
    (ARRAY *) refers to all arrays regardless of element type, (ARRAY <type>)
    refers only to those arrays that can result from giving <type> as the
    :element-type argument to the function MAKE-ARRAY.  Change the meanings
    for (SIMPLE-ARRAY <type>) and (VECTOR <type>) in the same way.

    Change the meaning of (TYPEP <x> '(COMPLEX <type>)) similarly.  Thus,
    (COMPLEX <type>) refers to all complex numbers that can result from 
    giving numbers of type <type> to the function COMPLEX, plus all other 
    complex numbers of the same specialized representation.  Remember that
    both the real and the imaginary parts of any such complex number must 
    satisfy:
                (TYPEP <real-or-imag-part> '<type>). 

 *. Add the function UPGRADED-ARRAY-ELEMENT-TYPE of one argument, which
    returns the element type of the most specialized array representation
    capable of holding items of the given argument type.   Note that except
    for storage allocation consequences, it could be defined as:

      (DEFUN UPGRADED-ARRAY-ELEMENT-TYPE (TYPE)
        (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))

    Since element-type upgrading is a fundamental operation implicit in 
    almost every existing implementation of MAKE-ARRAY, the purpose of this 
    added function is primarily to reveal how an implementation does its
    upgrading.

    Add the function UPGRADED-COMPLEX-PART-TYPE of one argument that
    returns the part type of the most specialized complex number
    representation that can hold parts of the given argument type.

 *. Clarify that "upgrading" implies a movement upwards in the type-
    hierarchy lattice.  Specifically, the type-specifier <type> must be
    a subtype of (UPGRADED-ARRAY-ELEMENT-TYPE '<type>).  Furthermore, if 
    <type1> is a subtype of <type2>, then:
            (UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)
    must also be a subtype of:
            (UPGRADED-ARRAY-ELEMENT-TYPE '<type2>).  
    Note however, that two type-disjoint types can in fact be upgraded into 
    the same thing.

    Clarify that ARRAY-ELEMENT-TYPE returns the upgraded element type
    for the array; in particular, any documentation patterned after 
    the sentence on p. 291 begining "This set may be larger than the 
    set requested when the array was created; for example . . ." should
    be embellished with this clarification.

    Similarly, the type-specifier <type> must be a subtype of 
    (UPGRADED-COMPLEX-PART-TYPE <type>).

 *. Clarify that upgrading an array element-type is independent of any 
    other property of arrays, such as rank, adjustability, fill-pointers, 
    displacement etc.  For all such properties other than rank this should 
    be obvious (since they are not expressible in the language of 
    type-specifiers); but note that unless it is also independent of rank, 
    it would not be consistently possible to displace arrays to those of 
    differing rank.

 *. Clarify that SUBTYPEP on ARRAY type-specifiers is as follows:  

    For all type-specifiers <type1> and <type2> other than *, require 
    (ARRAY <type1>) and (ARRAY <type2>) to be type-equivalent if and only 
    if they refer to arrays of exactly the same specialized representation; 
    and require them to be type-disjoint if and only if they refer to arrays 
    of different, distinct specialized representations.  This definition
    follows that implicitly prescribed in CLtL.

    As a consequence of the preceding change to TYPEP and of the definition 
    of UPGRADED-ARRAY-ELEMENT-TYPE, the two type specifiers 
                (ARRAY <type1>)  and 
                (ARRAY <type2>)
    are type-equivalent if and only if
                (UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)  and
                (UPGRADED-ARRAY-ELEMENT-TYPE '<type2>) 
    are type-equivalent.  This is another way of saying that `(ARRAY <type>)
    and `(ARRAY ,(UPGRADED-ARRAY-ELEMENT-TYPE '<type>)) refer to the same
    set of specialized array representations.

    This defines the behavior of SUBTYPEP on array type-specifiers; namely:
                (SUBTYPEP '(ARRAY <type1>) '(ARRAY <type2>))
    is true if and only if
                (UPGRADED-ARRAY-ELEMENT-TYPE '<type1>)  and
                (UPGRADED-ARRAY-ELEMENT-TYPE '<type2>)
    are type-equivalent.

 *. Define SUBTYPEP on COMPLEX type-specifiers as follows: 

    For all type-specifiers <type1> and <type2> other than *, 
            (SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>))
    is  T T  if:
      1. <type1> is a subtype of <type2>, or
      2. (UPGRADED-COMPLEX-PART-TYPE '<type1>) is type-equivalent
         to (UPGRADED-COMPLEX-PART-TYPE '<type2>);  in this case,
         (COMPLEX <type1>) and (COMPLEX <type2>) both refer to the 
         same specialized representation.
   The result is  NIL T  otherwise.

 The small differences between the SUBTYPEP specification for ARRAY and 
 for COMPLEX are necessary because there is no creation function for 
 complexes which allows one to specify the resultant part type independently
 of the actual types of the parts.  Thus in the case of COMPLEX, we must 
 refer to the actual type of the parts, although a number can be a member 
 of more than one type; e.g., 17 is of type (MOD 18) as well as of type
 (MOD 256); and 2.3f5 is of type SINGLE-FLOAT was well as FLOAT.
 The form:
     (SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
 must be true in all implementations; but:
     (SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
 is true only in implementations that do not have a specialized array
 representation for single-floats distinct from that for other floats.


Test cases:

 Let <aet-x> and <aet-y> be two distinct type specifiers that are
 definitely not type-equivalent in a given implementation, but for which
 make-array will return an object of the same array type.  This will be
 an implementation dependent search, but in every implementation that
 the proposer has tested, there will be some such types; often,
 (SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.

 Thus, in each case, both of the following forms return T T:

  (subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
            (array-element-type (make-array 0 :element-type '<aet-y>)))

  (subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
            (array-element-type (make-array 0 :element-type '<aet-x>)))

 To eliminate the distinction between "for declaration" and "for
 discrimination" both of the following should be true:

  [A]
   (typep (make-array 0 :element-type '<aet-x>)
          '(array <aet-x>))
   (typep (make-array 0 :element-type '<aet-y>)
          '(array <aet-y>))

 Since (array <aet-x>) and (array <aet-y>) are different names for
 exactly the same set of objects, these names should be type-equivalent.
 That implies that the following set of tests should also be true:

  [B]
   (subtypep '(array <aet-x>) '(array <aet-y>))
   (subtypep '(array <aet-y>) '(array <aet-x>))

 Additionally, to show that un-equivalent type-specifiers that use the
 same specialized array type should be equivalent as element-type
 specifiers, the following type tests should be true:

  [C]
   (typep (make-array 0 :element-type '<aet-y>)
          '(array <aet-x>))
   (typep (make-array 0 :element-type '<aet-x>)
          '(array <aet-y>))


Rationale:

 This proposal legitimizes current practice, and removes the obscure and
 un-useful distinction between type-specifiers "for declaration" and
 "for discrimination".  The suggested changes to the interpretation of
 array and complex type-specifiers follow from defining type-specifiers
 as names for collections of objects, on TYPEP being a set membership
 test, and SUBTYPEP a subset test on collections of objects.


Current Practice:

 Every vendor's implementation that the proposer has queried has a finite 
 set of specialized array representations, such that two non-equivalent 
 element types can be found that use the same specialized array 
 representation; this includes Lucid, Vaxlisp, Symbolics, TI, Franz,
 and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
 tests [A] and [C] part 2; this is a consequence of implementing the
 distinction between "for declaration" and "for discrimination".  Lucid
 and Xerox both pass test [B], and the other implementations fail it.
 The Explorer returns NIL for all six tests in [A], [B], and [C].

 Allegedly, the PCLS implementation does no "upgrading"; each array
 "remembers" exactly the type-specifier handed to the MAKE-ARRAY call
 that created it.  Thus the test cases are not applicable to PCLS,
 since the precondition cannot be met (i.e., find two non-type-equivalent
 type-specifiers that are non-trivially upgraded by make-array).

 Only the TI Explorer offers any specialized representation for complexes;
 part types of SINGLE-FLOAT and DOUBLE-FLOAT are specialized.


Cost to Implementors:

 This proposal is an incompatible change to the current language
 specification, but only a small amount of work should be required in
 each vendor's implementation of TYPEP and SUBTYPEP.

Cost to Users:

 Because of the prevalence of confusion in this area, it seems unlikely
 that any user code will have to be changed.  In fact, it is more likely
 that some of the vendors will cease to get bug reports about MAKE-ARRAY
 returning a result that isn't of "the obvious type".  Since the change
 is incompatible, some user code might have to be changed.


Cost of non-adoption:

 Continuing confusion in the user community.


Benefits:

 It will greatly reduce confusion in the user community.  The fact that
 (MAKE-ARRAY <n> :ELEMENT-TYPE '<type>) frequently is not of type 
 (ARRAY <type>) has been very confusing to almost everyone.  

 Portability of applications will be increased slightly, since
 the behavior of 
     (TYPEP (MAKE-ARRAY <n> :ELEMENT-TYPE <type>) '(ARRAY <type>))
  will no longer be implementation-dependent. 


Esthetics:

 Reducing the confusing distinction between type-specifiers "for
 declaration" and "for discrimination" is a simplifying step -- it is a
 much simpler rule to state that the type-specifiers actually describe
 the collections of data they purport to name.  Thus this is a step
 towards increased elegance.


Discussion:

 This issue was prompted by a lengthy discussion on the Common Lisp
 mailing list.  See for example a series of exchanges started on Thu, 
 17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
 under the subject line of "Types in CL".  See also the exchange started 
 Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
 under the subject line of "TYPEP warp implications"

 Although the types STRING,  BIT-VECTOR,  SIMPLE-STRING, and 
 SIMPLE-BIT-VECTOR are subtypes of the ARRAY type, they are not
 specifically discussed in this proposal.  The reason is that 
 they are not type-specifiers "that specialize", but are merely 
 abbreviations as follows:
   STRING             ==  (VECTOR STRING-CHAR)
   SIMPLE-STRING      ==  (SIMPLE-ARRAY STRING-CHAR (*))
   BIT-VECTOR         ==  (VECTOR BIT)
   SIMPLE-BIT-VECTOR  ==  (SIMPLE-ARRAY BIT (*))
 Thus their semantics could be affected only in an implementation that
 doesn't support a specific "specialized storage" type for arrays of
 bits and vectors of string-chars.  But in fact, every CL implementation 
 must appear to support "specialized storage" for bit-arrays and strings,
 even if it means nothing more than remembering the fact that such an
 array was created with that element-type.  This is required in order
 for strings, bit-vectors,  and bit-arrays to be disjoint datatypes 
 (see CLtL p.34; see also the definitions of BIT-ARRAY and STRING found 
 in CLtL p.293, Section 17.4, and in CLtL p.299.)

 We considered the possibility of flushing the permission to "upgrade";
 for example, it could be made a requirement that:
     (ARRAY-ELEMENT-TYPE (MAKE-ARRAY <n> :ELEMENT-TYPE <type>))
 always be equal to <type> (or, at least type-equivalent to <type>)
 for all valid type specifiers <type>.  This has several problems: it
 increases the storage requirement for many kinds of arrays, and hides
 a relevant part of the underlying implementation for no apparently 
 good reason.  However, it would increase portability, since it would be 
 much more difficult, for example, to write a program that created an
 array with one element-type, say, (UNSIGNED-BYTE 5), but operated on it 
 assuming a non-trivial upgraded element-type, say, (UNSIGNED-BYTE 8).
 Under this proposal, it is valid for an implementation of MAKE-ARRAY 
 to have arrays "remember" the type-equivalence class of the original 
 :element-type argument; such an implementation would satisfy all of 
 the  constraints listed above.

 We considered a suggestion to restrict the set of "known" array element 
 types; this would gain portability at the expense of limiting the 
 language.

 We considered leaving out of the proposal the addition of the two
 functions UPGRADED-ARRAY-ELEMENT-TYPE and UPGRADED-COMPLEX-PART-TYPE.
 But it was noted that every implementation of CL supports exactly
 that functionality somewhere in its implementation of MAKE-ARRAY; and
 exposing this to the user would be a good thing.  Furthermore, the
 existence of at least UPGRADED-ARRAY-ELEMENT-TYPE makes the clarifications
 on "upgrading" and SUBTYPEP implications easier.  Finally, there would
 be no other way at all to pinpoint just how complex parts are upgraded,
 since there is no type information available except for the actual
 types of the parts.

 Since this proposal contains the implication:
     (ARRAY <type1>)  is-type-equivalent-to  (ARRAY <type2>)
     ==> 
      <type1>  is-type-equivalent-to  <type2>
 then the question naturally arises "Does the reverse implication hold?"  
 That is, should two non-EQ but type-equivalent type-specifiers <type1>
 and <type2> always give rise to the same array types?   For example, 
 consider SHORT-FLOAT and SINGLE-FLOAT in an implementation where these 
 are type-equivalent (see CLtL section 2.1.3).  One may desire to implement 
 (ARRAY SHORT-FLOAT) and (ARRAY SINGLE-FLOAT) differently.  Say, for example 
 that the former is packed into 16-bit half-words, whereas the latter is 
 packed into 32-bit words; but for either kind of packing, the result of 
 AREF is an ordinary "single-float".  The whole point of the type-specifier
 to make-array is merely to specify a packing technique for "packed float" 
 arrays.  This "krinkle", however, will not be addressed by the proposal 
 herein; it should simply be remembered that the implication above goes 
 only one way, and is not an "if-and-only-if" link.

∂12-Jul-89  0008	CL-Compiler-mailer 	issue COMPILED-FUNCTION-REQUIREMENTS    
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jul 89  00:08:12 PDT
Received: from masunter.parc.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA19862; Wed, 12 Jul 89 00:07:11 -0700
Received: by masunter.parc.xerox.com
	(5.61+/IDA-1.2.8/gandalf) id AA16577; Wed, 12 Jul 89 00:08:26 PDT
Message-Id: <8907120708.AA16577@masunter.parc.xerox.com>
Date: Wed, 12 Jul 89 00:08:26 PDT
From: <masinter@arisia.Xerox.COM>
To: sandra%defun@cs.utah.edu
Cc: cl-editorial@sail.stanford.edu, cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 4 Jul 89 10:11:03 MDT <8907041611.AA00545@defun.utah.edu>
Subject: issue COMPILED-FUNCTION-REQUIREMENTS

I intended to vote on a proposal that COMPILE must produce a COMPILED-FUNCTION,
and that it isn't an error to pass COMPILE a function defined in a non-null
lexical environment.

In fact, I believe this was explicitly discussed at the meeting. 

Maybe we have to re-clarify again at another meeting, but it seems like
a not to difficult burden to all valid common lisp implementations that
their function "COMPILE" actually work on all things that are called
FUNCTION (especially since there isn't a good way, given a function object,
to decide whether it might be "defined in a non-null lexical environment".)

That is, I think the language we passed for COMPILED-FUNCTION-REQUIREMENTS
supercedes the language in COMPILE-ARGUMENT-PROBLEMS.

Larry

∂12-Jul-89  1046	CL-Compiler-mailer 	Re: issue COMPILED-FUNCTION-REQUIREMENTS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Jul 89  10:46:21 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA03735; Wed, 12 Jul 89 11:46:47 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA06085; Wed, 12 Jul 89 11:46:45 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8907121746.AA06085@defun.utah.edu>
Date: Wed, 12 Jul 89 11:46:43 MDT
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS
To: <masinter@arisia.Xerox.COM>
Cc: sandra%defun@cs.utah.edu, cl-editorial@sail.stanford.edu,
        cl-compiler@sail.stanford.edu
In-Reply-To: <masinter@arisia.Xerox.COM>, Wed, 12 Jul 89 00:08:26 PDT

> Date: Wed, 12 Jul 89 00:08:26 PDT
> From: <masinter@arisia.Xerox.COM>
> 
> I intended to vote on a proposal that COMPILE must produce a COMPILED-FUNCTION,
> and that it isn't an error to pass COMPILE a function defined in a non-null
> lexical environment.
> 
> In fact, I believe this was explicitly discussed at the meeting. 

I remember that it was discussed, with lots of argumentation on both
sides, but I don't recall that a consensus was ever reached.  I
suspect that many people on both sides of the issue thought the
proposal resolved this whichever way they wanted it, but the actual
language we voted on says nothing specific.  I don't have a record
that we agreed to further "editorial" clarifications in either my
notes or Mary's minutes.

> Maybe we have to re-clarify again at another meeting, but it seems like
> a not to difficult burden to all valid common lisp implementations that
> their function "COMPILE" actually work on all things that are called
> FUNCTION (especially since there isn't a good way, given a function object,
> to decide whether it might be "defined in a non-null lexical environment".)

Yes, there is such a way.  See the cleanup issue FUNCTION-DEFINITION. 

-Sandra
-------

∂12-Jul-89  1502	CL-Editorial-mailer 	LOOP clarification 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Jul 89  15:02:42 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate id AA21306g; Wed, 12 Jul 89 14:59:24 PDT
Received: by bhopal id AA14248g; Wed, 12 Jul 89 15:01:35 PDT
Date: Wed, 12 Jul 89 15:01:35 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8907122201.AA14248@bhopal>
To: cl-editorial@sail.stanford.edu
Cc: rpg@lucid.com, moon@symbolics.com, masinter.pa@xerox.com, gls@think.com,
        jonl@lucid.com
Subject: LOOP clarification

Both Dick Waters and I think this "clarification" is ok.

-- JonL --

Date: Tue, 11 Jul 89 15:25:40 EST
From: Jon L White <jonl>
To: goldman@vaxa.isi.edu
Cc: cl-iteration@sail.stanford.edu, jonl
In-Reply-To: goldman@vaxa.isi.edu's message of Mon, 10 Jul 89 13:43:56 PST <8907102144.AA27056@vaxa.isi.edu>
Subject: Common Lisp LOOP construct

re: [type declarations for the USING variable in hash-table syntax]
    It looks like whichever variable gets relegated to the USING clause
    can't be given a type specifier.  Have I missed something?

Sigh, no Neil, it looks like "we" missed something. 

What would you think of having an optional type-spec for the USING
variables in the FOR/AS syntaxes 6 and 7?  [see X3J13/89-004, p2-13].
The bnf for USING parts would then look like:

  [USING ({HASH-KEY | HASH-VALUE} <other-var> [type-spec])]

This would, of course, also apply to the package iterators.


-- JonL --

∂18-Jul-89  1419	CL-Editorial-mailer 	comments on 5.1    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 18 Jul 89  14:19:15 PDT
Received: by ti.com id AA11099; Tue, 18 Jul 89 16:19:30 CDT
Received: from Kelvin by tilde id AA14928; Tue, 18 Jul 89 16:12:01 CDT
Message-Id: <2825788353-5198108@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 18 Jul 89  16:12:33 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: chapman@aitg.enet.dec.com
Cc: CL-Editorial@SAIL.Stanford.edu
Subject: comments on 5.1


Editorial comments on the draft of section 5.1 dated June 21, 1989:

Page 5-6, under the heading "Creating Conditions, 4th paragraph, 1st
sentence, beginning "If an object ...", in
  "... keyword argument named :  <slot-name> ..."
should close the space after the colon.  On the next line (still the 1st
sentence), the notation "CONDITION-<slot-name>" is confusing; shouldn't
"condition" be in italics like "slot-name" instead of typewriter font?

Page 5-8, at the end of the section headed "Creating Conditions", says
"Signalling a condition that is a subtype of the type serious-condition
does not force entry into the debugger."  This sentence by itself seems
more confusing than helpful.  Presumably the point is that the debugger
is entered as a consequence of calling ERROR rather than just SIGNAL,
but that is explained better on the next page under "Signalling".

Figure 5-2, "Condition system data type tools", since all of the names
listed are slot reader functions, why not say so?

Page 5-10, under the heading "Establishing Handlers", "The same handlers
could be created ..." implies that the use of HANDLER-BIND and
HANDLER-CASE are interchangeable ways to do the same thing, which is
promoting a misconception.  If I understand this correctly, there is a
significant difference between the two:  the handlers defined by
HANDLER-BIND are invoked within the dynamic context of the point where
the condition was signalled, while the clauses of HANDLER-CASE are
invoked after execution of the body has been aborted.  Thus,
HANDLER-CASE cannot be used to invoke restarts defined within the body.

Later under that same heading, "The macro IGNORE-ERRORS can be used
prevent entering ...", insert "to" after "used".  Also, shouldn't it be
mentioned here that this ignores conditions of type ERROR, but not other
SERIOUS-CONDITIONs?

Figure 5.4, "Condition handling tools", DEFINE-CONDITION and
MAKE-CONDITION seem out of place here.  MAKE-CONDITION is more closely
related to "Condition signalling tools", but I admit that it isn't clear
where else DEFINE-CONDITION should go.  Well, it is mentioned in the
section "Condition System Data Types", so maybe it doesn't need to be in
one of the figures.

∂08-Aug-89  1615	CL-Editorial-mailer 	CL standard -- stylistic comments 
Received: from Think.COM ([131.239.2.1]) by SAIL.Stanford.EDU with TCP; 8 Aug 89  16:15:22 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Tue, 8 Aug 89 19:13:30 EDT
Date: Tue, 8 Aug 89 19:11 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: CL standard -- stylistic comments
To: chapman%aitg.dec@decwrl.dec.com
Cc: cl-editorial@sail.stanford.edu
Message-Id: <19890808231107.7.BARMAR@OCCAM.THINK.COM>

I've got a couple of stylistic comments about the formatting of the CL
standard.

1. Lisp symbols should never be broken across lines.  The exact spelling
of a Lisp symbol is important, and it may not always be clear whether
the hyphen at the end of the line is actually in the name of the symbol
or is just there because of the splitting.

2. Widows.  There are widows all over the place.  I'm mostly thinking of
subsection headings that are immediately follows by a page break.  I
think at least one line of the text should be on the same page as the
heading, otherwise the heading should be pushed to the next page.  Also,
there are some itemizations of the form:

	1. Thing1
	   Text about Thing1
	2. Thing2
	   Text about Thing2
	...

and I don't think a page break should be permitted between a ThingN and
the corresponding text.

3. Lisp widows.  Lisp forms should not be broken across page boundaries.
It is important to be able to see the indentation in Lisp code, to be
able to tell which forms line up, and this is impossible to do if the
code is split up.  Page breaks are OK between examples, but not in the
middle of one.

TeX is supposed to be one of the most powerful text formatters around,
so I hope it has ways to let you fix these things.  1 and 3 seem like
they should be easy to fix (for 1, you already have a macro you use for
Lisp symbols, so you could just add the non-hyphenation operator to its
definition), but 2 might be more complicated (most formatters I know of
that prevent widowing have it built into the formatter, as it might be
very difficult for macros to do).

By the way, I never saw any response from you regarding my message about
section numbering.  Did you think it was a good idea?  Does it have any
chance of getting implemented?  Do ANSI's guidelines for standards
document format say anything regarding section numbering?

                                                barmar

∂08-Aug-89  1631	CL-Editorial-mailer 	Re: CL standard -- stylistic comments  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 8 Aug 89  16:31:32 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.2-cs)
	id AA22823; Tue, 8 Aug 89 17:29:35 -0600
Received: by defun.utah.edu (5.61/utah-2.2-leaf)
	id AA04270; Tue, 8 Aug 89 17:29:31 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8908082329.AA04270@defun.utah.edu>
Date: Tue, 8 Aug 89 17:29:28 MDT
Subject: Re: CL standard -- stylistic comments
To: Barry Margolin <barmar@Think.COM>
Cc: chapman%aitg.dec@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: Barry Margolin <barmar@Think.COM>, Tue, 8 Aug 89 19:11 EDT

I agree that having more numbered subsections would make things easier to
locate.  Related to that, it would be helpful if cross-references to
material in other sections included the section number as well as the
name of the section.  

-Sandra
-------

∂21-Aug-89  1116	CL-Editorial-mailer 	CL standard -- stylistic comments 
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 21 Aug 89  11:15:41 PDT
Received: from fafnir.think.com by Think.COM; Mon, 21 Aug 89 14:15:54 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 21 Aug 89 14:13:26 EDT
Received: by verdi.think.com; Mon, 21 Aug 89 14:13:15 EDT
Date: Mon, 21 Aug 89 14:13:15 EDT
From: gls@Think.COM (Guy Steele)
Message-Id: <8908211813.AA01978@verdi.think.com>
To: barmar@Think.COM
Cc: chapman%aitg.dec@decwrl.dec.com, cl-editorial@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 8 Aug 89 19:11 EDT <19890808231107.7.BARMAR@OCCAM.THINK.COM>
Subject: CL standard -- stylistic comments

   Date: Tue, 8 Aug 89 19:11 EDT
   From: Barry Margolin <barmar@Think.COM>

   I've got a couple of stylistic comments about the formatting of the CL
   standard.

I faced these problems doing CLtL.

   1. Lisp symbols should never be broken across lines.  The exact spelling
   of a Lisp symbol is important, and it may not always be clear whether
   the hyphen at the end of the line is actually in the name of the symbol
   or is just there because of the splitting.

CLtL follows a rule that a line may be broken at an existing hyphen
in a Lisp symbol, but to prevent ambiguity it is therefore never
permissible to introduce a hyphen that wasn't there.  The TeX hackery
for this is pretty simple (but on another computer right now, so I'll
have to mail it separately).

   2. Widows.  There are widows all over the place.  I'm mostly thinking of
   subsection headings that are immediately follows by a page break.  I
   think at least one line of the text should be on the same page as the
   heading, otherwise the heading should be pushed to the next page.  Also,
   there are some itemizations of the form:

	   1. Thing1
	      Text about Thing1
	   2. Thing2
	      Text about Thing2
	   ...

   and I don't think a page break should be permitted between a ThingN and
   the corresponding text.

Again, careful attention in the macros to putting \penalty 10000 or
equivalent in the right places will solve this problem.

   3. Lisp widows.  Lisp forms should not be broken across page boundaries.
   It is important to be able to see the indentation in Lisp code, to be
   able to tell which forms line up, and this is impossible to do if the
   code is split up.  Page breaks are OK between examples, but not in the
   middle of one.

CLtL has page breaks in the middle of some examples, but in places
I have explicitly permitted (such as between COND clauses of the
outermost COND).

   TeX is supposed to be one of the most powerful text formatters around,
   so I hope it has ways to let you fix these things.  1 and 3 seem like
   they should be easy to fix (for 1, you already have a macro you use for
   Lisp symbols, so you could just add the non-hyphenation operator to its
   definition), but 2 might be more complicated (most formatters I know of
   that prevent widowing have it built into the formatter, as it might be
   very difficult for macros to do).

   By the way, I never saw any response from you regarding my message about
   section numbering.  Did you think it was a good idea?  Does it have any
   chance of getting implemented?  Do ANSI's guidelines for standards
   document format say anything regarding section numbering?

						   barmar