Aspen SCM‎ > ‎Expert System‎ > ‎2. Flow of Control‎ > ‎

2.4 Brackets and Branches

Brackets

Statements are evaluated from left to right. Brackets ( and ) can be placed around statements and take precedence over left-to-right processing.

Note that brackets must be separated from other tokens by whitespace; otherwise they are regarded as part of the adjacent token. If this happens, the statement is liable to be interpreted as a predicate (see section 2.9). Multiple brackets, e.g. ( ( must be separated from each other by whitespace for the same reason.

The absence of whitespace can easily be overlooked where a closing bracket is placed in column 1 of the Description. The parser appends each line to the preceding, so a closing bracket in column 1 becomes part of a token which extended to the end of the Description on the preceding line.

For this reason we prefer not to align closing brackets immediately beneath their corresponding opening bracket. Instead we align them 1 character to the right. Then an opening bracket in column 1 is closed by a bracket in column 2 which  cannot be interpreted as part of the last token on the preceding line.

Implicit Brackets for Keywords

The logical operator AND takes precedence over OR wherever it appears. This means that the expression A OR B AND C is evaluated as A OR ( B AND C). Thus the operator OR is equivalent to ) OR ( when it appears in the Description of a rule.

There is a difference between the meaning of keywords in the Code and in the Description. Where they appear in the Code, there are implicit brackets around them which must be made explicit if the equivalent statements are made in the Description:

  • AND is equivalent to ) AND (

  • OR is equivalent to ) ) OR ( (

Also (but these cannot appear in the Description):

  • IF is equivalent to IF ( (

  • THEN is equivalent to ) ) THEN (

Implicit Brackets for AND in the Code

Consider the rule:

IF      ?A = ?X + 0
AND     ?A GE ?Y OR ?A = ?Y + 0
AND     ?A GE ?Z OR ?A = ?Z + 0
THEN    MAX_OF ?X ?Y ?Z ?A

This returns as ?A the maximum of ?X, ?Y and ?Z.

If we move the ANDs from the Code of lines 2 and 3 to the Description we must encase the statements in brackets as:

IF      ?A = ?X + 0
        AND ( ?A GE ?Y OR ?A = ?Y + 0 )
        AND ( ?A GE ?Z OR ?A = ?Z + 0 )
THEN    MAX_OF ?X ?Y ?Z ?A

If we do not, the rule will not behave as intended. If ?X is greater than or equal to Y, it will set ?A to ?X; otherwise it will set ?A to the greater of ?Y and ?Z. This is discussed further in section 2.7.

Brackets and the Limit on Branches

There is a limit of 100 on the number of branches in any rule. Branches are nowhere defined and you only become aware of this limit when you try to execute a rule with more than 100 branches: the interpreter produces this error message as it tries to start the rule:

E0079:MAXIMUM NUMBER OF AND/OR BRANCHES EXCEEDED
E0076:ERROR IN SET: TEMP.R RULE: BADRULE CONDITIONS (IF)

In order to work out the number of branches in a rule, count 1 for each:

  • entry in the Code section (excluding NOTEs);

  • opening bracket in the Description;

  • OR in the Description.

As brackets count towards the limit on the number of branches, using them where they are not needed will cause you to hit the 100 limit sooner than necessary; they are also a poor substitute for a good lay-out which emphasises the code’s structure.

You can reduce the number of branches in a rule by moving ANDs from the Code to the Description. Thus

IF      ?A = 5
        AND ?B = 6
        AND ?C = 7

uses two fewer branches than

IF      ?A = 5
AND     ?B = 6
AND     ?C = 7
One place where extra brackets may be justified is in tests which are introduced by a keyword in the Code section. Thus

IF      ( ?I OR ?I= 0 )

may be preferred to

IF      ?I OR ?I= 0

on the grounds that it emphasises that the statement contains an OR test and makes it easier to embed the code within a subsequent outer condition or loop.


Back                                Next
Comments