Cocoa (initially called KidSim) is a rules-based LPV, in which the programmer specifies rules for demonstrating a postcondition starting from a precondition. The “programmers” targeted are children, and the associated field is the specification of graphics simulations and games. Cocoa is a complete Turing language, except that its facilities were not designed for general-purpose programming, but to facilitate children’s access to programming their own simulations.
The way in which the concrete and direct attributes are achieved in Cocoa are similar to Chimera because both use demonstration as a way to specify semantics. However, the response time level is different in Cocoa being between 2 and 3.
It is not level 3 for certain types of program changes, for example, adding new rules that do not affect the current display of variables until the express request of the programmer to resume running. For other program changes (changing the appearance of an object), the changes are immediately propagated on display.
In indicating the properties common to all rule-based systems, Hayes-Roth includes the ability to explain their behavior.
In Cocoa, a child can create worlds that contain a variety of characters, aspects, and properties. A specific rule that makes a character in a particular situation, the appearance allows the character to change its appearance, and the properties are used to retain character information. The simulation is done on the basis of a clock so that every touch of each character in the scene is allowed to operate according to their own worlds.
Each character has a list of rules. When a character has a turn to act, the system scans the list of rules, selects the first rule applies to the current state, and executes it.
The rules are created by specifying the actions that will be included by the programmer, after which the system generalizes them (creates the rule) so that they can be used automatically whenever it is needed.
The simplest rule is the one that moves a character.
The visual representation of a rule shows an image with the status of the rule before (left) and after (right), joined by an arrow. The rule is interpreted: “if there is free space to my right, I move in it.”
As the rules are revised at each touch of the clock, only this simple rule is sufficient to move the character along with the board.
Rules can also be created to change the appearance of a character.
Often the simulations become attractive because the characters change along the way: they get older, they get tired, they become stronger or smarter.
To allow changing the internal state of the characters, Cocoa offers the attribution of properties, which can be predefined or created by the user. For example, the user can develop features such as “age” or “hungry” for a particular character. These properties play the role of instances in object-oriented programming.
Cocoa also includes a computer to allow editing of complicated rules.
In each execution cycle, the rules associated with each character are followed in its top-down list.
The indicator next to a rule is “off” (gray) before the rule is taken into account. Then, if the rule cannot be applied to the current state of the character, the indicator next to the character becomes red.
If the rule can be applied, it is executed, and the indicator next to it becomes red.
After applying a rule for a character, it is stopped, and no rule is checked for it until the next cycle.