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 <[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 + ':' + $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 <[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] >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > > > _______________________________________________ > rules-dev mailing > [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
