Re: call-method proposal prime prime

[Gregor.pa@Xerox.COM]

    Date: Thu, 14 Jan 88 22:40 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    We're running low on time to decide to adopt this and update the
    documentation accordingly; can we make a quick decision?  I guess I
    can volunteer to help with the rewriting of existing text, if
    needed.

With the comments I make below I am happy with this and can promise you
fast turnaround on comments for anything you write.

    The technique that MAKE-METHOD-CALL used can't work here.  We simply
    have to decide whether it's the responsibility of the method-combination
    function or of programs that analyze effective-method forms to know that
    AND with one subform can be optimized.  They also have to know about
    PROGN, MULTIPLE-VALUE-PROG1, etc.  Either way will work and is easy
    enough to do.  In Flavors it's the responsibility of the analyzing
    programs rather than the synthesizing programs, so that's my suggestion.
    Either way, the CLOS specification must be explicit about this.

I think it should be the resposibility of the analyzing program, but I
believe we should make an explicit comment that has the effect of
standardizing the 'simple' value that can be returned by the
synthesizing program.  We should say that analyzing programs will catch
the case:
    (call-method <m1> <whatever>)

This will make people who have some weird special function, and who want
to clue the system in to the fact that they are just returning a call to
a single method have a standard way of doing that.

    This doesn't distinguish between "no next method" and "call-next-method
    not allowed."  MAKE-METHOD-CALL made that distinction.  If we need to
    make that distinction, then I suggest one required argument and one
    keyword argument, :NEXT-METHODS.  I don't think the Symbolics
    implementation will need that distinction, but I don't know about
    others.

It seems like the call-next-method not allowed distinction needs to
(mostly) be made at a different time anyways (specifically defmethod
time).  But if we do make that distinction I agree with Patrick that the
argument should be optional rather than keyword.

    They look right except for one or two comma errors.  They are awfully
    verbose, but I think I agree that in this particular case it's better to
    be more verbose than to have a more obscure primitive for people to
    learn.  Much of the verbosity is caused by the expressive poverty of
    Common Lisp, not by your two macros themselves.  Fortunately, the short
    form of define-method-combination eliminates the need for most people to
    deal with the verbosity.

I agree.

    Date: Thu, 14 Jan 88 22:48 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Tue, 5 Jan 88 12:54 PST
	From: Gregor.pa@Xerox.COM

	....we also need some facility
	which lets the user call a random function on the same arguments the
	generic function received.  This facility might be called
	MAKE-FUNCTION-CALL or FUNCTION-CALL or hopefully we could come up with a
	better name.  

    I assume you decided we don't really need to do anything about this,
    since it wasn't in your later message.  If we do, here's a suggestion.
    In Flavors, we just put

      (:ARGLIST . lambda-list)

I still think this is very important.  I just left it out of my last
message for simplicity.  Your suggestion about :arglist seems fine to
me, but I think :lambda-list is a better name.

    Date: Thu, 14 Jan 88 22:57 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    This looks good to me except for two fairly minor points.  One is that
    I think the options should be a required argument rather than a keyword
    argument.  There is no reason ever to omit this.  Secondly, I'm not
    sure about the name method-combination-instance; it doesn't seem consistent
    with the rest of chapter 3.  I don't know if you've changed the naming
    conventions since the last version I saw, but in that version the
    consistent name would be something like expand-method-combination.
    Personally I prefer parse-xxx for names of functions that convert
    specifications into objects, rather than expand-xxx.

In the message I sent out moments ago, I now believe the expand-xxx
functions that were in the mop are not yet well enough understood to be
standardized.  I do believe we can and should standardize this function
though; I like the name method-combination-object.  I agree that the
options argument should be required rather than keyword or optional.

-------