KMP's Notes on FAILED Issue DEFSYSTEM

This is the literal text of KMP's personal notes on failed issue DEFSYSTEM. Dates shown are the dates of creation of the notes, sometimes accompanied by the version of this issue to which the notes refer.

Note that in some cases there are endorsements included here by particular individuals or organizations. Those endorsements were made by those individuals or organizations in the context of the time and are retained here for the sake of the historical integrity of the document. Those individuals or organizations might not still endorse this proposal more than a decade later; for example, in some cases alternate solutions have arisen that they might prefer.

These notes are part of no official record. They have no official standing.

DEFSYSTEM (Version 4, 19-Mar-91)
 Author:   Pitman
 Forum:    Cleanup
 Status:   Rejected 1-13, Mar-91
 Comments: ----- Pitman 15-Mar-91 -----
	   Doug Rand (MITRE) is the only person to respond to this so far.
	   He strongly endorsed the idea.
           ----- Pitman 19-Mar-91 (version 3) -----
           Brian Anderson and Stephen Nicoud (Boeing) support the idea of
	   a DEFSYSTEM but wish it went further.  Versioning, distribution, ...
	   the whole product packaging concept.
           ----- Pitman 19-Mar-91 (version 4) -----
	   This version, including SWM's new amendment, looks ok to me and SWM
	   (both options NEW-FACILITY and +SUPPORT-DEPENDENCIES).
           ----- Pitman 05-Apr-91 (Mar-91 meeting) -----
	   In the discussion, there were several common themes:
	      - Common Lisp is already too big.  My take on this was that some people
		felt that voting no here would send a clear message that we meant
		business about not adding any more features.
		[Personally, I don't think CL will ever win a smallness award, so 
		 this seems silly to me.  If CL is going to win any battle for
		 supremacy, it will be on the basis of a large library of powerful
		 tools the presence of which saves people from writing and debugging
		 the same code over and over on a per-application basis.]
	      - Doing this is risky.  No one actually implements the proposal,
		so if something is wrong in it, we'll be stuck with it.
		[For the short term, we still have at least six months in which
		 bugs can be noticed and trivially fixed.  And for the long term,
		 I categorize the level of risk associated with add-ons like this
		 as virtually zero since its presence doesn't preclude either 
		 implementors or users from providing something better if it
		 doesn't work.  But at least it has a strongly normative effect if
		 it does work--for example, in a next generation standard we would
		 surely all be experts and would be sure to get it fixed.  As it is,
		 we'll now go into a next generation standard still disputing whether
		 a lisp-based DEFSYSTEM or a shell-based Make is the right answer.]
	       - Doing this might delay the standard.
		 [This is unfounded paranoia.  This is a couple of pages or so of 
		  description.  The standard is many hundreds of pages.  This is a 
		  drop in the bucket compared to the overall editing task, and its
		  presence or absence is not likely to make a noticeable difference
		  in the ability to get the standard out to public review `on time'.]
	   I heard no specific technical objections.  The objections seemed to be
	   largely issues of form and process.  I did note the following comments
	   (none direct quotes):
	    Gregor -- Worry that we can't resolve issues in time...
	    Sandra Loosemore (Sandra at Chestnut) -- Concern about lateness of the proposal...
	    Moon -- Excellent proposal technically, but...
	    RWK - Contributes nothing but a standard way to do things...
	    Weyrauch (note: no voting status) -- Issue of foreign functions is
	      more important...
	    SMH -- OK, but needs more work...
	   After a few minutes of discussion, RPG called the question.  
	   The proposal was rejected on a vote of 1-13.  We [Symbolics]
	   offered the only Yes vote.