OK, now that we're off and running, one-shot seems like it would work for a limited set of circumstances. However, if we use goal-oriented programming then we don't need a special set of rules or objects. If we have a specific goal and the goal exists THEN we do either one or two things:
1. If we want to know only that there exists at least one instance of a set of circumstances, then the RHS would retract that goal and either assert another or let the last goal have predominance on the conflict resolution table. 2. If we want to do something for all of the instances, don't retract the goal. Just let nature take it's course and do the same thing for all instances of that particular situation. As has been stated so many times, "Folks, this stuff ain't rocket science. It's just logic. And if Psychologists, Business Analysts and Doctors with not computer training at all can understand this and write decent programs (after a year or two of working with it) then any half-fast programmer SURELY can understand how to adjust to a given set of circumstances for a certain set of rules." Well, actually, that's my favorite quote. It follows the old KISS principle. SDG jco [EMAIL PROTECTED] wrote: > I think Rich Halsey wrote: > > > It may be that I'm still confused as to the utility of your proposed > > feature. > > > > It comes up constantly on this list. One recent instance concerned a > system in which definstances were added in an uninitialized state, and > then various rules set their properties. Each time a property was set, > various initialization rules were re-activated. The rules had to be > written carefully to avoid this. If they were one-shot rules instead, > the intent could be expressd more succinctly; and even better, the > rules would be more independent, as they wouldn't need to worry > directly about the effect of other rules. > > Here's another example: > > (defrule count-x-facts > (declare (one-shot TRUE)) > (x) > ?count <- (count (x ?n)) > => > (modify ?count (x (+ ?n 1)))) > > Without the "one-shot" feature, this fires every time an X fact is > modified; with it, it fires only when one is first created. The > existing solution to this problen is exceedingly unsatisfying: you > need to add a "counted-already" slot to the "x" template and test it > on the LHS and set it to TRUE on the RHS. This is really, really > gross; the one-shot feature is far superior. > > --------------------------------------------------------- > Ernest Friedman-Hill > Distributed Systems Research Phone: (925) 294-2154 > Sandia National Labs FAX: (925) 294-2234 > PO Box 969, MS 9012 [EMAIL PROTECTED] > Livermore, CA 94550 http://herzberg.ca.sandia.gov > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- -- SDG jco --------------------------------- James C. Owen Senior KE Knowledgebased Systems Corporation 6314 Kelly Circle Garland, TX 75044 972.530.2895 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
