;;; /tmp/mc.lisp (defpackage :mc-test (:use :cl ) (:export )) (in-package :mc-test) (defun positive-integer-qualifier-p (method-qualifiers) (and (= (length method-qualifiers) 1) (typep (first method-qualifiers) '(integer 0 *)))) (define-method-combination example-method-combination () ((methods positive-integer-qualifier-p)) `(progn ,@(mapcar #'(lambda (method) `(call-method ,method)) (stable-sort methods #'< :key #'(lambda (method) (first (method-qualifiers method))))))) (defgeneric quux (a) (:method-combination example-method-combination)) (defmethod quux 0 (a) (format t "hi there")) (defmethod quux 1 (a) (format t "bye?")) (defun main () (quux 4)) ;; CL-USER(1): (load (compile-file "/tmp/mc.lisp")) CL-USER(2): (in-package :mc-test) MC-TEST(3): (main) #| => debugger invoked on a SB-PCL::LONG-METHOD-COMBINATION-ERROR in thread #: More than one method of type METHODS with the same specializers. See also: The ANSI Standard, Macro DEFINE-METHOD-COMBINATION Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. ((SB-PCL::EMF QUUX) # # #) error finding frame source: Don't know how to use a DEBUG-SOURCE without a namestring or a form. This is probably a bug in SBCL itself. (Alternatively, SBCL might have been corrupted by bad user code, e.g. by an undefined Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers from alien code or from unsafe Lisp code; or there might be a bug in the OS or hardware that SBCL is running on.) If it seems to be a bug in SBCL itself, the maintainers would like to know about it. Bug reports are welcome on the SBCL mailing lists, which you can find at . source: NIL 0] :0 |#