The abstract state machines method for modular design and analysis of programming languages

Egon Börger
2014 Journal of Logic and Computation  
We survey the use of Abstract State Machines in the area of programming languages, namely to define behavioral properties of programs at source, intermediate and machine levels in a way that is amenable to mathematical and experimental analysis by practitioners, like correctness and completeness of compilers, etc. We illustrate how theorems about such properties can be integrated into a modular development of programming languages and programs, using as example a Java/JVM compilation
more » ... theorem about defining, interpreting, compiling, and executing Java/JVM code. We show how programming features (read: programming constructs) modularize not only the source programs, but also the program property statements and their proofs. 1 1 This text originates from an invited lecture for the Workshop on Scalable Language Specification at Microsoft Research Cambridge, June 25-27, 2013. 2 Listening to lectures I had invited Yuri Gurevich to deliver in the years 1986, 1987 and 1991 to the computer science PhD program in Pisa. See [57, Ch.9] or [26] for historical details and references. of manageable size and reflect the behavior of Prolog programs in a transparent way, to be useful to programmers. After an initial failure the goal was achieved in [19, 20, 21] by defining the notion of an ASM ground model [27, 29] and an ASMtailored stepwise refinement [28, 29] concept for modeling with ASMs, exploiting the possibilities for abstraction that are inherent in the ASM concept (which became essentially stable in 1995 [102]). As I will explain in Sect. 2.1 and 2.2 stepwise ASM refinements allowed me to separate orthogonal language features by modules of rule sets (horizontal refinement) and to deal with them at different levels of detail (vertical refinement) 3 , leading from the ground model (which in the case of Prolog became the ISO standard definition of its semantics [114] ) to a model of its (in the case of Prolog the WAM [52]) implementation. This provided a transparent, modular structure of small, simple ASM component models which are easy to reuse-not only for the specification of models, but also for the analysis of their properties by both mathematical proof (verification) and experimental validation (simulation and testing). Such model structuring was supported furthermore by a classification of ASM locations and functions into basic and derived, monitored (or input), output, controlled, and shared ones [24, 25] . The early work with ASM ground models and their ASM refinements was influenced by my interest in Prolog and thereby focussed on logic programming systems. 4 It turned out however that the three involved concepts-ASM, ASM ground model and ASM refinement-characterize what became known as ASM method for the design and analysis of any software-based system [57] . In particular those concepts support the scalability of ASM models for the major programming paradigms, providing justified-to-be-correct, reusable hierarchies of stepwise refined, structured dynamic semantics models, leading from the source code to a machine code view for full-fledged real-life programming languages. This is illustrated in Sect. 2.3,2.4 for object-oriented programming languages. The hierarchy of ASM models for Java (resp. C#) with its JVM (resp. .NET CLR) implementation exhibits the flexibility the ASM method offers to combine design and verification in a way which supports not only model reuse, but 3 ASM refinement differs from other refinement concepts in the literature by allowing one to refine in combination both the data structures (which make up the ASM state) and the computation steps (which are described by the ASM rules). More precisely, to relate abstract and refined runs for stating and proving the desired run properties, one can determine five features: a) the targeted refined data structure, b) appropriate pairs of corresponding abstract and refined states of interest one wants to relate, c) segments of abstract and refined computation steps leading from one pair of corresponding states of interest to the next one, d) sets of abstract and refined locations of interest one wants to compare, e) the equivalence properties or whatever comparison one wants to establish, see [28, 29] for details. Horizontal resp. vertical ASM refinement includes Java's "extends" resp. "implements". 4 The early work on specification and analysis of logic programming systems using ASMs, carried out in the period 1988-1994, is surveyed in the Proceedings of the first international ASM workshop which was organized as part of the 13th World Computer Congress, see [23] .
doi:10.1093/logcom/exu077 fatcat:7quppauog5eyvaahlbvlrk7w3u