See also: Built-in Conditions


A (rule-based) process is a box whose behaviour is defined in terms of a set or rules. A rule is just a condition/action pair. The conditions of a rule evaluate to true or false. The actions are a list of messages that should be sent to specified destinations if the rule's conditions are true.

In general a process will produce output, either by scanning and acting on information in one or more buffers, or by reacting to an input message (or by a combination of the two). The rules which define a process' behaviour are of two basic sorts: autonomous (or active) rules, and triggered (or passive) rules. Autonomous rules scan the contents of buffers and fire when appropriate conditions are met. Triggered rules fire only when they are triggered by the arrival of an appropriate message. Autonomous and triggered rules may be mixed freely within a single process.


The precise behaviour of processes is determined by the rules they contain and two properties:

The Rule Editor

The rule editor is the most complex part of COGENT, since it permits the user to create rules of arbitrary complexity, using a full-featured programming language based on the logic programming language Prolog. A full description of Prolog is beyond the scope of this manual; however, the rule editor makes the process considerably easier than standard Prolog programming, since it handles much of the syntax checking and provides many functions through a series of pull-down menus, so non-programmers should find it fairly easy to use.

The rule editor is invoked from a process's Rules & Condition Definitions window by either inserting a rule into a process (by right-clicking on the canvas) or by double-clicking on an existing rule (on the canvas). Three boolean options are displayed at the top of the rule editor window. These options control the firing properties of the rule. By default, rules will attempt to fire as many times as they can on each cycle; basically, they fire only if their conditions are satisfied. Each option further constrains the default firing behaviour of the rule:

The remainder of the rule editor is concerned with defining the conditions and actions of the rule. New conditions can be added by clicking on the Add condition button, in which case the new condition will be added to the condition list at the bottom. Similarly, new actions can be added by clicking on the Add action button, and again the new action will be added at the bottom of the list of already defined actions.

By default, new conditions will be of the type match, which attempts to match a specified item with an item in an accessible buffer. The list of accessible buffers can be viewed by clicking on the pull-down menu at the right-hand side of the condition; the user must specify the item to be matched in the text field. A pull-down menu at the left-hand side of the condition permits a variety of modifications to the default, such as changing the type of the condition, deleting it, qualifying it or adding a new condition above or below it. The Change type, Add above and Add below options each have a system of submenus which permit a large range of built-in condition types to be selected, including conditions dealing with list processing, term comparison, arithmetic and general prolog. It is possible, therefore, to create compound conditions of arbitrary complexity and power. Note, however, that further conditions are being added to COGENT with each new release, and so your version may offer more options than those listed here.

The Add qualifier option permits control over the precise operation of the condition, for example by negation or quantification. By default, conditions are universally quantified, that is, they will re-satisfy as many times as they can, but they can be forced to satisfy only once in the present invocation of the rule by using the once qualifier. Using the not qualifier makes the compound condition satisfy only if the subcondition is not met. It is possible to add subconditions within the scope of a qualifier, by using the pull-down menu directly to the right of the qualifier. As with top-level conditions, this menu permits adding subconditions above or below, adding (or deleting) further qualifiers, or changing or deleting the subcondition.

Finally, the rule editor permits the user to specify the actions which are to be carried out if the rule's conditions are met. The specification of a rule's actions follows exactly the specification of messages within a data source. This is possible because actions are just message lists.

The Condition Editor

The condition editor is invoked whenever the user attempts to create or modify a condition. Conditions should only be found within processes, and can be edited by following the general procedure for editing all box elements (i.e., double clicking on the condition, or selecting Edit... from the menu that appears after right-clicking on the condition). New conditions can be created by either copying existing ones (by selecting Copy from the menu that appears after right-clicking on the condition) or by pulling the menu down from Create and selecting Condition Above or Condition Below as appropriate.

Conditions 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 defining a compound condition separately from the rules and then calling the compound condition in each rule.

The condition editor is designed to simplify the process of writing Prolog conditions by forcing the appropriate structure on those conditions and preventing common syntax errors.

Each condition 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. The Functor field in the condition editor allows the user to modify the functor name, and changes here are reflected in all clauses of the condition. Similarly, the number of arguments is controlled by the Arguments widget; changing this value will change the number of argument fields available in the head of each clause.

As well as a head, each clause may have a body, which is composed of subconditions. A pull-down menu at the left of the clause allows the user to add, delete, change or qualify subconditions in a manner already familiar from the Rule Editor, and this menu makes the same built-in conditions available.

Any conditions which the user defines become available for selection through the pull-down condition-editing menus in both the Rule Editor and Condition Editor.

Special triggers

COGENT supports a small number of special triggers for the control of execution. These are system_end(Level) and stop.

    This trigger is sent to any rule which responds to it, on execution of a corresponding end(Level) script command. Level may be one of trial, block or subject. It is intended for use by experimenter boxes, for example to trigger statistical processes at the end of a trial, block or subject.
    Note that system_end(trial) replaces the previous system_quiescent trigger used to detect the end of a trial. system_quiescent triggers will be automatically converted to system_end(trial) internally, for backward compatibility.
    If a stop message is sent to any box, the box will be completely halted until the next initialisation. If the box is a compound then all child boxes will be stopped. stop takes effect immediately, overriding any other messages sent on the same cycle to that box.