[armedbear-devel] Additional slots in function classes screw up std-compute-discriminating-function

[Rudolf Schlatte]

On Dec 9, 2012, at 17:10, Pascal Costanza <pc at p-cos.net> wrote:

> Hi,
> 
> What the subject says. Here is a test case:
> 
> CL-USER(1): (use-package :mop)
> T
> CL-USER(2): (defclass my-function (standard-generic-function)
>              ((a-slot :initarg :a-slot :accessor a-slot))
>              (:metaclass funcallable-standard-class))
> #<FUNCALLABLE-STANDARD-CLASS MY-FUNCTION {24DF7EA4}>
> CL-USER(3): (defgeneric test (x y z)
>              (:generic-function-class my-function))
> #<THREAD "interpreter" {14BAAEA8}>: Debugger invoked on condition of type TYPE-ERROR
>  The value TEST is not of type LIST.
> 
> 
> The reason is that std-compute-discriminating-function is also called for subclasses of standard-generic-function that don't override compute-discriminating function. The specialization in std-compute-discriminating-function should only occur if the passed function is _extactly_ a standard-generic-function (or if it doesn't add any slots on top of standard-generic-function).

Thanks - this is hopefully fixed in r14342.  I chose to preserve slot order and append slots of child classes at the end, which allows optimized slot access in a number of places.

> By the way, we're getting closer (ha!). More and more test cases in my test suites work. I'm pretty confident that I can add full support for ABCL in Closer to MOP for the next version of ABCL.

That's great to hear.  I still have to invest a bit of thinking into your other outstanding bug (:default-initargs for generic functions), since that one lives at the intersection of Java, Lisp and the bootstrapping process.

Rudi