call-next-method incoherency

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

There is a problem in the specification of call-next-method which I
need some help to fix.

The current draft of the ANSI Common lisp specification says:
 
  If there is no next method, the generic function 
  no-next-method is called.

  If call-next-method is used in a method
  whose method combination does not support it,
  an error of type control-error is signalled.
 
In 88-002R, it said just "an error is signaled" rather than specifying
control-error.  The problem I need help with is not the inconsistent
spelling of "signaled" and is not exactly the particular condition type
to be signaled.  The problem is with the definition of what it means for
a method combination type to not support call-next-method.
Define-method-combination does not contain any way to specify whether
call-next-method is supported.  All you can do is call a method with
call-method and either supply a next-method-list or not supply one; but
there is no way to distinguish between a next-method-list that happens
to be empty (in which case call-next-method should call no-next-method)
and a situation where a next-method-list is not allowed.

I see four possible approaches:

1. Change "an error of type control-error is signalled" to
   "the generic function no-next-method is called."  Assume
   that an applicable method for no-next-method signals the error.

2. Change call-method to accept a second argument of :error,
   in place of a next-method-list, which tells call-next-method
   to signal an error.

3. Change call-method to make next-method-list optional.  If it
   is not supplied, that tells call-next-method to signal an error.

4. Add a long-form-option to define-method-combination to specify
   whether methods in this method group support call-next-method.

None of these approaches makes it particularly easy to report the
misuse-of-call-next-method error at compile time, but that's not
vitally important.  Approach 1 is the only one that makes reporting
the error at compile time impossible.

I need some help deciding which of these approaches is right.  We
can't just stick with the status quo, because it's inconsistent.
The approach I prefer is #3, as the least change to the language.