A type system is a syntactic method for automatically checking the absence of certain erroneous behaviors by classifying program phrases according to the kinds of values they compute. The study of type systems -- and of programming languages from a type-theoretic perspective -- has important applications in software engineering, language design, high-performance compilers, and security.This text provides a comprehensive introduction both to type systems in computer science and to the basic theory of programming languages. The approach is pragmatic and operational; each new concept is motivated by programming examples and the more theoretical sections are driven by the needs of implementations. Each chapter is accompanied by numerous exercises and solutions, as well as a running implementation, available via the Web. Dependencies between chapters are explicitly identified, allowing readers to choose a variety of paths through the material.The core topics include the untyped lambda-calculus, simple type systems, type reconstruction, universal and existential polymorphism, subtyping, bounded quantification, recursive types, kinds, and type operators. Extended case studies develop a variety of approaches to modeling the features of object-oriented languages.

https://www.seas.upenn.edu/~bcpierce/tapl/contents.pdf

Types and Programming Languages

The majority of the work carried out in the formal methods community throughout the last three decades has (for good reasons) been devoted to special languages designed to make it easier to experiment with mechanized formal methods such as theorem provers and model checkers. In this paper, we give arguments for why we believe it is time for the formal methods community to shift some of its attention towards the analysis of programs written in modern programming languages. In keeping with this philosophy, we have developed a verification and testing environment for Java, called Java PathFinder (JPF), which integrates model checking, program analysis and testing. Part of this work has consisted of building a new Java Virtual Machine that interprets Java bytecode. JPF uses state compression to handle large states, and partial order reduction, slicing, abstraction and run-time analysis techniques to reduce the state space. JPF has been applied to a real-time avionics operating system developed at Honeywell, illustrating an intricate error, and to a model of a spacecraft controller, illustrating the combination of abstraction, run-time analysis and slicing with model checking.

/pdf/model-checking-programs-292m6fh3ut.pdf

Model checking programs

Hardware and software systems will inevitably grow in scale and functionality. Because of this increase in complexity, the likelihood of subtle errors is much greater. Moreover, some of these errors may cause catastrophic loss of money, time, or even human life. A major goal of software engineering is to enable developers to construct systems that operate reliably despite this complexity. One way of achieving this goal is by using formal methods, which are mathematically based languages, techniques, and tools for specifying and verifying such systems. Use of formal methods does not a priori guarantee correctness. However, they can greatly increase our understanding of a system by revealing inconsistencies, ambiguities, and incompleteness that might otherwise go undetected. The first part of this report assesses the state of the art in specification and verification. For verification, we highlight advances in model checking and theorem proving. In the three sections on specification, model checking, and theorem proving, we explain what we mean by the general technique and briefly describe some successful case studies and well-known tools. The second part of this report outlines future directions in fundamental concepts, new methods and tools, integration of methods, and education and technology transfer. We close with summary remarks and pointers to resources for more information.

/pdf/formal-methods-state-of-the-art-and-future-directions-10ye4ieh6c.pdf

Formal methods: state of the art and future directions

One approach to model checking software is based on the abstract-check-refine paradigm: build an abstract model, then check the desired property, and if the check fails, refine the model and start over. We introduce the concept of lazy abstraction to integrate and optimize the three phases of the abstract-check-refine loop. Lazy abstraction continuously builds and refines a single abstract model on demand, driven by the model checker, so that different parts of the model may exhibit different degrees of precision, namely just enough to verify the desired property. We present an algorithm for model checking safety properties using lazy abstraction and describe an implementation of the algorithm applied to C programs. We also provide sufficient conditions for the termination of the method.

Lazy abstraction

ion makes it possible to build non-recursive functions directly inside Calculus of Constructions terms, without giving a name to them, but for recursive functions the Fixpoint command always gives a name to the defined function. It mixes the two operations: first the description of a recursive function, second the definition of a constant having this function as value. With the fix construct, we can have only the first operation; in this sense, it is similar to the abstraction construct. Here is the syntax for this construct: As with the Fixpoint command, the {struct ai} is not mandatory if p = l. In the particular case where one defines only one recursive function the two occurrences of the identifier f must coincide. This identifier is used to denote the recursive function being defined but it can only be used inside the expression expr. The similarity between Fixpoint and fix makes it easier to understand the need for the various parts of this construct. For instance, the mul t2 function could also have been declared in the following manner: Definition mult2' : nat~nat := fix f (n:nat) : nat .= match n with 0 =} 0 I S p =} S (S (f p)) end. Here we have willingly changed the name given to the recursive function inside the fix construct to underline the fact that f is bound only inside the construct. Thus, this identifier has no relation with the name under which the function will be known. 6.4 Polymorphic Types 175 6.4 Polymorphic Types Among the operations that one can perform on binary trees carrying integer values, many rely only on the tree structure, but are independent of the fact that the values are integer values. For instance, we can compute the size or the height of a tree without looking at the values. It is sensible to define a general type of tree, in which the type of elements is left as a parameter, and use instances of this general type according to the needs of our algorithms. This is similar to the polymorphic data structures available in conventional functional languages, or the generic data structures of Ada. We describe this notion of polymorphism on lists, pairs, etc. 6.4.1 Polymorphic Lists The Coq system provides a theory of polymorphic lists in the package List. Require Import List. Print list. Inductive list (A : Set) : Set := nil : list A / cons : A -+ list A -+ list A For nil: Argument A is implicit For cons: Argument A is implicit For list: Argument scope is [type_scope] For nil: Argument scope is [type_scope] For cons: Argument scopes are [type_scope __ ] The Coq system provides a notation for lists, so that the expression" cons a l" is actually denoted "a: : l." We see here that the inductive type being defined does not occur as a simple identifier, but as a dependent type with one argument. The value of this argument is always A, the parameter of the definition, as given in the first line of the definition. This definition behaves as if we were actually defining a whole family of inductive types, indexed over the sort Set. This illustrates the construction of higher-order types that we saw in Chap. 4. There may be several parameters in an inductive definition. When parameters are provided, they must appear at every use of the type being defined. Everything happens as if the inductive type had been declared in a section, with a context where A is bound as a variable. Thus, the definition above is equivalent to a definition of the following form: Section define_lists. Variable A : Set. Inductive list' : Set := I nil' : list' I cons' : A -+ list' -+ list'. End define_lists. 176 6 Inductive Data Types This analogy between polymorphic inductive types and simple inductive types defined inside a section is helpful to understand the form of the induction principle. Let us first study the type of the induction principle as it would have been constructed inside the section: list'_indO : 'v'P : list' --+Prop, P nil' --+ ('v'(x:A)(l:list'), P 1 --+ P (cons' x 1»--+ 'v'x:list', P x. When the section is closed, the variable A is discharged, the type list' must be abstracted over A, the constructors, too, and the induction principle must take these changes into account: Check list'. list' : Set--+Set Check nil'. nil' : 'v' A:Set, list' A Check cons'. cons' : 'v' A:Set, A --+ list' A --+ list' A Check list'_ind. list' ind: 'v' (A:Set)(P:list' A --+ Prop), P (nil' A) --+{V (a:A)(l:list' A), P l--+ P (cons' A a l)) --+ 'v' l:list' A, P l From a practical point of view, an important characteristic of parametric inductive definitions is that the universal quantification appears before the universal quantification over the property that is the object of the proof by induction. This characteristic will be important in comparison with the inductive principles for inductive definitions of variably dependent types (see Sect. 6.5.2) Recursive functions and pattern matching on polymorphic types can be performed in the same manner as for the inductive types of the previous sections. However, there is an important difference; the parameters must not appear in the left-hand side of pattern matching clauses. For instance, the function to concatenate polymorphic lists is defined by an expression of this form: Fixpoint app (A:Set) (1 m:list A){struct I} : list A := match 1 with I nil :::} m I cons a 11 :::} cons a (app A 11 m) end. In this pattern matching construct, nil appears in the left-hand side of its clause without its Set argument. The same occurs for the cons constructor, 6.4 Polymorphic Types 177 even though cons normally has three arguments; the pattern only has two. The reasoh for removing the parameter arguments from the constructors is that these parameters cannot be bound in the pattern. The type A for the values is already fixed because an expression of type "list A" is being analyzed by the pattern matching construct. In the right-hand side of the second clause, cons also appears with two arguments, but this is because the function is defined with the first argument being implicit (see Sect. 4.2.3.1). Use of implicit arguments for functions manipulating polymorphic types is frequent. For instance, the function app also has its first argument as an implicit argument. For this function, the Coq system also provides an infix notation, where "app h h" is actually denoted "h++h." Exercise 6.34 Build a polymorphic function that takes a list as argument and returns a list containing the first two elements when they exist. Exercise 6.35 Build a function that takes a natural number, n, and a list as arguments and returns the list containing the first n elements of the list when they exist. Exercise 6.36 Build a function that takes a list of integers as argument and returns the sum of these numbers. Exercise 6.37 Build a function that takes a natural number n as argument and builds a list containing n occurrences of the number one. Exercise 6.38 Build a function that takes a number n and returns the list containing the integers from 1 to n, in this order. 6.4.2 The option Type Polymorphic types need not be truly recursive. A frequent example is the option type that is well-adapted to describe a large class of partial functions. This type is also present in conventional functional programming languages. Its inductive definition has the following form: Print option. Inductive option (A:Set) : Set := Some: A-+option A / None: option A For Some: Argument A is implicit For None: Argument A is implicit For option: Argument scope is [type_scope] For Some: Argument scopes are [type_scope _] For None: Argument scope is [type_scope] 178 6 Inductive Data Types When we need to define a function that is not total from a type A to a type B, it is often possible to describe it as a total function from A to "option B," with the convention that the value "None" is the result when the function is not defined and the value is "Some y" when the function would have been defined with value y. For instance, the Coq library contains a pred function of type nat---+nat that maps any natural number to its predecessor (when it exists) and maps zero to itself. A partial function could have been defined that does not have a value for the number zero. The definition would have been as follows: Definition pred_option (n:nat) : option nat := match n with 0 => None I S P => Some pend. To use a value of the option type, a case analysis is necessary, to express explicitly how the computation proceeds when no true value is given. For instance, the function that returns the predecessor's predecessor can be defined as follows: Definition pred2_option (n:nat) : option nat := match pred_option n with I None => None I Some p => pred_option p end. As a second example, we can consider the function that returns the nth element of a list. The Coq library provides a function called nth for this requirement but that function takes an extra argument which is used for the result when the list has less than n elements. An alternative could be to define a function whose result belongs in the option type. This function can be defined using simultaneous pattern matching on the number and the list. Both arguments decrease at each recursive call, so that the principal recursion argument could be either of them. Here is one of the two possible versions: Fixpoint nth_option (A:Set) (n:nat) (l:list A){struct l} : option A := match n, 1 with I 0, cons a tl => Some a I S p, cons a tl => nth_option A p tl I n, nil => None end. Exercise 6.39 Define the other variant "nth_option'." The arguments are given in the same order, but the principal argument is the number n. Prove that both functions always give the same result when applied on the same input. Exercise 6.40 * Prove V(A:Set)(n:nat)(l:list A), nth_option A n 1 = None ---+ length 1 < n. 6.4 Polymorphic Types 179 Exercise 6.41 * Define a function that maps a type A in sort Set, a function f of type A---+booL, and a list L to the first element :z: in L such that "f x" is true. 6.4.3 The Type of Pairs Pairs prov

Interactive Theorem Proving and Program Development

Coq is a proof assistant based on a higher-order logic allowing powerful definitions of functions. Coq V6.1 is available by anonymous ftp at ftp.inria.fr:/INRIA/Projects/coq/V6.1 and ftp.ens-lyon.fr:/pub/LIP/COQ/V6.1

https://hal.inria.fr/inria-00069968/document

The Coq proof assistant : reference manual, version 6.1

We present Why3, a tool for deductive program verification, and WhyML, its programming and specification language. WhyML is a first-order language with polymorphic types, pattern matching, and inductive predicates. Programs can make use of record types with mutable fields, type invariants, and ghost code. Verification conditions are discharged by Why3 with the help of various existing automated and interactive theorem provers. To keep verification conditions tractable and comprehensible, WhyML imposes a static control of aliases that obviates the use of a memory model. A user can write WhyML programs directly and get correct-by-construction OCaml programs via an automated extraction mechanism. WhyML is also used as an intermediate language for the verification of C, Java, or Ada programs. We demonstrate the benefits of Why3 and WhyML on non-trivial examples of program verification.

/pdf/why3-where-programs-meet-provers-41zqtwtnhv.pdf

Why3: where programs meet provers

We present the Why/Krakatoa/Caduceus set of tools for deductive verification of Java and C source code.

/pdf/the-why-krakatoa-caduceus-platform-for-deductive-program-3q9gd8qopm.pdf

The Why/Krakatoa/Caduceus platform for deductive program verification

Why3 is the next generation of the Why software verification platform. Why3 clearly separates the purely logical specification part from generation of verification conditions for programs. This article focuses on the former part. Why3 comes with a new enhanced language of logical specification. It features a rich library of proof task transformations that can be chained to produce a suitable input for a large set of theorem provers, including SMT solvers, TPTP provers, as well as interactive proof assistants.

http://proval.lri.fr/submissions/boogie11.pdf

Why3: Shepherd Your Herd of Provers

ion The term \lambda τ1 x1, . . . , τn xn ; t denotes the n-ary logic function which maps x1, . . . , xn to t. It has the same precedence as \forall and \exists In this latter case, note that the two ’>’ must be separated by a space, to avoid confusion with the shift operator. ANSI/ISO C Specification Language CAT RNTL project 2.6 Logic specifications 39 term ::= \lambda binders ; term abstraction | extended-quantifier ( term , term , term ) extended-quantifier ::= \max | \min | \sum | \product | \numof Figure 2.12: Grammar for higher-order constructs Extended quantifiers Terms \quant(t1, t2, t3) where quant is max min sum product or numof are extended quantifications. t1 and t2 must have type integer, and t3 must be a unary function with an integer argument, and a numeric value (integer or real) except for \numof for which it should have a boolean value. Their meanings are given as follows: \max(i, j, f) = max{f(i), f(i+ 1), . . . , f(j)} \min(i, j, f) = min{f(i), f(i+ 1), . . . , f(j)} \sum(i, j, f) = f(i) + f(i+ 1) + · · ·+ f(j) \product(i, j, f) = f(i)× f(i+ 1)× · · · × f(j) \numof(i, j, f) = #{k | i ≤ k ≤ j && f(k)} = \sum(i, j,\lambda integer k; f(k)?1 : 0) If i > j then \sum and \numof above are 0, \product is 1, and \max and \min are unspecified (see Section 2.2.2). Example 2.28 Function that sums the element of an array of doubles. /*@ requires n ≥ 0 ∧ \valid(t+(0..n−1)) ; @ ensures \result ≡ \sum(0,n−1,\lambda int k; t[k]); @*/ double array_sum(double t[],int n) { int i; double s = 0.0; /*@ loop invariant 0 ≤ i ≤ n; @ loop invariant s ≡ \sum(0,i−1,\lambda int k; t[k]); @ loop variant n−i; */ for(i=0; i = Nil | Cons(A,list ); ANSI/ISO C Specification Language CAT RNTL project 40 Specification language logic-type-decl ::= type logic-type = logic-type-def ; logic-type-def ::= record-type | sum-type | type-expr type abbreviation record-type ::= { type-expr id (; type-expr id)∗ ;? } sum-type ::= | constructor (| constructor)∗ constructor ::= id constant constructor | id ( type-expr (, type-expr)∗ ) non-constant constructor type-expr ::= ( type-expr (, type-expr)+ ) product type term ::= term . id record field access | \match term { match-cases } pattern-matching | ( term (, term)+ ) tuples | { (. id = term ;)+ } records | \let ( id (, id)+ ) = term ; term match-cases ::= match-case match-case ::= case pat : term pat ::= id constant constructor | id ( pat (, pat)∗ ) non-constant constructor | pat | pat or pattern | _ any pattern | cst numeric constant | { (. id = pat)∗ } record pattern | ( pat (, pat)∗ ) tuple pattern | pat as id pattern binding Figure 2.13: Grammar for concrete logic types and pattern-matching introduces a concrete definition of finite lists. The logic definition /*@ logic integer list_length (list l) = @ \match l { @ case Nil : 0 @ case Cons(h,t) : 1+list_length(t) @ }; @*/ defines the length of a list by recursion and pattern-matching. 2.6.5 Hybrid functions and predicates Logic functions and predicates may take both (pure) C types and logic types arguments. Such an hybrid predicate (or function) can either be defined with the same syntax as before, or simply declared, but in the latter case the declaration should usually be augmented with a reads clause, with the syntax given in Figure 2.14, which extends the one of Figure 2.11. This feature is useful when a function or a predicate is not easily definable, but can be more easily axiomatized. ANSI/ISO C Specification Language CAT RNTL project 2.6 Logic specifications 41 logic-function-decl ::= logic type-expr poly-id parameters reads-clause ; logic-predicate-decl ::= predicate poly-id parameters? reads-clause ; reads-clause ::= reads locations logic-function-def ::= logic type-expr poly-id parameters reads-clause = term ; logic-predicate-def ::= predicate poly-id parameters? reads-clause = pred ; poly-id ::= id normal identifier | id type-var-binders identifier for polymorphic object | id label-binders normal identifier with labels | id label-binders type-var-binders polymorphic identifier with labels label-binders ::= { id (, id)∗ } Figure 2.14: Grammar for logic declarations with reads clauses Be it defined either directly by an expression or through a set of axioms, an hybrid function (or predicate) usually depends on one or more program points, because it depends upon memory states, via expressions such as: • pointer dereferencing: *p, p->f; • array access: t[i]; • address-of operator: x • built-in predicate depending on memory: \valid To make such a definition safe, it is mandatory to add after the declared identifier a set of labels, between curly braces. Expressions as above must then be enclosed into the \at construct to refer to a given label. However, to ease reading of such logic expressions, it is allowed to omit a label whenever there is only one label in the context. Example 2.30 The following annotations declare a function which returns the number of occurrences of a given double in an array of doubles between the given indexes, together with the related axioms. It should be noted that without the reads clauses, this axiomatization would be inconsistent, since the function would not depend on the values stored in t, hence the two last axioms would say both that a = b+ 1 and a = b for some a and b. /* nb_occ(t,i,j,e) gives the number of occurrences of e in t[i..j] * (in a given memory state labelled L) */ /*@ logic integer nb_occ{L}(double t[], integer i, integer j, @ double e) ANSI/ISO C Specification Language CAT RNTL project 42 Specification language @ reads t[..]; @*/ /* Notice that without label {L}, t[..] would be rejected. * With {L}, it is indeed a shortcut for \at (t[..],L). */ /*@ axiom nb_occ_empty{L} : @ ∀ double t[], integer i, integer j, double e; @ i > j =⇒ nb_occ(t,i,j,e) ≡ 0; @*/ // without {L}, term nb_occ(t,i,j,e) would be rejected /*@ axiom nb_occ_true{L} : @ ∀ double t[], integer i, integer j, double e; @ i ≤ j ∧ t[i] ≡ e =⇒ @ nb_occ(t,i,j,e) ≡ nb_occ(t,i,j−1,e) + 1; @*/ // without {L}, term ti would be rejected, here it is \at (ti,L) /*@ axiom nb_occ_false{L} : @ ∀ double t[], integer i, integer j, double e; @ i ≤ j ∧ t[i] 6≡ e =⇒ @ nb_occ(t,i,j,e) ≡ nb_occ(t,i,j−1,e); @*/ Example 2.31 This second example defines a predicate which indicates whether two arrays of the same size are a permutation of each other. It illustrates the use of more than a single label. Thus, the \at operator is mandatory here. Indeed the two arrays may come from two distinct memory states. Typically, one of the post condition of a sorting function would be permut{Pre,Here}(t,t). /* permut{L1,L2}(t1,t2,n) is true whenever t1[0..n−1] in state L1 * is a permutation of t2[0..n−1] in state L2 */ /*@ predicate permut{L1,L2}(double t1[], double t2[], integer n) @ reads \at(t1[..],L1), \at(t2[..],L2); @*/ /*@ axiom permut_refl{L} : @ ∀ double t[], integer n; permut{L,L}(t,t,n); @*/ /*@ axiom permut_sym{L1,L2} : @ ∀ double t1[], double t2[], integer n; @ permut{L1,L2}(t1,t2,n) =⇒ permut{L2,L1}(t2,t1,n) ; @*/ ANSI/ISO C Specification Language CAT RNTL project 2.6 Logic specifications 43 /*@ axiom permut_trans{L1,L2,L3} : @ ∀ double t1[], double t2[], double t3[], integer n; @ permut{L1,L2}(t1,t2,n) ∧ permut{L2,L3}(t2,t3,n) @ =⇒ permut{L1,L3}(t1,t3,n) ; @*/ /*@ axiom permut_exchange{L1,L2} : @ ∀ double t1[], double t2[], integer i, integer j, integer n; @ \at(t1[i],L1) ≡ \at(t2[j],L2) ∧ @ \at(t1[j],L1) ≡ \at(t2[i],L2) ∧ @ (∀ integer k; 0 ≤ k = Nil | Cons(A , list ); @ @ logic integer length (list l) = @ \match l { @ case Nil : 0 @ case Cons(h,t) : 1+length(t) } ; @ @ logic A fold_right ((A −> B −> B) f, list l, B acc) = @ \match l { @ case Nil : acc @ case Cons(h,t) : f(h,fold(f,t,acc)) } ; @ @ logic list filter ((A −> boolean) f, list l) = @ fold_right((\lambda A x, list acc; @ f(x) ? Cons(x,acc) : acc), Nil) ; @ @ } @*/ Module components are then accessible using a qualified notation like List::length . Predefined algebraic specifications can be provided as libraries (see section 3), and imported using a construct like

Jean-Christophe Filliâtre

Papers

The Coq proof assistant : reference manual, version 6.1

Why3: where programs meet provers

The Why/Krakatoa/Caduceus platform for deductive program verification

Why3: Shepherd Your Herd of Provers

ACSL: ANSI/ISO C Specification Language