perm filename CLEDIT.MSG[COM,LSP]12 blob sn#867873 filedate 1989-01-09 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00059 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00009 00002	∂31-Mar-88  1358	chapman%aitg.DEC@decwrl.dec.com 	editorial subcommittee notes    
C00025 00003	∂03-May-88  0658	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-PROPOSAL-FORMAT    
C00028 00004	∂03-May-88  0909	CL-Editorial-mailer 	Re: EDITORIAL-COMMITTEE-PROPOSAL-FORMAT
C00031 00005	∂03-May-88  1114	CL-Editorial-mailer 	editorial committee meeting  
C00032 00006	∂03-May-88  1118	CL-Editorial-mailer 	EDITORIAL-COMITTEE-STANDARD-REVIEW
C00044 00007	∂03-May-88  1251	CL-Editorial-mailer 	EDITORIAL-COMITTEE-STANDARD-REVIEW
C00049 00008	∂03-May-88  1302	CL-Editorial-mailer 	re:barmar comments 
C00051 00009	∂05-May-88  2216	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-STANDARD-REVIEW    
C00064 00010	∂06-May-88  0934	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-STANDARD-REVIEW    
C00066 00011	∂26-May-88  0728	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-PROPOSAL-FORMAT    
C00069 00012	∂26-May-88  0807	CL-Editorial-mailer 	EDITORIAL-COMMITTEE-STANDARD-REVIEW    
C00072 00013	∂26-May-88  1007	CL-Editorial-mailer 	hard copy
C00075 00014	∂26-May-88  1123	CL-Editorial-mailer 	$$'s for Words
C00077 00015	∂26-May-88  1134	CL-Editorial-mailer 	re: Sonya's comments    
C00081 00016	∂26-May-88  2052	CL-Editorial-mailer 	editorial committee meeting  
C00086 00017	∂10-Jun-88  0909	CL-Editorial-mailer 	standard mailing   
C00088 00018	∂16-Jun-88  1621	CL-Editorial-mailer 	Comments on the snapshot version  
C00092 00019	∂05-Jul-88  1129	CL-Editorial-mailer 	Editorial Committee Meetings - June    
C00112 00020	∂19-Jul-88  1046	CL-Editorial-mailer 	just to let you know    
C00114 00021	∂26-Jul-88  0613	CL-Editorial-mailer 	standard mailing   
C00115 00022	∂06-Aug-88  0325	CL-Editorial-mailer 	mailing list change
C00116 00023	∂06-Aug-88  0326	CL-Editorial-mailer 	mailing list change
C00117 00024	∂08-Aug-88  1243	CL-Editorial-mailer 	CL standard   
C00119 00025	∂23-Aug-88  0749	CL-Editorial-mailer 	standard 
C00120 00026	∂23-Aug-88  0907	CL-Editorial-mailer 	standard 
C00122 00027	∂30-Aug-88  0858	CL-Editorial-mailer 	questions
C00125 00028	∂30-Aug-88  1056	CL-Editorial-mailer 	Re: questions 
C00127 00029	∂30-Aug-88  1350	CL-Editorial-mailer 	questions
C00131 00030	∂30-Aug-88  1615	CL-Editorial-mailer 	questions
C00134 00031	∂31-Aug-88  1459	CL-Editorial-mailer 	questions
C00136 00032	∂31-Aug-88  1459	CL-Editorial-mailer 	questions
C00138 00033	∂02-Sep-88  2136	CL-Editorial-mailer 	wording about Symbols   
C00140 00034	∂06-Sep-88  1348	CL-Editorial-mailer 	Notation in standard for function argument/value types
C00143 00035	∂06-Sep-88  1414	CL-Editorial-mailer 	Notation in standard for function argument/value types
C00145 00036	∂06-Sep-88  1450	CL-Editorial-mailer 	Re: Notation in standard for function argument/value types 
C00147 00037	∂06-Sep-88  2131	CL-Editorial-mailer 	Notation in standard for function argument/value types
C00151 00038	∂06-Sep-88  2346	CL-Editorial-mailer 	Re: Notation in standard for function argument/value types 
C00153 00039	∂07-Sep-88  1017	CL-Editorial-mailer 	Audience of the Standard
C00156 00040	∂09-Sep-88  1217	CL-Editorial-mailer 	type specifiers    
C00158 00041	∂12-Sep-88  0843	CL-Editorial-mailer 	committee
C00159 00042	∂12-Sep-88  1037	CL-Editorial-mailer 	Issue: CLOS-:initform-typographical-errors  
C00169 00043	∂19-Sep-88  1439	CL-Editorial-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)   
C00178 00044	∂19-Sep-88  1505	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1) 
C00180 00045	∂19-Sep-88  1542	CL-Cleanup-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
C00191 00046	∂28-Sep-88  1344	CL-Editorial-mailer 	[Robert S. Boyer <boyer@CLI.COM>: Clean Up] 
C00194 00047	∂28-Sep-88  1442	CL-Editorial-mailer 	as if you haven't got enough to review 
C00216 00048	∂28-Sep-88  1707	CL-Editorial-mailer 	as if you haven't got enough to review 
C00226 00049	∂29-Sep-88  1220	CL-Editorial-mailer 	re: barmar comments on error paper
C00238 00050	∂29-Sep-88  1404	CL-Editorial-mailer 	re: barmar comments on error paper
C00250 00051	∂03-Oct-88  1125	CL-Editorial-mailer 	    
C00262 00052	∂03-Oct-88  1233	CL-Editorial-mailer 	October agenda
C00266 00053	∂03-Oct-88  1255	CL-Editorial-mailer 	error definitions  
C00277 00054	∂03-Oct-88  1406	CL-Editorial-mailer 	Error Terminology  
C00279 00055	∂03-Oct-88  1429	CL-Editorial-mailer 	Error Terminology  
C00284 00056	∂04-Oct-88  0951	CL-Editorial-mailer 	barmar questions about error terms
C00287 00057	∂04-Oct-88  1101	CL-Editorial-mailer 	Error Terminology  
C00290 00058	∂04-Oct-88  2041	X3J13-mailer 	Re: error definitions
C00294 00059	∂05-Oct-88  0021	CL-Editorial-mailer 	Re: Error Terminology   
C00296 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".