It's also a little dangerous.<br><br>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. <br>
<br>Also, a query run from the RHS of any rule with a flake would not show the flake, which is surprising.<br><br>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.<br>
<br>What happens if one inserts two or more flakes in a row?<br><br>Can you collect or accumulate flakes?<br><br>A logical insert of a fact in a RHS of a rule firing with a flake is pointless.<br><br>Well, could be that "djinn" would be even better: it comes, creates mischief and disappears again...<br>
<br>-W<br><br><br><br><div class="gmail_quote">On 12 August 2011 12:45, Mark Proctor <span dir="ltr"><<a href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
On 12/08/2011 11:22, Wolfgang Laun wrote:
<blockquote type="cite">One term (probably too long) would be "interjection".<br>
<br>
A more pictorial word is "flake", which (thinking of snowflake)
provides an inkling for the fast fade away.<br>
</blockquote></div>
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:<br>
<a href="http://www.grindwork.com/site/node/6" target="_blank">http://www.grindwork.com/site/node/6</a><br>
"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."<br>
<br>
<br>
Currently how Commands are handled:<br>
rule invalidMove no-loop when<br>
$c : MoveCommand($d : direction)<br>
$h : Here( $l : location)<br>
not ?connect( $d, $l; ) <br>
then<br>
System.out.println( <a href="http://rule.name" target="_blank">rule.name</a> + ':' + $c );<br>
end<br>
<br>
rule validMove no-loop when<br>
$c : MoveCommand($d : direction)<br>
$h : Here( $l : location)<br>
exists ?connect( $d, $l; ) <br>
then<br>
System.out.println( <a href="http://rule.name" target="_blank">rule.name</a> + ':' + $c );<br>
insert( new ExitEvent( $l ) );<br>
insert( new EnterEvent( $d ) );<br>
System.out.println( $d );<br>
modify( $h ) { location = $d };<br>
end<br>
<br>
rule retractCommand salience -100 when<br>
$c : Command()<br>
then<br>
retract( $c );<br>
end<div class="im"><br>
<blockquote type="cite"><br>
-W<br>
<br>
<br>
<div class="gmail_quote">
On 12 August 2011 12:00, Mark Proctor <span dir="ltr"><<a href="mailto:mproctor@codehaus.org" target="_blank">mproctor@codehaus.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What would you call a fact that is inserted once and the
conflict set<br>
computed (the rules that can fire). The fact is then retracted
so no<br>
more matches can take place, but the conflict set itself is
allowed to<br>
fire (assuming their other facts remain true).<br>
<br>
I think this is quite a common use case and most users will
handle this<br>
via a lower salience and retracting the fact manually, but I
think it's<br>
useful enough to build in as a keyword on type declaration. We
just need<br>
a name for it :)<br>
<br>
Mark<br>
<br>
<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
rules-dev mailing list
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</div></div>
<br>_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br></blockquote></div><br>