Isabelle/UTP‌ Sample Clauses

Isabelle/UTP‌. Isabelle/UTP [21, 52, 20] is a mechanisation of the UTP semantic framework in the proof assistant Isabelle/HOL [39]. It allows us to define UTP theories within the alphabetised relational calculus, whilst taking advantages of Isabelle’s type checker, and then mechan- ically prove associated theorems, such as algebraic laws. Such laws can then be applied to program verification tasks in Isabelle. ⇒ An alphabetised relation is essentially a set of possible observations that can be made of the model, such as the set of possible input and output mappings. Our model of alphabetised predicates, therefore, is α upred ¾ (α bool), where α is a suitable type for modelling the alphabet, that corresponds to the state space. This means that we can easily implement the usual operators of boolean algebra and complete lattices by lifting the corresponding HOL notions on sets. Similarly, relational operators like composition P ; Q can also be obtained by lifting the corresponding HOL functions. A relation with input alphabet α and output alphabet β has the type (α, β) rel in Isabelle/UTP, which is syntactic sugar for a predicate of type (α × β) upred. ⇒ Variables in the state space α are modelled abstractly using lenses [17, 16], which are perhaps best known in the functional programming world. A lens V = S, for view type V and source type S, identifies V with a subregion of S. This is illustrated in Figure 2, where the hatched region denotes the portion of S that V corresponds to. Lenses can be used to abstract many types of data structure. For example, if S is a record type, then V might be a particular field, or if S is a function type, then V might be an element of the domain. ≈ A lens consists of two functions: get that extracts a view from a larger source, and put that puts back an updated view. Moreover the behaviour of lenses is constrained by a number of algebraic laws which are summarised in Figure 3. Since lenses are semantic rather than syntactic entities, we cannot compare them just using (in)equality, and thus we introduce further operators. Lens equivalence, X Y , states that lenses X and Y view precisely the same region of the source, though these views may have different types. Lens independence, X da Y , states that the two lens views are independent: manipulating the source type using X has no effect on the region identified by Y and vice-versa. Such operators can be used as the basis for comparison of variables. ⊕ We have mechanised a theory of lenses i...

Isabelle/UTP‌. Isabelle/UTP is a theorem prover implemented within the Isabelle proof assistant and logic of HOL. It supports proof in the context of Hoare and He’s Unifying Theories of Programming (UTP) [20]. This is a general and unifying framework to define programming language semantics, and we have used it to encode Circus, amongst other languages. The UTP adopts a predicative approach that represents computational mod- els as relations over a theory-specific alphabet of variables. Those variables determine the observable quantities and can, for instance, include the state variables of a program, traces of a reactive process, or trajectories of a hybrid system. State spaces in Isabelle/UTP are modelled by record types (named tuples). In Isabelle/UTP, we use the command alphabet to construct such types. Below is an example that introduces three variables, x, y and z. The alphabet command is similar to Isabelle/HOL’s built-in record com- mand for introducing record types, but caters for some additional set-up in the context of UTP. We give a detailed technical explanation of it in [15]. To give an example of a predicate encoding, let us consider a model of the assignment z := x ∗ y . We encode it as follows in Isabelle/UTP. The above corresponds to the hand-written relational predicate x j = x ∧ yj = y ∧ z j = x ∗ y . Primed variables are used to refer to the values of variables after a computa- tion has finished, and plain (unprimed) variables refer to their values at the start of a computation. Whereas the third conjunct specifies the new value of z , we note that the first two conjuncts are necessary to ensure that x and y retain their values. The encoding illustrates a few salient points about Isabelle/UTP. First of all, variables have to be prefixed with either & or $, depending on whether they are used in the context of a plain predicate that does not allow primed variables, or in the context of a relational predicate that does so, like the one above. Secondly, operators (such as ‘=’ above) usually have to be subscripted to delineate them from HOL operators. There are a few exceptions to this; for instance, arithmetic operators can be written as in HOL. Important to note is that the general view of the UTP modelling computa- tions as predicates facilitates a contractual view. For instance, more gener- ally, predicates of the form ok P ok j Q specify total-correctness pro- grams as familiar pre- and postcondition pairs (P, Q ). Here, ok and ok j are special boole...

Isabelle/UTP‌. ‌ Isabelle/UTP is a theorem prover implemented in the Isabelle proof assistant, on top of Higher-Order Logic (HOL). It supports proof in the context of Hoare and He’s Unifying Theories of Programming (UTP) [21]. This is a general and unifying framework to define programming language semantics. It adopts a predicative approach that represents computational models as relations over a theory-specific alphabet of variables. These determine the observable quantities and can, for instance, include the state variables of a program, traces of a reactive process, or trajectories of a hybrid system. To give an example, we consider the predicate (1) It models the partial assignment z := x div y. Here, x , y and z are program variables of type integer or real. Primed variables are used to refer to the program state after execution, and unprimed variables to the program state before execution. We point out that ok is a special boolean variable that models program termination. Hence ok being true signifies that the program has started, and okr being true signifies that it has terminated. ~ ~ ~ ~ ~ } { ~ ~ ~ ~ } The above predicate (1) admits, for example, the observation2 ok true, x 6, y 2, z r 3, okr true , capturing that the program starts in a state where x = 6 and y = 2, and terminates in a state where z = 3. It also admits the observation ok true, x 6, y 0, okr false , capturing that the program may not terminate if started in a state where y = 0. Predi- xxxxx specify in this way the observations that can be made of a computation 2We represent observations as bindings records. Variables not mentioned in the binding can have arbitrary values. within a particular computational paradigm or model. Here, for instance, the paradigm is sequential programming under total correctness. In a partial correctness semantics, ok would not be needed. For the semantic theory of a process algebra, we may in contrast need additional variables that account for traces of interactions with the environment. During INTO-CPS, we have encoded and mechanised several UTP theories in Isabelle/UTP that can be used to reason about languages relevant to the design of co-simulation models, including Modelica and VDM-RT. For our proof technique presented in this deliverable, it is sufficient to limit our theory to partial-correctness computations, being modelled by predicates over program state variables only. This already provides a suitable model to validate, for instance, the rules of Hoare logi...