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 be that I'm still confused as to
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
Indeed I did !!
Sorry !
However, I'm still not sure what this brings to the table with respect to
rules engineering. If I simply wanted
a one-shot test why couldn't I just write the code in Java whereas if I want
a RETE-based environment to monitor
any/all changes to objects that I want to be eli
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
I think James C. Owen wrote:
> Ernest:
>
> Let me see if I can understand what we're actually saying here: As written
> below, since ?fact is being modified in the RHS of the rule then the rule will
> be placed on the agenda as available to be fired again, even though the
> recursion principle wo
Ernest:
Let me see if I can understand what we're actually saying here: As written
below, since ?fact is being modified in the RHS of the rule then the rule will
be placed on the agenda as available to be fired again, even though the
recursion principle would otherwise have removed the rule from
I think Thomas Gentsch wrote:
>
> What I would find favourable is a modified behavior in a way, that a
> rule gets activated by a modified fact *only* if a slot applicable to
> the rule had been changed...
Yes, this one has been brought up quite a bit. I've unfortunately not
been able to think of
Hi there,
I personally think that this actually works around the basic idea of a
fact/rule system like Jess - a rule fires whenever all its conditions
are met and this will be tested whenever the facts in question are
modified. In other words - the behavior as it is right now is absolutely
correc
Hello ejfried,
Sunday, January 05, 2003, 6:20:37 AM, you wrote:
ecsg> Hi Folks,
ecsg> Very often, people post questions equivalent to the following to this
ecsg> list:
ecsg> "Why does this cause an infinite loop?
ecsg> (defrule my-rule
ecsg> ?fact <- (fact (slot ?x))
ecsg>
12 matches
Mail list logo
