CL:DEFMETHOD fails for &AUX arguments that reference other arguments

[Mark Evenson]

The code recently refactored by Erik in trunk/abcl/src/org/armedbear/lisp/ArgumentListProcessor.java does not handle &AUX arguments for CL:DEFMETHOD correctly.

After defining the APPLY-RULE generic function as such:

(defgeneric apply-rule (rule))
(defmethod apply-rule ((rule t) &aux (context (format nil "~A" rule)))
  (format nil "Applying rule '~A' in context '~A'" rule context))

then

   CL-USER> (apply-rule "1")

will fail with errors in

Wrong number of arguments for #<FUNCTION (LAMBDA (ARGS NEXT-EMFUN)) {756AF1BA}>; 2 expected.
   [Condition of type PROGRAM-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] Abort thread.

Backtrace:
  0: (#<FUNCTION {4024268F}> #<PROGRAM-ERROR {27ABBCDA}> #<FUNCTION {4024268F}>)
  1: (APPLY #<FUNCTION {4024268F}> (#<PROGRAM-ERROR {27ABBCDA}> #<FUNCTION {4024268F}>))
  2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<PROGRAM-ERROR {27ABBCDA}> #<FUNCTION {4024268F}>)
  3: (INVOKE-DEBUGGER #<PROGRAM-ERROR {27ABBCDA}>)
  4: org.armedbear.lisp.Lisp.error(Lisp.java:379)
  5: org.armedbear.lisp.ArgumentListProcessor$FastMatcher.match(ArgumentListProcessor.java:642)
  6: org.armedbear.lisp.ArgumentListProcessor.match(ArgumentListProcessor.java:459)
  7: org.armedbear.lisp.Closure.execute(Closure.java:205)
  8: org.armedbear.lisp.Closure.execute(Closure.java:139)
  9: org.armedbear.lisp.clos_221.execute(clos.lisp:1910)
 10: org.armedbear.lisp.FuncallableStandardObject.execute(FuncallableStandardObject.java:99)
 11: org.armedbear.lisp.LispThread.execute(LispThread.java:649)
 12: org.armedbear.lisp.Lisp.evalCall(Lisp.java:550)
 13: org.armedbear.lisp.Lisp.eval(Lisp.java:515)
 14: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345)
 15: (#<STANDARD-GENERIC-FUNCTION APPLY-RULE {3C3A157E}> "1")

[Evenson Not Org]

After applying the ​CFFI patch to enable Hunchentoot to use CL+SSL, then load RESTAS via Quicklisp, evaluation of the following form shows the problem in our MOP

(let* ((package (format nil "not.org.~A" (gensym)))
      (module (restas:define-module package))
      (pkg-submodule (make-instance 'restas::pkg-submodule :module module)))
 (restas:submodule-routes pkg-submodule))

[Mark Evenson]

(In [13884]) See #199: factored test for failing case.

[Mark Evenson]

For the ​RESTAS framework loaded by the Feb 2012 Quicklisp the following MOP call fails when trying to run the 'examples/example-1.lisp' code:

 (MOP::INITIAL-DISCRIMINATING-FUNCTION #<STANDARD-GENERIC-FUNCTION SUBMODULE-ROUTES {59FAC3A2}> (#<RESTAS::PKG-SUBMODULE{23452A3E}))

I would like to either fix this for abcl-1.0.2 or get ​abcl-1.1.0-dev working with Hunchentoot again, as I'm pretty sure this should be fixed easily in Rudi's code.

Wrong number of arguments for #<FUNCTION (LAMBDA (ARGS NEXT-EMFUN)) {4B658B53}>.
   [Condition of type PROGRAM-ERROR]

Restarts:
 0: [RETRY] Retry SLIME interactive evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] Abort thread.

Backtrace:
  0: (#<FUNCTION {17144A84}> #<PROGRAM-ERROR {35282BF2}> #<FUNCTION {17144A84}>)
  1: (APPLY #<FUNCTION {17144A84}> (#<PROGRAM-ERROR {35282BF2}> #<FUNCTION {17144A84}>))
  2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<PROGRAM-ERROR {35282BF2}> #<FUNCTION {17144A84}>)
  3: (INVOKE-DEBUGGER #<PROGRAM-ERROR {35282BF2}>)
  4: org.armedbear.lisp.Lisp.error(Lisp.java:381)
  5: org.armedbear.lisp.Function.execute(Function.java:312)
  6: org.armedbear.lisp.Primitive.execute(Primitive.java:113)
  7: (#<STANDARD-GENERIC-FUNCTION SUBMODULE-ROUTES {59FAC3A2}> #<RESTAS::PKG-SUBMODULE {605D3821}>)
  8: (APPLY #<STANDARD-GENERIC-FUNCTION SUBMODULE-ROUTES {59FAC3A2}> (#<RESTAS::PKG-SUBMODULE {605D3821}>))
  9: (MOP::INITIAL-DISCRIMINATING-FUNCTION #<STANDARD-GENERIC-FUNCTION SUBMODULE-ROUTES {59FAC3A2}> (#<RESTAS::PKG-SUBMODULE {605D3821}>))
 10: (RESTAS:SUBMODULE-ROUTES #<RESTAS::PKG-SUBMODULE {605D3821}>)
 11: (RESTAS:CONNECT-SUBMODULE #<RESTAS::PKG-SUBMODULE {605D3821}> #<ROUTES:MAPPER {8102FF4}>)
 12: (RESTAS::ADD-TOPLEVEL-SUBMODULE #<RESTAS::PKG-SUBMODULE {605D3821}> NIL 8080)
 13: (RESTAS:START #:RESTAS.EXAMPLE-1 :PORT 8080)

[Mark Evenson]

Reassigning to Erik.

[Mark Evenson]

As noted in ​the CLHS, the use of &AUX is equivalent to putting the forms in a LET* binding, so as a workaround for the original problem with RESTAS replace

(defmethod submodule-routes ((submodule submodule)
                             &aux (decorators (submodule-decorators submodule)))
  (mapcar (lambda (route)
            (apply-decorators route decorators))
          (module-routes (submodule-module submodule) submodule)))

with

(defmethod submodule-routes ((submodule submodule))
  (let* ((decorators (submodule-decorators submodule))))
    (mapcar (lambda (route)
              (apply-decorators route decorators))
            (module-routes (submodule-module submodule) submodule)))

See ​http://detroit.slack.net/~evenson/abcl/restas/abcl-restas-defmethod-aux-20120229a.patch.

[ehuelsmann]

This fails since 0.21.x (of which I had an accidental build lying around), with the only difference that the recent refactoring tells you how many arguments are expected (2), while the original just reports "Wrong number of arguments.".

[ehuelsmann]

Even more interesting:

(defgeneric b (c))
(defmethod b ((c stream) &aux a b c) (print "ok"))
(b *standard-output*)
---> Error

But:
(defgeneric b (c d e f g h))
(defmethod b ((c stream) d e f g h &aux i) (print "ok"))
(b *standard-output* t t t t t)
---> Prints "ok"

[Mark Evenson]

DEFGENERIC should error when given &aux keyword.

See ​http://www.lispworks.com/documentation/HyperSpec/Body/03_db.htm.

[Evenson Not Org]

Not all use of &AUX arguments fail, just those which refer to other types of arguments in the function's lambda list.

The problem exists for functions defined via DEFUN as well, not just CLOS.

[ehuelsmann]

The problem in case of the DEFMETHOD version is that the function being called (presumably an EMF) takes 2 arguments (ARGS and NEXT-EMFUN), but receives only one: the stream.

[ehuelsmann]

Could we be looking at 2 different issues? I'm not seeing the &aux issue with the interpretation. Only the CLOS one.

[Mark Evenson]

As you note this only seems to fail for DEFMETHOD forms. I have no idea what was causing the failure that I saw yesterday, which is not reproducible for me either.

[Evenson Not Org]

The failure seems to be limited to generic functions that have only one required argument.

[Mark Evenson]

Addressed in r13939.