State of the world

[Dick Gabriel <RPG@SAIL.STANFORD.EDU>]

Here is what Linda and I have been doing to the specification.

1. Settling on terminology. This mostly involves selecting one
out of several different terminologies inserted into the spec
by different people, where the terms refer to the same thing.

2. Making the organization right. In several places material that
belongs in FUNCTIONS ended up in CONCEPTS and vice versa. Sometimes
material was repeated. These were rationalized and pointers back and
forth were placed where appropriate.

3. Clarifying terminology. This mostly happened in places where people
had inserted good terminology without definition or comment on its
use. A good example is ``primary method,'' which is used intuitively
in some places and precisely in others. We put in an explanation of
the use of the term in CONCEPTS. The explanation says that a primary
method is used to refer to a method with an intended role depending on
the method combination type. In standard method combination it means
a certain thing (precisely) as it does when you use the short form (though it
means something slightly different). This way the reader is not jolted
upon reading in standard method combination that a primary method is 
precisely an unqualified method while under the short form he'll read
that some qualified methods are primary. (And without the explanation,
a reader could spend 15 minutes going back and forth among the
various apparent definitions of it).

4. Rationalizing where objects versus names of objects are to be used,
particularly in parameter specializers where one thing is meant in
specialized lambda-lists and another in parameter specializers of a method
object (one needs names and the other needs objects).

5. Incorporating the latest, most final comments of Gregor and Moon.
I'm not sure we've done this completely well, but we did all the comments
through Feb 6.

6. Re-writing sections that were very hard to understand. The worst
part was redefining classes and the change-class protocol, which Moon
put in during the last round. After a number of sessions on the phone
with Danny and Gregor and after a face-to-face with them, I think we
finally have it down reasonably. This re-write impacted number 4 above.

I think that Moon's change-class protocol, though a little obscure, is
now understandable, which means it has some hope of gaining approval
in March.

7. Correcting grammar. There were many grammatical and punctuation
mistakes made here and there. Some seem to be typos and oversights.
Correcting these takes sharp, fresh eyes.

8. Formatting was regularized and BNF's were scrutinized.

9. Typesetting bugs were and aesthetics improved.

We are still 1/2 day away from being done with this cleanup. The magnitude
of work required to achieve 1 through 7 was much greater than we thought, which
is why the documents are not now on [cls,lsp]. I'm afraid that people are not
going to get much of a chance, if any, to read the document before it goes out.

But the document can be superceded at the March meeting, and we didn't
intentionally change any content, even in the parts we don't like.
I think the document is complex enough that the folks who will try to read
it for March deserve as much time as possible to grind through it.

Mostly because redundancies were removed, the document will be approximately
82 pages long: 26 pages for CONCEPTS and 56 for FUNCTIONS.

			-rpg-