ALGOL 48 AND ALGOL 50 ALGOLIC LANGUAGES IN MATHE- MATICS

Similar documents
SOME LISP HISTORY AND SOME PROGRAM LANGUAGE IDEAS John McCarthy, Stanford University Berlin, 2002 June 19

Programming Languages Third Edition

Introduction to Axiomatic Semantics

AXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop

3.7 Denotational Semantics

Theorem proving. PVS theorem prover. Hoare style verification PVS. More on embeddings. What if. Abhik Roychoudhury CS 6214

Chapter 2 & 3: Representations & Reasoning Systems (2.2)

UNIT 3

AXIOMS FOR THE INTEGERS

An Evolution of Mathematical Tools

The Rule of Constancy(Derived Frame Rule)

Chapter 3 (part 3) Describing Syntax and Semantics

This is already grossly inconvenient in present formalisms. Why do we want to make this convenient? GENERAL GOALS

Lectures 20, 21: Axiomatic Semantics

The semantics of a programming language is concerned with the meaning of programs, that is, how programs behave when executed on computers.

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics

Lecture 5 - Axiomatic semantics

Proving the Correctness of Distributed Algorithms using TLA

Typed Lambda Calculus for Syntacticians

Consider a description of arithmetic. It includes two equations that define the structural types of digit and operator:

Typed Lambda Calculus

Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?

Introduction to Automata Theory. BİL405 - Automata Theory and Formal Languages 1

! Use of formal notations. ! in software system descriptions. ! for a broad range of effects. ! and varying levels of use. !

Handout 9: Imperative Programs and State

A short manual for the tool Accumulator

3.4 Deduction and Evaluation: Tools Conditional-Equational Logic

6. Hoare Logic and Weakest Preconditions

Formal Systems II: Applications

Axiomatic Specification. Al-Said, Apcar, Jerejian

Chapter 6 Control Flow. June 9, 2015

1 Introduction CHAPTER ONE: SETS

CS 161 Computer Security

Lecture 4 Searching Arrays

Lecture Notes on Linear Search

Chapter 3. Describing Syntax and Semantics ISBN

Hoare Logic. COMP2600 Formal Methods for Software Engineering. Rajeev Goré

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Chapter 3. Describing Syntax and Semantics ISBN

Chapter 3. Describing Syntax and Semantics

CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Sections p.

Chapter 3. Describing Syntax and Semantics

Com S 541. Programming Languages I

CS 6110 S14 Lecture 1 Introduction 24 January 2014

Type Systems COMP 311 Rice University Houston, Texas

VS 3 : SMT Solvers for Program Verification

CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Section 17.1

SEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION

Introduction to Axiomatic Semantics (1/2)

Static semantics. Lecture 3-6: Semantics. Attribute grammars (2) Attribute grammars. Attribute grammars example. Dynamic semantics

(a) (4 pts) Prove that if a and b are rational, then ab is rational. Since a and b are rational they can be written as the ratio of integers a 1

1.3. Conditional expressions To express case distinctions like

#23: Sequences March 28, 2009

Contents. Chapter 1 SPECIFYING SYNTAX 1

Status: Informal Type: Technical. This document gives an example of the Compliance Notation.

Typing Control. Chapter Conditionals

A Small Interpreted Language

Incremental Proof Development in Dafny

SOFTWARE ENGINEERING DESIGN I

APCS-AB: Java. Recursion in Java December 12, week14 1

Induction and Semantics in Dafny

Introduction to Axiomatic Semantics (1/2)

Specifying Concurrent Systems with TLA +

Verification Condition Generation via Theorem Proving

CSCC24 Functional Programming Scheme Part 2

MIDTERM EXAMINATION. CSE 130: Principles of Programming Languages. Professor Goguen. February 16, points total

Specifying Concurrent Systems with TLA +

MITOCW watch?v=kz7jjltq9r4

Dynamic Programming Algorithms

Defining Languages GMU

Static verification of program running time

Programming Languages Fall 2013

Critical Analysis of Computer Science Methodology: Theory

Computing Fundamentals 2 Introduction to CafeOBJ

What is Iteration? CMPT-101. Recursion. Understanding Recursion. The Function Header and Documentation. Recursively Adding Numbers

P1 Engineering Computation

Lecture 6: Arithmetic and Threshold Circuits

Example. program sort; var a : array[0..10] of integer; procedure readarray; : function partition (y, z :integer) :integer; var i, j,x, v :integer; :

1 The Axiom of Extensionality

Program Analysis: Lecture 02 Page 1 of 32

G Programming Languages - Fall 2012

LOGIC AND DISCRETE MATHEMATICS

Goals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1

Recursive Functions. 6.1 Primitive Recursive Functions

Chapter 3. Syntax - the form or structure of the expressions, statements, and program units

Lecture 2: SML Basics

Ensuring a Rigorous Curriculum: Practices and Goals

The Diagonal Lemma: An Informal Exposition

Formal Methods in Software Engineering. Lecture 07

Proofwriting Checklist

A Theory of Parallel Computation The π-calculus

Hardware versus software

Recursion and Induction

Midterm I Exam Principles of Imperative Computation André Platzer Ananda Gunawardena. February 23, 2012

This book is licensed under a Creative Commons Attribution 3.0 License

Definition: A context-free grammar (CFG) is a 4- tuple. variables = nonterminals, terminals, rules = productions,,

Dynamic Programming Algorithms

A Partial Correctness Proof for Programs with Decided Specifications

Cover Page. The handle holds various files of this Leiden University dissertation

An Annotated Language

Transcription:

ALGOL 48 AND ALGOL 50 ALGOLIC LANGUAGES IN MATHE- MATICS Abstract This article describes how to express programs with assignment statements and conditional go tos in mathematical logic without any programming constructs used in Fortran and Algol. The names come from imagining mathematicians devising a programming language in 1948 and elaborating it in 1950. There are just two innovations regarding the values of variables as functions, of a natural number valued time, e.g. x(t) instead of a program variable x, and regarding a program counter pc(t) as just another variable. This way of writing programs has a number of advantages. One is that statements and proofs of correctness are just ordinary proofs in the domain of variables supplemented by Peano arithmetic. We introduce the programming languages Algol 48 and Algol 50 to illustrate in a simpler setting some ideas to be used in Elephant 2000. These are the explicit use of time in a programming language and the representation of the program by logical sentences. The former permits a direct expression of the operational semantics of the language, and the latter permits proofs of properties of programs without any special theory of programming. The properties are deduced from the program itself together with axioms for the domain. We use these names, because the languages cover some of the ground of Algol 60 but use only a mathematical formalism old fashioned recursion equations that precedes the development of programming languages. They are programming languages I imagine mathematicians might have created in 1950 had they seen the need for something other than machine language. Algol 48 is a preliminary version of Algol 50 just as Algol 58 was a preliminary version of Algol 60. Consider the Algol 60 fragment. 1

0 start : p := 0; 1 i := n; 2 loop : if i = 0 then go to done; 3 p := p + m; 4 i := i 1; 5 go to loop; 6 done : The program computes the product mn by initializing a partial product p to 0 and then adding m to it n times. The correctness of the Algol 60 program is represented by the statement that if the program is entered at start it will reach the label done, and when it does, the variable p will have the value mn. Different program verification formalisms represent this assertion in various ways, often not entirely formal. Its partial correctness is conventionally proved by attaching the invariant assertion p = m(n i) to the label loop. Its termination is proved by noting that the variable i starts out with the value n and counts down to 0. This proof is expressed in various ways in the different formalisms for verifying programs. 0.1 Algol 48 In Algol 48 we write this algorithm as a set of old fashioned recursion equations for three functions of time, namely p(t), i(t) and pc(t), where the first two correspond to the variables in the program, and pc(t) tells how the program counter changes. The only ideas that would have been unconventional in 1948 are the explicit use of a program counter and the conditional expressions. We have p(t + 1) = if pc(t) = 0 then 0 else if pc(t) = 3 then p(t) + m else p(t),. and i(t + 1) = if pc(t) = 1 then n else if pc(t) = 4 then i(t) 1 else i(t), 2

pc(t + 1) = if pc(t) = 2 i(t) = 0 then 6 else if pc(t) = 5 then 2 else pc(t) + 1. The correctness of the Algol 48 program is represented by the sentence m n(n 0 t(pc(t) = 0 t (t > t pc(t ) = 6 p(t ) = mn))) This sentence may be proved from the sentences representing the program supplemented by the axioms of arithmetic and the axiom schema of mathematical induction. No special theory of programming is required. The easiest proof uses mathematical induction on n applied to a formula involving p(t) = m(n i(t)). Algol 48 programs are organized quite differently from Algol 60 programs. Namely, the changes to variables are sorted by variable rather than sequentially by time. 0.2 Algol 50 However, by reifying variables, Algol 50 permits writing programs in a way that permits regarding programs in this fragment of Algol 60 as just sugared versions of Algol 50 programs. Instead of writing var(t) for some variable var, we write value(var, ξ(t)), where ξ is a state vector giving the values of all the variables. In the above program, we ll have value(p, ξ(t)), value(i, ξ(t)) and value(pc, ξ(t)). The variables of the Algol 60 program correspond to functions of time in the above first Algol 50 version and become distinct constant symbols in the version of Algol 50 with reified variables. Their distinctness is made explicit by the unique names axiom i p i pc p pc. In expressing the program we use the assignment and contents functions, a(var, value, ξ) and c(var, ξ), of (McCarthy 1963) and (McCarthy and Painter 1967). a(var, value, ξ) is the new state ξ that results when the variable var is assigned the value value in state ξ. c(var, ξ) is the value of var in state ξ. 3

As described in those papers the functions a and c satisfy the axioms. c(var, a(var, val, ξ)) = val, and var1 var2 c(var2, a(var1, val, ξ)) = c(var2, ξ), a(var, val2, a(var, val1, ξ)) = a(var, val2, ξ), var1 var2 a(var2, val2, a(var1, val1, ξ)) = a(var1, val1, a(var2, val2, ξ)). The following function definitions shorten the expression of programs. Note that they are just function definitions and not special constructs. step(ξ) = a(pc, value(pc, ξ) + 1, ξ), goto(label, ξ) = a(pc, label, ξ). We make the further abbreviation loop = start + 2 specially for this program, and with this notation our program becomes t (ξ(t + 1) = if c(pc, ξ(t)) = start then step a(p, 0, ξ(t)) else if c(pc, ξ(t)) = start + 1 then step a(i, n, ξ(t)) else if c(pc, ξ(t)) = loop then (if c(i, ξ(t)) = 0 then goto(done, ξ(t)) else step ξ(t)) else if c(pc, ξ(t)) = loop + 1 then step a(p, c(p, ξ(t)) + m, ξ(t)) else if c(pc, ξ(t)) = loop + 2 then step a(i, c(i, ξ(t)) 1, ξ(t)) else if c(pc, ξ(t)) = loop + 3 then goto(loop, ξ(t)) else ξ(t + 1)) In Algol 50, the consequents of the clauses of the conditional expression are in 1-1 correspondence with the statements of the corresponding Algol 60 4

program. Therefore, the Algol 60 program can be regarded as an abbreviation of the corresponding Algol 50 program. The (operational) semantics of the Algol 60 program is then given by the sentence expressing the corresponding Algol 50 program together with the axioms describing the data domain, which in this case would be the Peano axioms for natural numbers. The transformation to go from Algol 60 to Algol 50 would be entirely local, i.e. statement by statement, were it not for the need to use statement numbers explicitly in Algol 50. Program fragments can be combined into larger fragments by taking the conjunction of the sentences representing them, identifying labels where this is wanted to achieve a go to from one fragment to another and adding sentences to make sure that the program counter ranges don t overlap. The correctness of the Algol 50 program for multiplication by addition is expressed by tξ 0 (c(pc, ξ(t)) = start ξ(t) = ξ 0 t (t > t c(p, ξ(t )) = mn c(pc, ξ(t )) = done var( (var {p, i, pc}) c(var, ξ(t )) = c(var, ξ 0 )))) Note that we quantify over all initial state vectors. The last part of the correctness formula states that the program fragment doesn t alter the state vector other than by altering p, i and pc. We have not carried the Algol 50 idea far enough to verify that all of Algol 60 is conveniently representable in the same style, but no fundamental difficulties are apparent. In treating recursive procedures, a stack can be introduced, but it would be more elegant to do without it by explicitly saying that the return is to the statement after the corresponding procedure call and variables are restored to their values at the time of the call. This requires the ability to parse the past, needed also for Elephant 2000. We advocate an extended Algol 50 for expressing the operational semantics of Algol-like programming languages, i.e. for describing the sequence of events that occurs when the program is executed. However, our present application is just to illustrate in a simpler setting some features that Elephant will require. In particular, proper treatment of calling a function procedure with side-effects will require a state that can have a value during the evaluation of an expression. Nissim Francez and Amir Pnueli (see references) used an explicit time for similar purposes. Unfortunately, they abandoned it for temporal logic. 5

While some kinds of temporal logic are decidable, temporal logic is too weak to express many important properties of programs. 6