marick@ccvaxa.UUCP (12/15/85)
This is a bowdlerized version of my trip report from the Common Lisp meeting, held in Boston Dec 9-11, 1985. Both my memory and note-taking are imperfect, so what's written below may not be exactly what happened. At this meeting, the various issues were discussed: standardization, validation, a USC-ISI Common Lisp framework, and language extensions for error handling, object-oriented programming, and windowing. Miscellany: Guy Steele passed out several pages of varia for Common Lisp, bug fixes and extensions that he was unwilling to unilaterally declare a part of the language. As noted below, there's now a technical committee to rule on such things; I expect most will be approved. Charter and Standardization: This discussion centered around several problems: 1. The Common Lisp book contains errors and ambiguities. There is no formal or semi-formal mechanism for fixing or clarifying them. There is also no mechanism for approving extensions to the definition. 2. Common Lisp is not a standard; it is not blessed by ISO, ANSI, IEEE, etc. This became more pressing, since there has been a proposal to ISO that a Lisp standard be created. Given the number of people who've spent money developing Common Lisp, it sure would be nice if it became the standard. 3. There are numerous services that ought to be provided. (Distribution of public-domain sources and tools, updating the official specification, possibly writing and running a validation suite, etc.) Right now, some are being provided by volunteers, and others are not being provided. Bob Mathis, who headed the ISO standards team for Ada, is already a sort of provisional chair for an ISO "AI languages" standard group. Apparently, it's now easy for him to become the official "convener" of a standards committee. We agreed that he would appoint two committees to oversee the rest of the standards effort: a steering comittee and a technical committee. They would originally consist of the Gang of Five (the five main designers of Common Lisp), Bob Mathis, Steve Squires of DARPA and 2-4 other people. This group of people was also given the responsibility of passing judgement on language questions, with the assumption that their decisions would become part of the standard. They were also directed to "try hard" to propose, within 6 months, a service organization, probably based at USC-ISI. All this will be re-evaluated in six months (over the network). Validation: DARPA will give USC-ISI money to organize and administer a Common Lisp test suite. The tests will be contributed by the vendors. Most of the vendors there volunteered their test suites. Several vendors volunteered to create detailed tests for a particular part of the manual. Most people's test suites are broad but shallow. The actual organization of distributing and running the test suite is still up in the air. The same technical committee used in the standards effort will rule on the language interpretation questions that will inevitably come up. There will be discussion of this on the Common-Lisp-Validation mailing list. Error Handling: Common Lisp, as defined in the aluminum book, has no way of handling errors Among other things, that means you can't write a portable test suite for code that is defined to "signal an error". Kent Pitman of Symbolics has a proposal. It has many of the same features as other exception handling schemes (for example, Mesa): Code may signal a condition. Handlers for that type of condition are given the option of handling it. They may terminate the code, resume it and pass it arguments, or resignal the error. Common Lisp ERROR and CERROR are defined in terms of these operations. The proposal has an object-oriented flavor, but does not depend on any particular object system. This proposal, with minor tweaking, should be accepted early next year, after discussion on the Common-Lisp-Error-Handling mailing list. There should be a public-domain implementation in January. Relevant documents: error-proposal.text, by Kent Pitman, and "Exceptional Conditions in Lisp", MIT AI Working Paper 268, Kent Pitman. USC-ISI Common Lisp Framework: This is intended to be an environment for personal workstations; it depends heavily on windows and the like. The entire system is object-oriented in the sense that Lisp objects and their relationships, rather than files of text and their relationships, are the basic stuff of the system. There's no distinction between memory and disk. (I know, I know, Multics did it first N years ago.) Instead of files, you use objects that refer to other objects. There's a lot of emphasis on clerical assistance for programming -- enforcing consistency relationships among system parts and keeping track of tasks. The system is slanted toward single-developer systems. I'd say there's a fair chance it really will be useful to its intended audience. It's used internally now and at beta sites; open distribution will come soon. Xerox PARC is also working on a new generation "residential environment". Object Oriented Programming: Summary: There are several proposals out there; none of the proposers believe that things are so well-understood that a standard right now is a good idea, despite significant pressure from users. There is hope, though: 1. Many of the proposals will be widely available soon. People can start beating on them. (A problem is that object systems are most needed - and are best put to the test - in systems that would be unmanageable without them. That sort of experience is hard to come by.) 2. There are substantial areas of agreement. For example, everyone agrees multiple inheritance is necessary. Most believe that an object-oriented function call should look like an ordinary Lisp function call. It is not clear whether it's best to adopt an entire proposal or find a common subset. The current schedule is for proposers to make portable versions of their systems available as soon as possible, for discussion to take place over the Arpanet, and for another meeting to be held at the Lisp conference in August. Agreement next year is by no means certain. Details: New Symbolics Flavors: Because enough users found Flavors hard to use, Symbolics is revising the design. The new Flavors features easier-to-understand method combination and generic functions instead of message sending. They consider new Flavors too young to make an object oriented programming standard. It's unknown when, if ever, there'll be a portable implementation. Relevant documentation: "Flavors: Object-oriented Programming on Symbolics Computers", by Sonya E Keene and David A. Moon. XEROX Common Loops: Xerox is providing a free portable implementation of Common Loops that can be included in a product. Common Loops features generic functions instead of a message-sending syntax, dispatching off multiple arguments instead of just the first, objects that are defined with defstruct, and metaclasses to control the implementation of instances and to emulate other systems. No new documentation. LMI Object Lisp: This is a distributed part of their product. I got the impression there will be a portable implementation provided, but I'm not sure. No new documentation. HP Common Objects: HP is similar to old Flavors in many ways. (For example, it retains the message-send syntax[tic sugar].) They stress data-hiding and efficient implementation on stock hardware. They may make a portable version available. Common Loops can partially implement Common Objects, but not completely. Relevant Documentation: "Object Oriented Programming for Common Lisp", by Alan Snyder, and "A Common Lisp Objects Implementation Kernel", by Snyder, Creech, and Kempf. Windowing: I had a plane to catch, so I missed some of this. Lucid has a proposal it developed with Intellicorp, which would like to see its systems run on many different machines. The proposal assumes the standard fancy graphics screen with mouse. I didn't take notes on the details. Brian Marick, Wombat Consort Gould Computer Systems -- Urbana ...ihnp4!uiucdcs!ccvaxa!marick ARPA: Marick@GSWD-VMS