<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 12/08/2011 12:10, Wolfgang Laun wrote:
<blockquote
cite="mid:CANaj1LddHU4buo3b_g9Cw8wv8X-exO-YdmK_yqGEnW5eHwC4Kw@mail.gmail.com"
type="cite">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>
</blockquote>
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.<br>
<blockquote
cite="mid:CANaj1LddHU4buo3b_g9Cw8wv8X-exO-YdmK_yqGEnW5eHwC4Kw@mail.gmail.com"
type="cite">
<br>
Also, a query run from the RHS of any rule with a flake would not
show the flake, which is surprising.<br>
</blockquote>
A flake would never show up in a query no.<br>
<blockquote
cite="mid:CANaj1LddHU4buo3b_g9Cw8wv8X-exO-YdmK_yqGEnW5eHwC4Kw@mail.gmail.com"
type="cite"><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>
</blockquote>
We can probably add a new enum for this special retraction.<br>
<blockquote
cite="mid:CANaj1LddHU4buo3b_g9Cw8wv8X-exO-YdmK_yqGEnW5eHwC4Kw@mail.gmail.com"
type="cite">
<br>
What happens if one inserts two or more flakes in a row?<br>
<br>
Can you collect or accumulate flakes?<br>
</blockquote>
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.<br>
<blockquote
cite="mid:CANaj1LddHU4buo3b_g9Cw8wv8X-exO-YdmK_yqGEnW5eHwC4Kw@mail.gmail.com"
type="cite"><br>
A logical insert of a fact in a RHS of a rule firing with a flake
is pointless.<br>
</blockquote>
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.<br>
<blockquote
cite="mid:CANaj1LddHU4buo3b_g9Cw8wv8X-exO-YdmK_yqGEnW5eHwC4Kw@mail.gmail.com"
type="cite"><br>
Well, could be that "djinn" would be even better: it comes,
creates mischief and disappears again...<br>
</blockquote>
:)<br>
<br>
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.<br>
<br>
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.<br>
<br>
Mark<br>
<blockquote
cite="mid:CANaj1LddHU4buo3b_g9Cw8wv8X-exO-YdmK_yqGEnW5eHwC4Kw@mail.gmail.com"
type="cite">
<br>
-W<br>
<br>
<br>
<br>
<div class="gmail_quote">On 12 August 2011 12:45, Mark Proctor <span
dir="ltr"><<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:rules-users@lists.jboss.org"
target="_blank">rules-users@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>