[rules-dev] [rules-users] What would you call a Fact that is only evaluated once?

[Wolfgang Laun]

It's also a little dangerous.

Consider that two or more rules should be firing with a flake. If it's
already out of WM at the time the first one fires, you can't do a modify,
e.g., for controlling the firing of the other rules, or simply for passing
them some data via the flake.

Also, a query run from the RHS of any rule with a flake would not show the
flake, which is surprising.

Event handling would need to be adapted -  certainly the melting of a flake
would have to be reported to a listener, probably with an appropriate
indication.

What happens if one inserts two or more flakes in a row?

Can you collect or accumulate flakes?

A logical insert of a fact in a RHS of a rule firing with a flake is
pointless.

Well, could be that "djinn" would be even better: it comes, creates mischief
and disappears again...

-W



On 12 August 2011 12:45, Mark Proctor <mproctor at codehaus.org> wrote:

>  On 12/08/2011 11:22, Wolfgang Laun wrote:
>
> One term (probably too long) would be "interjection".
>
> A more pictorial word is "flake", which (thinking of snowflake) provides an
> inkling for the fast fade away.
>
> The context here is I'm working on an adventure game. You insert commands,
> the engine evaluates what to do with them, then you retract it again. Once
> the initial conflict set is evaluated there is no more use for the fact, and
> you end with redundant rules. I'd rather declare @liftetime(flake)
> @liftetime(durable) and have the engine handle that, or something along
> those lines/terms.  Grindwork also adds something slightly different called
> "consume" for handling similar situations:
> http://www.grindwork.com/site/node/6
> "This rule fires when those conditions in the 'when' clause become true.
> When they become true, the "consume" causes the removal of the client
> message and the old alias (if one was set). The "rising" actions add (+
> means add to the knowledge base) facts. One fact is the new alias, and the
> other is that an alias has changed. The alias changed fact allows others
> rules to notify people in the channel that the alias changed."
>
>
> Currently how Commands are handled:
> rule invalidMove no-loop when
>     $c : MoveCommand($d : direction)
>     $h : Here( $l : location)
>     not ?connect( $d, $l; )
> then
>     System.out.println( rule.name + ':' + $c );
> end
>
> rule validMove no-loop when
>     $c : MoveCommand($d : direction)
>     $h : Here( $l : location)
>     exists ?connect( $d, $l; )
> then
>     System.out.println( rule.name + ':' + $c );
>     insert( new ExitEvent( $l ) );
>     insert( new EnterEvent( $d ) );
>     System.out.println( $d );
>     modify( $h ) { location = $d };
> end
>
> rule retractCommand salience -100 when
>     $c : Command()
> then
>     retract( $c );
> end
>
>
> -W
>
>
>  On 12 August 2011 12:00, Mark Proctor <mproctor at codehaus.org> wrote:
>
>> What would you call a fact that is inserted once and the conflict set
>> computed (the rules that can fire). The fact is then retracted so no
>> more matches can take place, but the conflict set itself is allowed to
>> fire (assuming their other facts remain true).
>>
>> I think this is quite a common use case and most users will handle this
>> via a lower salience and retracting the fact manually, but I think it's
>> useful enough to build in as a keyword on type declaration. We just need
>> a name for it :)
>>
>> Mark
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110812/5ee6e4f2/attachment-0001.html