Where we stand

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

A progress report from the Technical Committee is overdue.  Here's where
things stand:

First, the technical and steering committees have held electronic
elections.  I have been elected chariman of the technical committee
through the end of 1986.  Bob Mathis has been elected chairman of
the steering committee.  Both of us have the model that the main
function of the chariman is to keep things moving and to moderate the
discussions.  As his messages have indicated, Bob has been moving along
with the process of getting all this organized properly within ANSI and
ISO.

Second, we have been thinking about how to proceed on the technical
side.  Most of us favor a model in which we start with an online version
of the manual.  Issues would be debated on the Common Lisp mailing list
and, when things have settled as much as they are going to, the
technical committee would make a decision.  Each such decision is folded
immediately into the manual, which is available online to everyone.  At
some point we decide we're done and send the document over to ANSI with
our recommondation that this become the new standard for Common Lisp;
ANSI then decides, and we go from there to ISO.  Up to the point where
ANSI makes a decision, all of this is just a set of proposals for a
language spec, though implementaiton groups are free to act on these
recommendations if they choose to.

It would probably be best to use the Digital Press book as the starting
point if we can obtain the necessary rights; an alternative is to start
from a manual Lucid has developed which is meant to describe the same
language, but in different words, if we can obtain the necessary rights
from Lucid.  The worst option is to develop a new docuemnt from scratch
-- a lot of redundant work, plus the likelihood that we will introduce
some new ambiguities.  We need to obtain, from Digital Press or Lucid or
both, the right to create a derivitive work that is intended to be used
as a specification document, while those companies keep the copyright on
their original version.  We are trying to work out exactly who should
own the rights to the revised document.  ANSI normally owns the
copyright on their standards and makes some money selling the documents,
but in this case we are determined that the final document should be
readily available to everyone at a low price and that the text can be
used by companies to create online and printed documents for their own
products without a lot of red tape.  None of us wants to put a lot of
work into this document and then find that someone else controls the use
of it.

As you can imagine, this document situation raises all sorts of
complicated legal issues, and it is going to take us some time to cut
through it all.  Lawyers don't work very fast.  I want to resolve a lot
of the technical issues over the summer and have a document ready for
submission to ANSI by the end of the year, and if we are to meet that
goal we must get moving.  And so, reluctantly, I propose that we begin
trying to resolve issues a few at a time, and that we just record the
decisions in an online file until we have a document that we can start
working on.  This means that we'll need a separate pass later on to
incorporate the decisions into a document, and there is the danger that
we'll inadvertently introduce new bugs at that time, but I see no good
alternative.  We can't wait around any longer.

If people don't object to this plan, we'll get started soon.  I'll begin
by sending out a message proposing some principles about how
conservative we want to be, and when we've got some general agreement
on that we can start on our backlog of issues.

In addition to resolving known problems, especially in the area of code
portability, we must agree on a reasonably complete error system.  It is
not absolutely essential, but I believe it would be very beneficial if
we can agree on a set of object-oriented facilities in time to get them
into this spec.  Progress on iteration, windows/graphics, and standard
subsets would be welcome, but not essential.

-- Scott