Part IX: Updates

This part collects the design of updates in Predica. The view update problem is included here for now: it is one important case of the broader question of how an update expression determines a well-defined change to the underlying predicates.

The Updates part also specifies the statement language: local variables, assignment, control flow, printing, procedure declarations, and block-bodied functions. A block-bodied function remains pure when its body uses only local state and calls only pure functions. Side-effecting reusable operations are written as procedures.

Parameter declarations state access and ownership directly. Plain parameters are read-only, & parameters grant a procedure temporary exclusive access to a caller variable, and ^ parameters are owned by the callee. For & and an explicit ^, the caller uses an expression that denotes a location. The former temporarily grants access to it; the latter moves its value and leaves it uninitialised.

Runtime failures are represented as exceptions and may be handled by statement-level try/catch. Static errors are rejected before execution and cannot be caught.

Predica distinguishes local program-state updates from database-state updates. A local update writes only program locations, such as variables or locations inside values held by variables. It does not require a transaction.

A database-state update writes locations that belong to persistent database state, such as mutable attributes of entities in a database partition. Database-state updates are performed inside transactions. The syntax for opening, committing, and rolling back a transaction depends on the host language, but a database-state update requires an open transaction on a single data partition. Constructing an entity value is still an expression; the database-state update is the statement that adds or changes that value at a base persistent location.