I think Alan Moore wrote:
>
> > In fact, if fact-id's didn't change...
>
> [alan]
> I plead ignorance here, but how does this affect activation? I presume
> existing agenda items that were activated with the old "version" of the
> fact(s) they matched on would have their patterns re-evaluated as before.
> Newly matched patterns would also activate.
The proposed changes change absolutely nothing about how Jess
operates; fact-ids have always been just window-dressing.
>
> How would I recognize a rule(s) that depended on the fact-id changing? Would
> they have to have explicit use of fact-ids such as stashing them in other
> facts, etc.?
Yes. It's currently possible (in Jess and CLIPS) to literally write
things like
(reset)
(assert (foo (bar 1)))
(modify 1 (bar 2))
(retract 2)
This code would break under the proposed changes - the fact-id of the
foo fact after the modify is assumed here to have been incremented to
2, when now it would remain at 1.
>
> [alan]
> If the change isolated, could it not be configured via a compatibility
> switch?
>
> Sorry, I had to ask D-;
No, this is a good question. The change is easy to make in the current
code base, and there could indeed be a compatibility switch. BUT,
maintaining the compatibility option might constrain me from taking
advantage of the optimization opportunities.
>
> > Some other fact-related changes: currently all deftemplates, ordered
> > and unordered, inherit from a deftemplate __fact with no slots. This
> > isn't very useful. It could be much more useful if it were changed a
> > little. For instance, what if __fact had a slot (id) which contained
> > the fact-id? Then you could eaily find a fact with a given ID.
>
> [alan]
> Since defclass is-a deftemplate is-a fact (?), would the id slot for
> definstances be the object reference, possibly redundant with the OBJECT
> slot?
>
> (defrule find-object
> ?this <- (type (slot1 ?value1) (slot2 ?value2))
> (looking-for ?this)
> =>
> (call ?this method)
> (assert (found ?this))
> )
>
> The id namespaces are different so I don't think this would be possible
> unless facts were changed to use the underlying references as their id's.
>
The fact that this is not currently possible has surprised some
users. I think it would be nice if this worked.
> >
> > What if __fact had a slot (head) which contained the "head" or name of
> > the fact. Then you could find all facts of a given type, with the type
> > being runtime data.
>
> [alan]
> Does this mean I could somehow distinguish between multiple definstances of
> the same object reference. For example, given an object instance A that
> implements interfacesX and interfaceY, I would like to "definterface" the X
> and Y interfaces separately like so:
>
> (import interfaceX)
> (import interfaceY)
>
> (deffunction doit (?x ?y)
> (definstance ?x (head interfaceX.class.toString())
> (definstance ?y (head interfaceY.class.toString())
> )
>
> I would like to be able to write rules that work with interfaces and that do
> not depend on (or in addition to) the underlying object identity?
No, the proposed changes don't do anything to help this dilemna, which
we've discussed in the past.
>
> > What if __fact were the parent of deftemplates __ordered, which was
> > the parent of all ordered deftemplates, and the slot 'data' that all
> > ordered deftemplates have were moved up to the parent? Then you could
> > find any ordered fact containing a given datum, regardless of head.
>
> [alan]
> Could you give a concrete example of how an existing rule could be rewritten
> to exploit these changes or how something that is not currently possible
> could be accomplished?
Well, one simple one is something like this, which retracts all facts
of a given type, with the type being runtime data:
(defrule retract-named-facts
(retract-facts ?head)
?id <- (?head)
=>
(retract ?id))
>
> In any case, it sounds useful to me...
>
> > I think all of these would be more or less transparent to existing
> > code, but the features would be available. Again, opinions and
> > suggestions are invited.
>
> [alan]
> Are stupid questions ok?
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list (use your own address!) List problems? Notify [EMAIL PROTECTED]
> ---------------------------------------------------------------------
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
