[Openmcl-devel] Debugging a class precedence problem
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
>> #<STANDARD-CLASS BASIC-SCENARIO> contains FORWARD-REFERENCED-CLASS
>> HIERACHICAL-AGENT-CONTROL::RANDOM-NUMBER-GENERATION-MIXIN> .
>>> While executing: #<CCL::STANDARD-KERNEL-METHOD
>> CCL:COMPUTE-DEFAULT-INITARGS (CCL::SLOTS-CLASS)>
>>> Type :POP to abort.
>> Type :? for other options.
>> 1 >
>> Gary Warren King, Lab Manager
>> EKSL East, University of Massachusetts * 413 577 0176
> Sorry for not responding earlier.
> (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
> 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