call-next-method with arguments

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

    Date: Fri, 17 Aug 90 19:24:27 EDT
    From: kab@charon.MIT.EDU (Kim A. Barrett)

    Partly in response to the recent question on one of the mailing lists about the
    error signaling behavior for call-next-method with arguments that don't
    correspond to the same ordered set of applicable methods as the original
    arguments, I recently made another pass over some parts of 88-002R and have the
    following questions.

Here are my personal opinions on your questions:

    1. If call-next-method is called with arguments, should it check for wrong
    number of arguments?  Probably, at least in safe circumstances.

Yes, it should be just like calling the generic function except that only a
subset of the usual applicable methods are used.  This is quite easy to implement.

    2. If call-next-method is called with arguments, some of which are keyword
    arguments, should the receiving `effective' method redo exact key checking?
    This is probably expensive.  Assuming safe code of course, since unsafe code
    isn't required to check, due to a vote at the 6/90 meeting.

Yes, it should be just like calling the generic function except that only a
subset of the usual applicable methods are used.  There's a subtle point here:
it has to use the original set of applicable methods, not the smaller set, for
checking the keyword arguments, or else call-next-method with no arguments would
sometimes be invalid.  I don't think this is any harder to implement than keyword
argument checking always is.

    3. If call-next-method is called with arguments which specify a different set
    of applicable methods and there is no next method available, does the check for
    changed applicable methods occur or does no-next-method get called with the new
    arguments?  Probably should be the former.

Yes.  This is quite easy to implement.

    4. If call-next-method is called with arguments, it is supposed to signal an
    error if the ordered set of methods applicable to the new arguments differs
    from the ordered set of methods applicable to the original arguments.  However,
    the order of methods is not well defined, since applicable methods may have the
    same specializers but different qualifiers, and there is no ordering constraint
    between such methods.  Is compute-applicable-methods required to be consistent
    in its ordering of such methods (a currently undocumented constraint), or does
    call-next-method need to handle this situation (making the handling of
    call-next-method with arguments even slower).

The specification should be clarified to say that the new and old sets of
applicable methods must have the same elements and where the order of two
elements is defined by the specification, it must be the same in both sets.
It should be up to the implementation to choose to do this by imposing a
total ordering on the methods or by making call-next-method use something
other than EQUAL to do the checking.  I don't think this is a change, I
think this is what the words "the same as" used in the specification mean.

    5. Should the checking for different applicable methods by call-next-method
    fall into the realm covered by {issue whose name escapes me, passed at 6/90
    meeting making argument quantity and exact keyword checking be `should
    signal'}.  That is, do we want to permit this checking to be elided in unsafe
    code.

ARGUMENT-MISMATCH-ERROR.  Yes.  It was a collective mistake by X3J13 that this
did not get included in that cleanup issue.  (As the author of the issue I'll
accept 50% of the responsibility, but certainly not 100%).  By the way I am not
at present aware of any CLOS implementations that signal this error.

Eliding the checking in unsafe code is quite easy to implement.

    6. The description of call-method is completely silent on the question of
    whether or when its arguments are evaluated.  The uses of call-method in the
    examples for define-method-combination clearly indicate that the arguments are
    not evaluated.

Yes, they are not evaluated.  Depending on what are the conventions for
describing macro arguments used in this specification, the specification may
in fact already be specifying that they are not evaluated.  But I like it
better to be explicit about this.

    7. The description of call-method does not make clear what lexical environment
    the form in a make-method entry is supposed to be executed in.  Presumably it
    is the lexical environment in which the call-method form is executed.  For this
    to be true it is essential that call-method not evaluate its arguments.

Yes.

I was not sure I had ever seen this feature of call-next-method (supplying
arguments to it) used in real life, so I looked at CLIM, a medium-large
CLOS-based program.  The version of CLIM I looked at uses call-next-method in
42 places, of which 31 are without arguments and 11 are with arguments.  Of
those 11, 4 are mistakes (the arguments are not actually changed) and the
remainder only change the value of numerical arguments that are never
specialized.  Most of these 7 look like their speed matters.  Most of them
don't involve keyword arguments, but I think one does.  All of them could
reasonably be compiled unsafe if that is truly necessary for performance.  I
also looked at some CLIM applications and none of them used call-next-method
at all.  I conclude that the issues you've brought up can't just be dismissed
as unimportant.