| Both sides previous revision Previous revision Next revision | Previous revisionLast revisionBoth sides next revision |
| reference:rules [2015/12/12 16:51] – [Adornments of production rules] gawrilow | user_guide:extend:rules [2019/01/25 16:02] – ↷ Page moved from reference:rules to user_guide:extend:rules oroehrig |
|---|
| === Sources === | === Sources === |
| |
| //Sources// is a comma-separated list of properties which constitute the mandatory input of the algorithm. The rule scheduler provides for the existence of all source properties before the rule is executed. Moreover, all source properties are assured to have defined values. | //Sources// is a comma-separated list of properties which constitute the mandatory input of the algorithm. The rule scheduler provides for the existence of all source properties before the rule is executed. Moreover, all source properties are ensured to have defined values. |
| |
| If a rule can utilize additional source properties, which are however not mandatory, they must not be listed in the header. The rule must access optional properties using ''lookup()'' methods. | If a rule can utilize additional source properties, which are however not mandatory, they must not be listed in the header. The rule must access optional properties using ''lookup()'' methods. |
| === Labels === | === Labels === |
| |
| Labels allow to control the choice of rules by the scheduler via [[:general#preferences|preference lists]] manipulated by the user. Usually, rules with similar functionality are assigned labels with common tail part and different first limbs. For example, different rules solving LP with the simplex method are labeled with ''cdd.simplex'', ''lrs.simplex'', etc. After the user has issued a command ''prefer "cdd";'' the rule with ''lrs'' label is not considered by the scheduler until the ''cdd'' rule has failed on the object being processed. In the absence of active preference lists, labeled rules are treated the same way as unlabeled ones. | Labels allow to control the choice of rules by the scheduler via [[:general#preferences|preference lists]] manipulated by the user. Usually, rules with similar functionality are assigned labels with common tail part and different first limbs. For example, different rules solving LP with the simplex method are labeled with ''cdd.simplex'', ''lrs.simplex'', etc. After the user has issued a command ''%%prefer "cdd";%%'' the rule with ''lrs'' label is not considered by the scheduler until the ''cdd'' rule has failed on the object being processed. In the absence of active preference lists, labeled rules are treated the same way as unlabeled ones. |
| |
| Besides this, labels are involved in the overriding mechanism, and, finally, there are some special labels completely changing the semantics of the rule. Both are described further on this page. | Besides this, labels are involved in the overriding mechanism, and, finally, there are some special labels completely changing the semantics of the rule. Both are described further on this page. |
| * The rule body is executed within an own transaction scope. It is not allowed to influence it in any manner from within the rule code. | * The rule body is executed within an own transaction scope. It is not allowed to influence it in any manner from within the rule code. |
| * No attachments may be accessed nor created. | * No attachments may be accessed nor created. |
| * Mutable properties or subobjects may only be added with ''temporary'' flag. | * Mutable properties or multiple subobjects may only be added with ''temporary'' flag. |
| |
| ==== Adornments of production rules ==== | ==== Adornments of production rules ==== |
| === Permutations === | === Permutations === |
| |
| A production rule can [[permutations#Triggering the permutation|trigger a permutation]] if it produces some properties sensitive to this permutation without reading any other properties being as well sensitive to it. While the threat of triggering could in most cases be detected automatically by analyzing the rule header, we prefer to state this explicitly by putting the following adornment line: | A production rule can [[permutations#Creating permuted subobjects|incur a permutation]] if it produces some properties sensitive to this permutation without reading any other properties being as well sensitive to it. While the threat of triggering could in most cases be detected automatically by analyzing the rule header, we prefer to state this explicitly by putting the following adornment line: |
| permutation : PermutationName; | incurs PermutationName; |
| |
| As a little aid, there is a script ''list_suspicious_rules'' which performs the analysis of all production rules in an application and prints the headers of rules which could trigger a permutation but does not state it. | As a little aid, there is a script ''list_suspicious_rules'' which performs the analysis of all production rules in an application and prints the headers of rules which could incur a permutation but does not state it. |
| |
| Currently a production rule can't be declared to trigger more than one permutation. | Currently, a production rule can't be declared to incur more than one permutation. |
| |
| ==== Rules operating on multiple subobjects ==== | ==== Rules operating on multiple subobjects ==== |