Content Comparison

...

While the action has effects on things outside of the pico, the postlude can change the state of the pico or add additional rules to the event evaluation currently in progress (see the Event Loop Introduction page for more information).

Overall structure of postlude

The postlude, if present in a rule, comes in one of three forms. The choice is based on whichever provides the clearest and easiest-to-understand code.

<postlude>           ::= <postlude form> [ finally { <postlude item list> } ]
<postlude form>      ::= fired { <postlude item list> } [ else { <postlude item list> } ]
                       | notfired { <postlude item list> } [ else { <postlude item list> } ]
                       | always { <postlude item list> }
<postlude item list> ::= <postlude item> | <postlude item list> ; <postlude item> [;]

Overall structure of postlude

The postlude specifies internal effects on the pico. These can be conditional, based on the conditional action. The KRL developer can choose one of the , i.e. whether or not the rule is said to have "fired". The KRL developer can choose one of the fired (line 2), notfired (line 3), or always (line 4) postlude forms. The choice is based on whichever provides the clearest and easiest-to-understand code. In any case, the developer can also indicate postlude items to be executed after the conditional postlude form, by using a finally block.

...

A postlude item is either an assignment to an entity variable, or effects on the raising of an event internal to schedule of rules involved in this event execution. Raised events result in additional rules being added to the end of the schedule of rules to be evaluated for the event.

...

The special keyword last aborts the schedule of rules and the event execution finishes without evaluating any rules which might remain on the schedule.

<postlude item>          ::= <postlude assignment>operation> [ <guard> ]
<guard>                  ::= if <BOOL EXPR>
     | <postlude raise event> [ <guard> ] <postlude assignment>    ::= ent:<ID> := <EXPR> <postlude raise event>   ::= raise| <ID>on eventfinal
<STRING<postlude EXPR>operation> [ for <STRING EXPR> ]::= [<postlude attributesassignment>
<MAP EXPR> ]                         |   |<postlude raise eventevent>
<STRING<postlude EXPR>assignment> [ for <STRING EXPR> ] [ attributes <MAP EXPR> ]
<guard>::= ent:<ID> := <EXPR>
                     ::= if <BOOL EXPR>   | clear ent:<ID>
<postlude raise event>   ::= raise <postlude event spec> [ for <STRING EXPR> ] [ attributes <MAP EXPR> ]
                           | last
<postlude on final

...

event spec>    ::= <ID> event <STRING EXPR>
                           | event <STRING EXPR>

For more information about conditional guarded postlude items, see the Guard Conditions page.

...

Guards either check for a Boolean expression (line 2) or for the very last iteration of a foreach loop (line 3).

Entity variable assignment

A pico is provided with entity variables by its installed rulesets. Entity variables can be assigned values only inside of rule postludes.installed rulesets. Entity variables can be assigned values only inside of rule postludes. An entity variable can be assigned a value (computed by an expression), or it can be cleared (line 8).

When an entity variable is mentioned in an expression (which can happen anywhere an expression can appear in a ruleset), and it does not exist in the pico/ruleset then the value is null.

Raised events

As with all events, raised events are identified by a pair of identifiers for its "domain" and "type". These are specified in one of two ways.

In the first version of the syntax (line 48), the domain is given as a bare word between the keywords raise and event, and the type is usually a String constant (but can be computed by an expression computing a String which is a valid identifier.)

In the second (and newer) version of the syntax (line 59), the event is identified by a String expression which consists of a valid identifier for the domain followed by a colon followed by a valid identifier for the type.

In both cases, the selecting of rules to be added to the schedule can be limited to a single ruleset by including the for clause followed by a String expression which computes a valid ruleset identifier. When the for clause is absent, the rules in all rulesets installed in the pico will be considered.

Finally attributes for the raised event are given by a Map after the keyword attributes. If these are not given, the compiler will provide an empty Map.