The initargs argument consists of zero or more slot initialization arguments which are passed unevaluated to the CLOS make-instance function.
The identifier argument is the symbol which identifies the new CLOS instance. This argument is ignored unless the instance is of type INSTANCE-IN-KNOWLEDGE-BASE (see Remarks below).
The kb argument is the knowledge base in which the instance's identifier is to be interned. This argument is ignored if the instance is not of type INSTANCE-IN-KNOWLEDGE-BASE (see Remarks below).
CLOS instances can be created by tell and create, as well as by make-object. The behavior of tell and create depends on the setting of the :prefer-clos-instances feature.
If the :automatic-clos-classes feature is set, a shadowing CLOS class is created for a given concept the first time that make-object is called to instantiate that concept. (Calls to tell and create may also result in class creation.) If :automatic-clos-classes is not set, a class will not be created unless the concept has the :clos-class characteristic. If the :warn-on-nonprimitive-clos-classes feature is set, a warning is issued when a class is created for a non-primitive concept.
The shadowing CLOS class normally has the same name as the concept being instantiated, but this can be overridden by the :class-name option in the concept's definition. Similarly, the :existing-class-name option can be used to shadow the concept with an existing CLOS class rather than a new one.
Loom supports automatic revision of CLOS classes. When a Loom concept is redefined, its shadowing class (if any) is likewise redefined the next time that the concept is instantiated.
If a type specifier for a non-existent CLOS class occurs in the parameter list of a defmethod, Loom will dynamically create the class if there is a concept with the same name as the type specifier and it is possible to create a shadowing class for that concept.
When a shadowing class is created for concept C, the superclasses of the new class are computed from the most-specific shadowed superconcepts of C. A slot C.R is allocated on C if R is neither :read-only nor inherited from a superclass of C, and one of the following is true:
When a concept is defined to have mixin classes (see defconcept), it is automatically shadowed, and its instances inherit properties of the specified mixins as follows:
(defconcept Woman :mixin-classes INSTANCE-WITH-CONCEPTS) (setq ?i (make-object 'Woman)) ==> \#<Woman \#X1777546> (tellm (American ?i)) (retrieve ?x (American ?x)) ==> (\#<Woman \#X1777546>) (defconcept Person :mixin-classes INSTANCE-WITH-DYNAMIC-SLOTS) (setq ?i (make-object (find-class 'Person))) ==> \#<Person \#X177FFDE> (tellm (age ?i 33)) (retrieve ?x (:and (Person ?x) (age ?x 33))) ==> \#<Person \#X177FFDE> (defconcept Doctor :mixin-classes INSTANCE-IN-MATCH-NETWORK :implies Rich) (make-object 'Doctor) ==> \#<Doctor \#X178B8EE> (retrieve ?x (Rich ?x)) ==> (\#<Doctor \#X178B8EE>) (defconcept Dog :mixin-classes INSTANCE-IN-KNOWLEDGE-BASE) (make-object 'Dog :identifier 'Fido) ==> |i|FIDO (find-instance' Fido) ==> |i|FIDO (defconcept Man :roles wife :mixin-classes INSTANCE-WITH-INVERSES) (defrelation husband :is (:inverse wife)) (setq ?i (make-object 'Man)) ==> \#<Man \#X179ABCE> (tellm (wife ?i Mary)) (retrieve ?x (husband Mary ?x)) ==> (\#<Man \#X179ABCE>)