[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: no-applicable-method

    Date: Tue, 8 Aug 89 11:01 U

    I encountered a strange phenomenon when I was using and :around method
    for the no-applicable-method generic function.  A sample of the code used

    (defmethod no-applicable-method :around
               ((gen-func standard-generic-function) &rest args)
      (if (next-method-p)
	  ... else report some error))

This is an illegal method definition.  This is because it is a method on
a specified generic function that is specialized to only specified

That is, the generic function no-applicable-method is specified in CLOS
and the class standard-generic-function is specified in CLOS.  There are
at least two ways to see why this definition has to be illegal.

The easiest is to observe that in some sense, this should be considered
a redefinition of a reserved name.  This definition is exactly analogous
to redefining an existing Lisp function like, lets say, CAR.  If were to
redefine such a function, at least theoretically, all programs including
the system implemenation itself see the change.  This can reek havoc if
you do something wrong.

Another way to see the problem with this definition is based on looking
at the problems of implementing a causally effective metacircular system
like CLOS.  In such a system, this kind of redefinition can have more
dramatic effect even if you think your method is, itself, not buggy.
The prinicple outlined above permits the implementation to assume (and
mine does), that it `knows' about all the specified methods.  This is
the easiest technique for ensuring that the metacircularity grounds out
properly.  When an unknown method leaks into the specified level of the
system, as in your method above, all hell can break lose.

This second is the problem you are running into and, in fact, is the
same problem as has been cropping up with cache expansion.