On Sat, Apr 24, 2010 at 7:27 AM, David Holz <[email protected]> wrote: > > [I tried mailing this to the Jess list, but any interaction with it > (including the majordomo daemon) seems to be eaten by a black hole for me. > Maybe it'll pop up there too, eventually.]
[So I'm replying via the list, because David's answer shouldn't be lost.] > Wolfgang Laun wrote: > > (1) Given that logical() may be applied to the initial subset of CE of > some LHS, one might reason that it is the sum of all CEs on the LHS > what implies a fact asserted on the RHS. Is there some (theoretical or > practical) backing for the usefulness of permitting logical for a > subset? > > The logical portion essentially holds the clause which defines the truth of > the rule in general. The presence and disappearance of the RHS-asserted fact > will follow the rising and falling of this truth value. (The rising also > depends on the non-logical clauses holding true.) > > The non-logical portion of the LHS can be considered to be polled exactly > once during the rising edge. If those polled facts are then retracted, but > the logical portion holds true, then the logical assertion also still holds > true with the original bindings from when the rule originally fired, allowing > a sampling of potentially transient or difficult-to-calculate additional > values at the time of the rule becoming true. > > This has been quite useful when doing state machines (or simpler state > detection) in rules. The inference which defines actually being in the state > can be in the logical portion, while transient facts defining what the state > should do can be captured by the non-logical portion. Then those transient > facts can be consumed in the normal course of the state's operation without > invalidating the logical fact declaring that you're still in that state. > > So in other words, when you depend on something in order to _start_, but > don't want its disappearance to break your truth maintenance, that's when you > use non-logical clauses in a logical assertion. At least, that's the use > I've found. :-) > This makes sense to me, and I see the flexibility of this approach. Somehow I have managed to implement my rule based state machines without having to represent state as a fact that needs to be retracted. In one case, state was an attribute of a single WME representing the "StateMachine". Also, I tend to try and keep the number of rules small, packing actions (e.g., as lambdas) into WMEs defining the actual behaviour; but this was inspired by the requirement to use the same basic FSM mechanism for a range of similar instantiations, which is (I think) easier done by several sets of "parameter facts" defining the actual behaviour. > > (2) Assuming only situations where indeed all CEs are preconditions > for one fact asserted on the RHS, then (asking rhetorically) what if > I'd need to insert another fact which is not to be retracted when one > of the CEs turns false? > > Other systems actually do use separate right-hand syntax for logical assert > vs ground assert. Nothing comes to mind immediately about how to possibly > express this in a single rule in .clp syntax; maybe Ernest has some ideas. Well, this confirms my surmise that having this choice for fact insertion is not absurd ;-) All in all, I think that Jess provides this feature in a very flexible way. A ground assert can be easily done in an additional rule triggerd by the appearance of the logically asserted fact. Thank you very much, David! Wolfgang > > Thanks, > > David Holz > Director, Grindwork Corporation > -------------------------------------------------------------------- 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]. --------------------------------------------------------------------
