Gregor's comments on some things

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 29 Jan 87 15:12 PST
    From: Gregor.pa@Xerox.COM

    I am amenable to making methods not be funcallable in the way that
    generic-functions are.  

OK.

    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.

Let's plan to talk about this in person, then.

    ---
    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".

That's a good idea.  I put it into the document, since I was editing
that part.

    ---
    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?

I think so.  I believe "X is of class Y" and "X is an instance of Y" mean
that (class-of X) is Y or a subclass of Y, rather than (eq (class-of X) Y).

    --
    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.

Well, it's pretty weird that symbols are turned into class objects but
QUOTE-expressions are not.  This doesn't generalize very well to the
extension to supporting other Common Lisp type specifiers.  Otherwise
I have no objection to the proposal, so if you can supply a brief design
rationale for doing it that way to go into the document I'm amenable.

Of course it makes get-method and related functions useless until we put
in the supporting functions such as class-named.  Is there any reason
that these aren't documented already?  That is, are there any
outstanding issues on these, or is it only a matter of writing the
information down and putting TEX commands into it?  Do you Gregor, or
anyone else, have a list of these missing functions?  I'm not talking
about the full meta-object protocol, just the functions needed to program
at the next level of abstraction below the defxxx macros.

    ---

    Here is my proposal for slot inheritance rules....

I think this is the same as what Sonya and I worked out in the latest
version of the document.  When you get that document, please read the
slot inheritance description and see if you think it says what you
want and is clear.  If you have trouble retrieving the document from
SU-AI we can mail you the TEX source of that part.

    ---
    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.), 

I think this is the same as what Sonya and I worked out in the latest
version of the document.  Maybe your bulleted list is a clearer way of
saying it though; we'll check on this.