Common Lisp meeting report

[mar...@ccvaxa.uucp]

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