call-next-method: More feedback from Symbolics reviewers

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

    Date: 4 Feb 87 21:20 PST
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

	In the current version of the document, CALL-NEXT-METHOD is
	documented as a macro.  That was a mistake; it should be a
	function.

    We need a proposal for the extension for call-next-method for changed
    arguments.  What is the problem with providing call-next-method with an
    &rest argument, and if it is non-null, then argument checking is done on
    those elements of the argument-list that have been used in the
    discriminator-code.

No problem, that's what I had in mind.  The only reason it's not in is
that someone wouldn't let me put it in because the proposal wasn't lean
enough.  Maybe it's time to put it in now?

    Does this argue for a macro implementation to allow
    alternative expansions in the case where arguments are provided.

That was my idea at first, but it was firmly pointed out to me that
issues of optimization should be separated from issues of semantics.
Implementations can surely figure out how to make their compilers notice
whether arguments are provided or not, and generate different code.
One way is to declare the FLET function INLINE and constant-fold the
conditional inside the function that checks whether arguments were
supplied.