Hi!
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.
Cute. I think we can beef up %defgeneric to accept a list of method descriptions and the macro environment (for make-method-lambda) and call ensure-method inside %defgeneric, after creating the generic function. I can have a look at that.
Well, I hope you don't mind, but I quickly looked at the problem last week myself as well. From all the scenario's that I could come up with the simplest (and most unsatisfying in terms of "everything is delayed to load time and I want more at compile time") is what I tried (see attached patch).
This patch seems to solve the "compile in memory" issue, but for some reason, it doesn't seem to solve the compilation problem.
Also, note that the patch is incomplete, because the forms - before being stored for load-time evaluation - should at least be macro-expanded to expand macrolet and symbol-macrolet in the body.
Hopefully it's something to give you a head start in your analysis. (I'm not going to commit this, unless it's by accident.)
Bye,
Erik.