Issues for the CLOS committee to start focussing on

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

Here is a reproduction of part of Moon's message with some statements
about how things are going on the issues [enclosed in square brackets].

Consistent terminology
  - names for relationships among classes
[In the concepts file I have made the following definitions and
terminology conventions:

``direct superclass'' means immediate parent.
``direct subclass'' means immediate daughter.
``superclass'' means direct superclass or direct superclass of a direct
superclass or etc.
``subclass'' is similar.
I've defined the phrase ``classes at or above a given class'' to mean
what ``component'' means in New Flavors documentation. It means the set
of superclasses of a class along with the class itself. Mathematics provides
no help except that we could chose to define a class to be a superclass of
itself.]

  - names for predefined classes & other interesting entities
[I did nothing here.]
  - describing the terminology at the front of the document
[The concepts file, being the front of the document, defines these
terms as it goes.]
  - making sure the document adheres everywhere to the chosen terminology
  (this may have been resolved already, but we were still discussing
   it quite recently)
[The concepts file adheres everywhere. If people agree to the way it reads,
I'll extend it to the functions file.]

Method-combination.
[This has two aspects: the general theory of how generic functions cause
method combination to happen and the syntax of defining new method combination
types. I took Sonya's text for the first aspect and tried to make it more
understandable - I think it's a little better now. I think the hard part was
explaining why it works like macro expansion instead of simply doing it.]

The class precedence rules, description, and algorithm.  To a certain
extent these are three separate issues.
  (Dick has been working on this, but I don't think it's resolved yet)
[I added a test description of the rules based on the topological sort
approach in concepts. My description still recommends optionally
signalling errors in cases where multiple orders are possible but preorder
has disambiguated. I think there is a consensus to remove this, and I will
as soon as Sonya is finished with the file.  I think it reads pretty well.
It might be a good idea to include, as an implementation note, a
description of Moon's rules and algorithm as an example of an equivalent
implementation, or of Danny's, but I don't plan to do it.

My description requires that we make the class DAG a lattice, which means
a bottom as well as a top element. We haven't decided this, but I don't
think it's a big deal to do it. If we don't do it and go with alternatives
like calling it a lattice though it isn't, I think we risk ridicule.
The one reasonable alternative is to define it to be a DAG with a distiniguished
element, and when we compute the CPL, we get a local lattice.]

				-rpg-