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