A process is a box whose behaviour is defined in terms of a set of rules. A rule consists of a list of conditions and a list of actions. The conditions of a rule evaluate to true or false. The actions consist of messages that should be sent to specified destinations if the rule's conditions are true.
Rules are of two sorts. Autonomous rules scan the contents of buffers and fire when appropriate conditions are met. Triggered rules may also scan buffer contents but, in addition, can only fire when the process receives a message matching the rule's triggering pattern. Autonomous and triggered rules may be mixed freely within a single process.
Rules are edited using the rule editor. Which allows the user to define the conditions and actions of the rule, to specify whether the rule is triggered or autonomous, and if necessary to define its triggering pattern.
The rule editor also allows the user to specify whether a rule is refracted A refracted rule will fire only once with each pattern of instantiations of its variables during a given trial. Thus, each time it fires, it will produce a new solution. Note, however, that if multiple different solutions are possible, the rule will fire once for each possibility, and moreover, if more than one possibility exists on a given cycle, it will fire as many times as are possible on that cycle.
The precise behaviour of processes is determined by the rules they contain and two properties:
Recurrent (possible values: Yes/No; default: No)
Recurrent processes are able to send messages to themselves. By default processes just take in information, process it, and send it on, but recurrent processes are able to feed their output back into themselves. The value of the property can be set by right clicking on the menu button beside the property and selecting the appropriate value.
Firing Rate (possible values: 0.0 -- 1.0; default: 1.0)
This property gives the probability or a process's rules firing when their conditions are satisfied. Normally a rule will fire whenever its conditions hold, but by setting a process's firing rate to (for example) 0.5, we can specify that rules should only fire on half of the occasions that firing is possible.
A process may also contain user specified condition definitions which are also edited using the rule editor. Condition definitions are basically raw Prolog. Some of their more advanced uses, especially those involving recursion, definitely require a reasonable understanding of Prolog. However, it is worth noting that if several rules have the same sequence of subconditions in common, then the process of rule writing can be made easier, and the rules themselves made simpler and clearer, by using that sequence of subconditions as a condition definition. The newly defined condition may then be called by those rules that need to check the sequence of conditions used to define it. /P>
The rule editor simplifies the process of writing Prolog condition definitions by forcing the appropriate structure on those definitions and preventing common syntax errors.
Each condition definition consists of one or more clauses, and each clause is composed of a head, which is a Prolog structure, with a functor and zero or more arguments, and optionally a body, composed of subconditions.
A process's condition definitions may be used as conditions in that process's rules and are available on the rule editor's Add Condition menu..
See also: Built-in Conditions