KMP's CL References
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.
First publication and Copyright 2002 by Kent M. Pitman. All Rights Reserved.