[armedbear-devel] CLOS / D-M-C tests failure DMC-TEST-MC.1 help requested

[Erik Huelsmann]

> (One issue that I see is that all these tests used to pass when I wrote
> them. So at some point something must have changed which made us
> incompatible with ourselves. That's another reason why I at least want to
> understand what's going on...)
>
> That I can answer, I think: generic functions used to store the method
> combination _name_, and the actual method combination would be looked up
> during the computation of the effective method.  Now the generic function
> object stores the method combination object itself (purely because the amop
> test suite checks the type of the return value of
> generic-function-method-combination).
>
>
Ok. I figured out what's happening, at least inside SLIME, but I assume the
same happens for the compiler. At least, if we can  fix this happening in
SLIME, we can probably fix it for the compiler as well.

So, just to show the code that's failing to be correctly compiled:

Form 1:
(define-method-combination dmc-test-args-with-optional.4 ()
  ((methods ()))
  (:arguments &optional (a :default sup-p))
  `(progn ,@(mapcar (lambda (method) `(call-method ,method))
                    methods)
          (values ,a ,sup-p)))

Form 2:
(defgeneric dmc-test-args-with-optional.4a (x &optional b)
  (:method-combination dmc-test-args-with-optional.4)
  (:method (x &optional b) (progn x b)))


My compilation steps are to go into Form 1 and hit C-c C-c. Then do the
same with Form 2.

Every time when I do that, the method combination of the generic function
comes out with #<METHOD-COMBINATION STANDARD>. Which is clearly wrong.

What happens is that the second form expands into:

(PROG1 (SYSTEM:%DEFGENERIC 'DMC-TEST-ARGS-WITH-OPTIONAL.4A
                           :LAMBDA-LIST
                           '(X &OPTIONAL B)
                           :METHOD-COMBINATION
                           '(DMC-TEST-ARGS-WITH-OPTIONAL.4))
       (PUSH (DEFMETHOD DMC-TEST-ARGS-WITH-OPTIONAL.4A
                        (X &OPTIONAL B)
                        (PROGN X B))
             (SYSTEM:GENERIC-FUNCTION-INITIAL-METHODS (FDEFINITION
'DMC-TEST-ARGS-WITH-OPTIONAL.4A))))

Because the macro expander continues to expand the forms before compiling
them, it'll expand the DEFMETHOD above. When the DEFMETHOD gets expanded
however, it's expansion is dependent on the existence of the generic
function. However, since the form as a whole hasn't been interpreted yet,
there *is* no generic function: after all, that's being created in the
first form of the PROG1.

Something similar probably happens during compilation.


I'm now wondering what the next step should be to resolve this situation...


Ah. Going back 10 months and looking at the DEFMETHOD macro there, I see
now what the difference is between then and now: back then we didn't depend
on the GF existing during the macro expansion. Now we do. Can we generate a
different macroexpansion which defers the GF-being-defined requirement to
evaluation time?

Bye,

Erik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20120807/b3b7cef5/attachment.html>