[Openmcl-devel] Debugging a class precedence problem

Gary King gwking at cs.umass.edu
Fri Mar 19 14:21:41 PST 2004

Thanks Gary. I thought that it would be something like this but your 
explanation makes it nice and clear what is happening. I think that the 
actual error I was getting was a combination of multiple versions of 
source and compiled files. I did some housecleaning (computer cleaning) 
and it mercifully went away.

thanks again for your answer.

On Mar 18, 2004, at 1:16 AM, Gary Byers wrote:

> On Mon, 15 Mar 2004, Gary King wrote:
>> This is from code that runs under MCL 5.0 but not under OpenMCL. I
>> think that the code because of changes in the MOP. I'm not, however,
>> quite sure how to interpret the error message or what I should do to
>> fix my code.
>>> Error in process listener(1): Class precedence list of
>>> While executing: #<CCL::STANDARD-KERNEL-METHOD
>>> Type :POP to abort.
>> Type :? for other options.
>> 1 >
>> Thanks,
>> --
>> Gary Warren King, Lab Manager
>> EKSL East, University of Massachusetts * 413 577 0176
> Sorry for not responding earlier.
> In:
> (defclass a (b) ())
> [assuming that neither A nor B was defined beforehand.]
> the class B is just a placeholder for an as-yet-to-be-defined class.
> In the MOP, the class B is an instance of the class 
> if and when it's defined, the class's class will be changed to 
> something
> appropriate (e.g., STANDARD-CLASS) via CHANGE-CLASS.
> The class A in the example above isn't yet in a fully usable state:
> since we don't know much of anything about one of its superclasses
> (B), we don't anything about it class precedence list and therefore
> don't know what slots it'll inherit or what methods will be applicable
> for its instances.  If we try to do anything that requires that A's
> inheritance be "finalized" we'll get an error like the one above.
> Making an instance of A would require that it not have any
> forward-referenced superclasses; defining a (similarly constrained)
> subclass of A shouldn't require that
> I'm a little surprised that whatever provoked this error worked in MCL;
> its CLOS implementation doesn't really formalize the notion of a
> FORWARD-REFERENCED-CLASS, but it should recognize that it doesn't
> know much about B in this situation and refused to do anything that'd
> require this knowledge.
> What provoked the error you got ?
Gary Warren King, Lab Manager
EKSL East, University of Massachusetts * 413 577 0176

Freedom is untidy; Stuff happens.
   -- Defence Secretary Donald Rumsfeld

More information about the Openmcl-devel mailing list