Defining the Circus operational semantics inthe K-framework Alex Alberto, Marie-Claude Gaudel To cite this version: Alex Alberto, Marie-Claude Gaudel. Defining the Circus operational semantics in the K-framework. [Research Report] LRI - CNRS, University Paris-Sud; ICMC, University of Sao Paulo. 2017, pp.59. hal-01438386 HAL Id: hal-01438386 https://hal.archives-ouvertes.fr/hal-01438386 Submitted on 17 Jan 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Defining the Circus operational semantics in the K-framework Alex Alberto1 and Marie-Claude Gaudel2 1Universidade de S~aoPaulo, ICMC, S~aoCarlos, Brazil 2LRI, Univ. Paris-Sud and CNRS, Universit´eParis-Saclay, 91405 Orsay, France January 17, 2017 Abstract This report documents how we have implemented a trace generator for the Circus specification language using K, a rewrite-based executable semantic framework in which programming languages, type systems and formal analysis tools can be defined using configurations, computations and rules. This implementation is based on the operational semantics of Circus, that we have revisited to make it exploitable with K. The moti- vation of this work is the development of a test generation environment for Circus. Moreover, it may provide some inspiration to the developers of tools for specification languages based on process algebras. 1 Contents 1 Introduction 3 2 Background 4 2.1 The K-Framework . 4 2.2 Circus ................................ 5 3 Syntax 8 4 Configuration 12 4.1 Structures of loaded processes: the procstrs cell . 14 4.2 Local configurations for symbolic evaluation of processes: the procs and proc cells . 15 4.3 Possible initials after a configuration: the inits cell bag . 16 5 Symbolic evaluation of process synchronizations 17 6 Structural and embedding rules 20 6.1 Specification processing and loading . 20 6.2 Configuration maintenance . 24 7 Operational semantic rules 25 7.1 Internal progress . 26 7.2 State and Z schema . 29 7.3 Observable progress . 31 8 Examples 45 9 Conclusions and future work 50 A Operational semantics: table of selected transition rules 53 B Specification-oriented transition system: labels and rules 57 2 1 Introduction Circus is a state-rich process algebra combining Z [WD96], CSP [Ros98], and a refinement calculus [Mor94]. Its denotational and operational semantics are based on the Unifying Theories of Programming (UTP) [HJ98]. 5 The K-Framework is a rewrite-based executable semantic framework for de- veloping tools based on the operational semantics of programming languages [Ros07]. We report how we have defined a configuration structure and a set of rewrite rules within the K-Framework, which, given a Circus specification, produces an 10 executable symbolic transition system that mimics the one defined by the formal operational semantics of Circus. The result is a symbolic evaluator that takes the text of a Circus specification as input and produces, as output of interest, a constraint and two sets of sym- bolic traces: one corresponding to the constrained symbolic traces of the Circus 15 operational semantics [CG11a]; the other to the specification traces, closer to the specification text, that were introduced in [CG14] to facilitate the analysis of test coverage criteria. We have translated each Circus operational semantic rule into some equiv- alent K-Framework rewrite rule or set of rules. The efforts were focused on 20 keeping a close similarity between the rules of the formal semantics and the input format of the K-framework. Most of the rules were translated in a straightforward way, permitting a crosscheck between the operational semantics and the designed rewriting ver- sion. Nevertheless, some behaviors, especially those related to the synchro- 25 nization of nested concurrent processes, required the adoption of more complex strategies. Non-determinism is allowed in Circus specifications and it was handled ex- ploiting the backtracking mechanism of the K-framework, guaranteeing the cov- erage of all possibilities. 30 We have organised this document as follows: • The statement of a simplified, machine readable, syntax for the Circus language is given in Section 3; • The definition of a configuration to keep the necessary information for handling the state and other properties for Circus processes is given in 35 Section 4; • The adopted strategy to handle communications and synchronizations be- tween concurrent processes is described in Section 5; • The structural rules for dealing with structural issues, such as loading and optimizing the configuration, are presented in Section 6; 40 • The Circus operational semantics rules designed as K-Framework rewrite rules are presented in Section 7; 3 • Some examples of specification texts, used for validating the behavior of the transition system, and the corresponding traces are presented in Section 8. 45 Moreover, the next section contains a brief introduction to some background concepts. 2 Background 2.1 The K-Framework The K-framework is presented by its authors as a rewrite-based definitional 50 framework in which programming languages, calculi, as well as type systems or formal analysis tools can be defined [RS¸10]. It provides many desirable aspects such as modularity, non-determinism and concurrency handling. The frame- work is presented formally [Ros07] and packed in a reference implementation, offering tools to generate executable interpreters that allows state-exploration 55 and reasoning about programs [CLRR16]. Semantics for programming languages, calculi and other analysis tools are defined in the framework by using a set of rewrite rules and labelled, poten- tially nested, cell structures, refered to as the configuration. The content of the configuration cells keeps relevant information such as the state and general 60 environment for the system/program. There are two types of rewrite rules: computational, which count as com- putational steps, and structural rules, which are used to rearrange the terms so that the computational rules can apply. A computation is an element or a sequential list of elements that carries \computational meaning", that is, a 65 sequence of computational tasks. For instance, the assignment of the value of an expression to a variable is a computation, composed by a sequence of com- putations which are required to, first, compute the value of the expression and, then, perform the adequate changes to the affected environment configuration cells. 70 In the K-Framework, computations are syntactical elements of the sort K and they are stored and handled inside the configuration cell labelled as k. This cell is referred to as the k cell or the computation cell. Computations have a list structure, capturing the intuition of computation sequentialization, with the symbol ∼> as list the separator, to be read as \followed by" and the unit 75 symbol \." (the empty computation). In particular, computations extend the original language or calculus syn- tax. When necessary to avoid ambiguities, throughout this report we use the name k-computation when referring to a computation inside the k-cell. The k- computations can be handled like any other terms in the rewriting environment, 80 that is, they can be matched, moved from one place to another in the original term, modified, or even deleted. In such a framework, it is important to distinguish between computations under treatment and computations already completed, for instance, between 4 expressions and their values. To allow this distinction, the framework defines 85 the KResult internal syntactic subcategory. Coming back to the variable assign- ment example, the treatment of the expression will be judged finished when the achieved result is classified under KResult category as, for example, an integer value. The rewrite rules in the K-Framework are unconditional, although they may 90 have ordinary side conditions, and they are context-insensitive, so the rules apply concurrently as soon as they match. They generalize conventional rewrite rules by making explicit which parts of the term is read, write, or ignored. The framework has been developed with the mechanisation of structural operational semantics in mind. The correspondence can be summarised, in a 95 nutshell, as: • Computation terms and other auxiliary information such as environment and state, are contained in nested configuration cells. Computations are kept in special k-cells, and other information are organised and managed in cells and sub-cells, depending on the considered language. 100 • Rewrite rules correspond to transitions of the operational semantics. They describe the evolution of the top configuration cell. Computations pro- gresses are reflected by evolutions of k-sub-cells. Changes of environment and state are reflected by changes of other cells. • Structural rules describe computations rearrangements, so that rewrite 105 rules can match and apply. Such definitions can be processed by the rewrite engine that is the kernel of the K framework. As say the authors, \interpreters for free" can be obtained from formal language definitions, as well