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
Oh, now we have another possibility. I guess I was actually "thinking" of
marking a fact so that changes to it wouldn't activate rules at all, so that
only changes to the (x) fact would trigger count-x-facts. In effect, this
would convert the "fact" into a variable that nonetheless could be matched
I think Prof. Michael Stiber wrote:
> Please pardon me if I missed part of this discussion by overzealous email
> deletions (holiday email cleanup), but is this property more appropriately
> attached to the fact, rather than the rule (as is "logical")? In the example
> below, the "count" template c
Please pardon me if I missed part of this discussion by overzealous email
deletions (holiday email cleanup), but is this property more appropriately
attached to the fact, rather than the rule (as is "logical")? In the example
below, the "count" template could be marked so that changes to it won't
r
Ernest:
What I have done in the past is to establish a Goal object to control "rule flow"
such that we assert the Goal objects in the reverse order of rule flow so that the
last asserted Goal will be examined first. This lets the rules control the flow
using the recency of the Goals. If I want t
But you seem to be ignoring the whole problem, the "refractoriness"
problem, I think you might call it. Show me how, using Jess's current
semantics, you might accomplish what this rule (using the new feature)
does:
> > (defrule count-x-facts
> > (declare (one-shot TRUE))
> > (x)
>
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
Thanks Ernest,
I'll sit quietly in the boat now.
Rich Halsey
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, January 05, 2003 1:24 PM
Subject: Re: JESS: Re: Proposed feature
> I think Rich Halsey wrote:
>
> > It may
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
12:09 PM
Subject: Re: JESS: Re: Proposed feature
> I think Rich Halsey wrote:
>
>
> > On the other hand, depending on the system architecture
> > or the goal we wish
> > to achieve, a one-shot rule may be the anti-thesis of what we need.
> >
>
> It seem
I think Rich Halsey wrote:
> On the other hand, depending on the system architecture
> or the goal we wish
> to achieve, a one-shot rule may be the anti-thesis of what we need.
>
It seems that you, like James, may have missed the idea that this is
an optional property that you could grant to in
Excusez moi,
I have been following the various postings with interest and it seems that
the proposal (for the new one-shot
feature) is really a crutch for projects that can't (or won't) do rules
engineering.
My preference would be to have a tool that can assist with the rules
engineering by mappi
12 matches
Mail list logo