On 12/08/2011 12:10, Wolfgang Laun wrote:
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.
Flake's cannot be modified as they will not exist in the WM by the time
by the time the rule fires. Flakes must be considered "final" and
immutable such that the rule can still fire on them though.
Also, a query run from the RHS of any rule with a flake would not show
the flake, which is surprising.
A flake would never show up in a query no.
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.
We can probably add a new enum for this special retraction.
What happens if one inserts two or more flakes in a row?
Can you collect or accumulate flakes?
You can, but it would result in no change. The object is inserted and
then retracted straight away, resulting in no change on the accumulate.
The only difference is we leave the resulting conflict available to fire.
A logical insert of a fact in a RHS of a rule firing with a flake is
pointless.
the flake would never be able to falsify the logical insertion, although
other facts in the match can still do so. But users would definitely
neeed to be aware of that.
Well, could be that "djinn" would be even better: it comes, creates
mischief and disappears again...
:)
What we are trying to achieve is the abilty for users to insert objects
into WM and not have to worry about retracting them. While this is
similar to events, it's not quite the same, as the retraction of events
is not enforced if it's matched against.
Definitely room some more thought on this one, I think it would be a
nice use case, if we can make sure we get it right.
Mark
-W
On 12 August 2011 12:45, Mark Proctor <[email protected]
<mailto:[email protected]>> 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 <http://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 <http://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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
