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

[Erik Huelsmann]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20120813/5b725134/attachment.html>