Probabilistic Semantics for RoboChart A Weakest Completion Approach

We outline a probabilistic denotational semantics for the RoboChart language, a diagrammatic, domain-specific notation for de- scribing robotic controllers with their hardware platforms and operating environments. We do this using a powerful (but perhaps not so well known) semantic technique: He, Morgan, and McIver’s weakest completion semantics, which is based on Hoare and He’s Unifying Theories of Programming. In this approach, we do the following: (1) start with the standard semantics for a nondeterministic programming language; (2) propose a new probabilistic semantic domain; (3) propose a forgetful function from the probabilistic semantic domain to the standard semantic domain; (4) use the converse of the forgetful function to embed the standard semantic domain in the probabilistic semantic domain; (5) demonstrate that this embedding preserves program structure; (6) define the probabilistic choice operator. Weakest completion semantics guides the semantic definition of new languages by building on existing semantics and, in this case, tackling a notoriously thorny issue: the relationship between demonic and probabilistic choice. Consistency ensures that programming intuitions, development techniques, and proof methods can be carried over from the standard language to the probabilistic one. We largely follow He et al., our contribution being an explication of the technique with meticulous proofs suitable for mechanisation in Isabelle/UTP

Nondeterministic Relational Semantics of a while Program

A relational semantics is a mapping of programs to relations. We consider that the input-output semantics of a program is given by a relation on its set of states; in a nondeterministic context, this relation is calculated by considering the worst behavior of the program (demonic relational semantics). In this paper, we concentrate on while loops. Calculating the relational abstraction (semantics) of a loop is difficult, but showing the correctness of any candidate abstraction is much easier. For functional programs, Mills has described a checking method known as the while statement verification rule. A programming theorem for iterative constructs is proposed, proved, demonstrated and applied for an example. This theorem can be considered as a generalization of the while statement verification to nondeterministic loops.&nbsp

Demonic fixed points

We deal with a relational model for the demonic semantics of programs. The demonic semantics of a while loop is given as a fixed point of a function involving the demonic operators. This motivates us to investigate the fixed points of these functions. We give the expression of the greatest fixed point with respect to the demonic ordering (demonic inclusion) of the semantic function. We prove that this greatest fixed coincides with the least fixed point with respect to the usual ordering (angelic inclusion) of the same function. This is followed by an example of application

Heuristics for constructing while loops

AbstractWe discuss the stepwise construction of iterative programs from specifications, represented by relations. We make an effort to isolate, in the construction of an iterative program, those decisions that are dictated by correctness preservation concerns, from decisions that the programmer is free to make at will

Thirty-seven years of relational Hoare logic: remarks on its principles and history

Relational Hoare logics extend the applicability of modular, deductive verification to encompass important 2-run properties including dependency requirements such as confidentiality and program relations such as equivalence or similarity between program versions. A considerable number of recent works introduce different relational Hoare logics without yet converging on a core set of proof rules. This paper looks backwards to little known early work. This brings to light some principles that clarify and organize the rules as well as suggesting a new rule and a new notion of completeness.Comment: A version appears in proceedings of ISOLA 2020. Version2: fix typos, minor clarifications, add a citation. Version3: copy edits, add citations on completeness. Version 4: minor corrections. Version 5: restore missing precond in loop rul

Linking programs and specifications in Z

This thesis uses the Z specification language notation to discuss the relationship between programs and specifications. We give a brief introduction to formal semantics, and the Z specification language. We provide an adaptation of the Z schema calculus which is based on predicates rather than propositions: this is constructed from the standard calculus and is thus intended as an enhancement rather than a replacement. We discuss the process of refining a specification towards a program as an exposition of the relationship between the Z language (in particular) and standard programming languages. We formulate the standard refinement proof obligations in our calculus, and briefly examine some applications. The focal point of the thesis is the provision of the semantics for a small language in Z. We believe our approach to be unique, in that we have not only described the semantic mapping functions using Z, but we are also taking Z to be our semantic domain; that is, our semantics will map a program into a corresponding Z specification. We assert the usefulness of such a specification as a basis for the analysis of the program. The semantics are analyzed in detail, and further work is done towards the unification of various aspects of program analysis under the Z notation, and in particular, under our predicate version of the schema calculus; the use of this notation and calculus to explore the link between programs and specifications is a dominant theme throughout the thesis. Using the same structures to describe programs and specifications is becoming increasingly common; in the light of this we claim that constructing a link between one and the other should not be considered solely in directional terms; the techniques in moving from the former to the latter are likely to be just as useful when moving in the opposite "direction". We present a number of small examples to illustrate the above concepts