My comments on some things

[Gregor.pa@Xerox.COM]

I am amenable to making methods not be funcallable in the way that
generic-functions are.  Let me take this opportunity to repeat that I am
not amenable to allowing the method function of a method not be
FUNCALLable with the "natural" arguments.  I am fairly certain Danny
agrees with me on this issue.  I think this is something we need to talk
about the next time we get together.  I believe that we can show
"meta-objecty" programs which may it clear what a pain this would be.

---
I believe the simplest way to rephrase the much maligned (and
deservedly) phrase "the classes at or above C" is "C and all of its
superclasses", or perhaps just "C and its superclasses".

---
What does the phrase "x is of class array mean"?  In the first paragraph
of the section Integrating Types and Classes in Concepts (draft of 1/23)
it is used to mean "x is of class array or some subclass of array"?  Is
that official?

--
Args to get-method and make-instance of 'method

More along the lines of names not being the same ast the "objects they
name", I would like to change get-method and the specializers of a
method to be either (QUOTE <datum>) or a class OBJECT.  That means that
instead of saying:

   (get-method #'print-object () '(symbol t))

you would say:

   (get-method #'print-object () (list (class-named 'symbol)
(class-named 't)))

  or use mapcar or something.  

Admitedly this is somewhat longer, but I believe it is clearer, it keeps
to the abstraction that "names are supported by things which start with
DEF", but below that level of abstraction we deal with class and generic
function objects.  This allows programming with anonymous classes and
generic functions to be clean since names are not tied in at the
low-level of the system.


---
Slot inheritance rules.

Here is my proposal for slot inheritance rules.  It isn't in english, it
more of a FSM, but I believe its clear, and if we all agree then it can
be put in english.

First, what are the default values for the various slot options:

:initform    defaults to unsupplied, what this means exactly will become
clear
:type        defaults to T
:allocation  defaults to :instance

Now, how are the slot descriptions from all the different defclasses
where a slot of a particular name appears merged.

First, get the slot descriptions in class-precedence-list order.

Then, merge the individual options as follows.

:initform,  take the most specific :initform which is supplied, or take
            unsupplied if :initform is not specified in any of the slot
            descriptions

:type       The total type is and of all the types specified.

:allocation the allocation of the most specific slot.
            Note that this rule, means that you can't change the
            default value of a :class variable which you inherited,
            this is a feature, not a bug, it makes the rules simpler
too.

Some examples:

(defclass foo ()    ((a :initform 1)))
(defclass bar (foo) ((a :initform 2 :type integer)))
(defclass baz (bar) ((a :initform 3)))

BAZ's effective description for A is:
  (A :initform 3 :type (and t integer t) :allocation :instance)



(defclass foo ()    ((a :initform 'george))
(defclass bar (foo) ((a :type symbol)))

BAR's effective description for A is:
  (A :initform 'george :type (and t symbol) :allocation :instance)


(defclass foo ()    ((a :allocation :class :initform ()))
(defclass bar (foo) ((a :initform *a-default*)))

BAR's effective description for A is:
  (A :initform *a-default* :type (and t t) :allocation :instance)
Note that instances of FOO have access to a class variable of the class
FOO named A.
Instance of BAR each have their own variable named A.


---
In introduction to generic functions, (also concepts of 1/23), the
paragraph (with a bullet) which reads:

  Generic functions are named precisely as ordinary functions.  When a
generic
  functions is   associated with a symbol, that name is in a certain
package and
  can be exported...

just confuses the issue.  The point is that (unfortunately) packages
talke about symbols, not definitions or bindings.  Symbols can always be
exported.  I think the point you are really try to make is just that 
 - generic functions are function objects,
 - the same rules apply as to all other function objects,
 - as with other function objects, they are often stored in the function
   cell of a symbol (with defmethod etc.),