> <\body> <\hide-preamble> \; >> > > ||>> |> > |> \; University of WrocŖaw Department of Mathematics and Computer Science Institute of Computer Science >>|<\doc-misc> |> cowych>||<\author-affiliation> Uniwersytet WrocŖawski WydziaŖ Matematyki i Informatyki Instytut Informatyki >>|<\doc-misc> |> Type systems for programming languages are both a first line of defense against programmer mistakes, and an aid in structuring programs around data structures and functions that manipulate them. Type systems are a natural formalism for language extensions that express those aspects of program specifications which can be automatically, statically checked. Type inference enhances programmer efficiency and code adaptability by providing the types of expressions to the programmer, rather than asking the programmer for the types. There is a long line of research on automated program analysis and verification by generating specifications that a program does obey, for example generating loop invariants. This thesis extends a familiar type system for functional programming languages and provides a type inference algorithm that generates invariants and postconditions of recursive functions. Generalized Algebraic Data Types (GADTs) extend polymorphic type systems by introducing reasoning by cases into type-checking of definitions by cases. We present a GADTs type system based on Franēois Pottier and Vincent Simonet's but without type annotations. We extend it to a language with existential types represented as implicitly defined and used GADTs. We show that the type inference problem reduces to satisfaction of second order constraints. We solve the constraints by iterating: (1) constraint generalization, which finds most specific common consequences; and (2) joint constraint abduction, which finds most general common explanations. Abduction is used to generate invariants, infer and check types. Generalization is used to generate existential types, which serve as postconditions. The constraints include linear arithmetic (equations and inequalities). We called the system implementing these techniques . It solves a vast majority of inference tasks we attempted, without type annotations. solves nearly all meaningful GADTs inference tasks we tried, clearly more than all earlier type inference implementations for GADTs. It also solves clearly more invariant and postcondition inference tasks than the approach, except for some programs with higher-order functions. In addition, we present a selection of new inference tasks, for programs manipulating lists with length, binary numbers and AVL trees of imbalance 2. These programs can serve as baseline tests for future research on invariant and postcondition inference. > > Systemy typów dla j¦zyków programowania s” zarówno pierwsz” lini” obrony przed bŖ¦dami programistycznymi, jak i pomoc” przy strukturowaniu programów wokóŖ struktur danych oraz funkcji które nimi manipuluj”. Systemy typów to dobry formalizm do wyra»ania tych aspektów specyfikacji programów, które mog” by¢ automatycznie, statycznie sprawdzone. Inferencja typów zwi¦ksza wydajno±¢ programisty i adaptowalno±¢ kodu dostarczaj”c programi±cie typy wyra»e«, zamiast wymaga¢ podawania typów. Badania nad automatyczn” analiz” i weryfikacj” programów od dawna obejmowaŖy mi¦dzy innymi generowanie specyfikacji speŖnianych przez dane programy, na przykŖad generowanie niezmienników p¦tli. Ta praca rozszerza znany system typów dla j¦zyków funkcyjnych i podaje algorytm inferencji typów, generuj”cy niezmienniki i warunki ko«cowe funkcji rekurencyjnych. Generalized Algebraic Data Types (GADTs) rozszerzaj” systemy typów polimorficznych o wnioskowanie przez przypadki podczas sprawdzania typu definicji przez przypadki. Prezentuj¦ system typów > z GADTs, oparty o system typów > Franēois Pottiera i Vincenta Simoneta ale bez annotacji typami. Rozszerzam go do j¦zyka z typami egzystencjalnymi reprezentowanymi jako domy±lnie definiowane i u»ywane struktury GADTs. Pokazuj¦ redukcj¦ problemu inferencji typów do speŖnialno±ci wi¦zów drugiego rz¦du. Wi¦zy drugiego rz¦du rozwi”zuj¦ iteruj”c dwa algorytmy: (1) generalizacj¦ wi¦zów, znajduj”c” najbardziej specyficzn” wspóln” konsekwencj¦ wi¦zów; (2) Ŗ”czn” abdukcj¦ wi¦zów, znajduj”ca najogólniejsze wspólne obja±nienie, przesŖank¦ implikuj”c” wi¦zy. Abdukcji u»ywamy gŖównie do generowania niezmienników, inferencji i sprawdzania typów. Generalizacji u»ywamy do generowania typów egzystencjalnych, sŖu»”cych jako warunki ko«cowe. Wi¦zy obejmuj” arytmetyk¦ liniow” (równania i nierówno±ci). System implementuj”cy te techniki nazwaŖem . Rozwi”zuje on zdecydowan” wi¦kszo±¢ zada« inferencji które opracowaŖem lub zaadaptowaŖem, bez annotacji typami. rozwi”zuje zdecydowanie wi¦cej zada« inferencji typów dla GADTs ni» dotychczasowe systemy. Rozwi”zuje te» wi¦cej problemów inferencji niezmienników i warunków ko«cowych ni» podej±cie , je±li ograniczymy si¦ do zada« nie potrzebuj”cych inferencji niezmienników dla argumentów funkcji wy»szego rz¦du. Dodatkowo, prezentuj¦ kilka programów operuj”cych na listach z dŖugo±ci”, liczbach binarnych i drzewach AVL o niezbalansowaniu nie przekraczaj”cym 2. Te programy mog” sŖu»y¢ jako cz¦±¢ testów dla przyszŖych prac nad wszechstronnymi systemami inferencji niezmienników i warunków ko«cowych. > I thank my advisor Leszek Pacholski for supporting the great opportunity to pursue this work despite my excursions to other topics and projects. I thank Šukasz Kaiser for feedback and support through the years. My office colleague Jan Otop offered discussions early in my work. Dariusz Biernacki reviewed and helped improve my conference paper. Filip Sieczkowski, Jakub Michaliszyn and Marek Materzok remarks helped improve the thesis presentation. All the technical errors are my sole responsibility. Most of all, I dedicate this thesis to my parents Maria and Piotr, without whose support this work would not have been possible. \; \; \; \; \; <\right-aligned> David Deutsch's Law <\table-of-contents|toc> |.>>>>|> |.>>>>|> |.>>>>|> Introduction> |.>>>>|> 1.1.Contributions |.>>>>|> 1.2.Examples |.>>>>|> Background and Related Work> |.>>>>|> 2.1.The DML System |.>>>>|> The Type System |.>>>>|> > Bidirectional Type Inference |.>>>>|> > Relevance |.>>>>|> > 2.2.The > Formalization |.>>>>|> The Untyped Calculus |.>>>>|> > The > Type System |.>>>>|> > Constraint Derivation |.>>>>|> > Relevance |.>>>>|> > 2.3.The > System |.>>>>|> Type Inference |.>>>>|> > Relevance |.>>>>|> > 2.4.Pointwise GADTs |.>>>>|> Type Inference |.>>>>|> > Relevance |.>>>>|> > 2.5.Liquid Types |.>>>>|> The Type System |.>>>>|> > Liquid Types Inference |.>>>>|> > Relevance |.>>>>|> > 2.6.Herbrand Constraint Abduction |.>>>>|> Relevance |.>>>>|> > The Type System> |.>>>>|> 3.1.The Language of Constraints |.>>>>|> 3.2.The Type System with GADTs |.>>>>|> 3.3.Type Inference Constraints |.>>>>|> 3.4.Existential Types |.>>>>|> 3.5.Type Inference Constraints for Existential Types |.>>>>|> 3.6.Semantics by Reduction to > |.>>>>|> Solving Second Order Constraints> |.>>>>|> 4.1.Overview of Solving for Predicate Variables |.>>>>|> 4.2.Constraint Abduction |.>>>>|> Formulating the Joint Constraint Abduction Problem |.>>>>|> > Abduction Algorithm for The Combination of Domains |.>>>>|> > Joint Constraint Abduction |.>>>>|> > Simple Constraint Abduction |.>>>>|> > Abduction for Terms |.>>>>|> > Abduction for Linear Arithmetic |.>>>>|> > 4.3.Constraint Generalization |.>>>>|> Algorithm for Combining Domains |.>>>>|> > Linear Arithmetic |.>>>>|> > Abductive Constraint Generalization |.>>>>|> > 4.4.Negative Constraints |.>>>>|> 4.5.Details of Solving for Predicate Variables |.>>>>|> : Tests and Limitations> |.>>>>|> 5.1.Benchmarks |.>>>>|> 5.2. Failure Cases |.>>>>|> The Need to Expand Pattern Variables |.>>>>|> > Constraints Shared by Constructors of a Datatype |.>>>>|> > Negative Constraints in the Sort of Terms |.>>>>|> > Insufficient Context to Infer Postconditions |.>>>>|> > Insufficient Search |.>>>>|> > Nested Definitions with Tied Postconditions |.>>>>|> > Conclusions> |.>>>>|> 6.1.Related Work |.>>>>|> 6.2.Future Work |.>>>>|> 6.3.Summary |.>>>>|> |.>>>>|> Proofs> |.>>>>|> A.1.The Type System |.>>>>|> The Logic of Constraints |.>>>>|> > The GADT Type System |.>>>>|> > Existential Types |.>>>>|> > Semantics by Reduction to > |.>>>>|> > A.2.Constraint Abduction |.>>>>|> Formulating the Joint Constraint Abduction Problem |.>>>>|> > Abduction Algorithm for The Combination of Domains |.>>>>|> > A.3.Constraint Generalization |.>>>>|> A.4.Solving for Predicate Variables |.>>>>|> Algorithmic Details> |.>>>>|> B.1.Generating and Normalizing Formulas |.>>>>|> Normalization |.>>>>|> > Implementation Details |.>>>>|> > Simplification |.>>>>|> > B.2.Abduction |.>>>>|> Abduction for Terms with Alien Subterms |.>>>>|> > Joint Constraint Abduction |.>>>>|> > Simple Constraint Abduction for Terms |.>>>>|> > Heuristic for Better Answers to Invariants |.>>>>|> > Simple Constraint Abduction for Linear Arithmetics |.>>>>|> > B.3.Constraint Generalization |.>>>>|> Extended Convex Hull |.>>>>|> > Issues in Inferring Postconditions |.>>>>|> > Abductive Constraint Generalization |.>>>>|> > B.4.Incorporating Negative Constraints |.>>>>|> B.5. and : and Relations in |.>>>>|> Normalization, Validity and Implication Checking |.>>>>|> > Abduction |.>>>>|> > Constraint Generalization |.>>>>|> > B.6.Solving for Predicate Variables |.>>>>|> Solving for Predicates in Premises |.>>>>|> > Solving for Existential Types Predicates and Main Algorithm |.>>>>|> > Stages of Iteration |.>>>>|> > Implementation Details |.>>>>|> > B.7.Generating OCaml Source and Interface Code |.>>>>|> Source Code of Examples> |.>>>>|> C.1.Incompleteness Example for : Function |.>>>>|> C.2.Pointwise Examples |.>>>>|> Function |.>>>>|> > Function : -way |.>>>>|> > Function |.>>>>|> > Function |.>>>>|> > Function |.>>>>|> > Function |.>>>>|> > C.3.Non-Pointwise Examples |.>>>>|> Function |.>>>>|> > Function |.>>>>|> > Function |.>>>>|> > Function |.>>>>|> > Function : -way |.>>>>|> > Function |.>>>>|> > Function |.>>>>|> > C.4.Run-time Type Representations |.>>>>|> Function |.>>>>|> > Function |.>>>>|> > C.5.Lists with Length |.>>>>|> Function |.>>>>|> > Function |.>>>>|> > Function |.>>>>|> > Function |.>>>>|> > Function |.>>>>|> > C.6.Binary Numbers |.>>>>|> Function |.>>>>|> > Function |.>>>>|> > Function |.>>>>|> > C.7.AVL Trees |.>>>>|> C.8.Arrays and Matrices |.>>>>|> Program |.>>>>|> > Program |.>>>>|> > Program |.>>>>|> > Function |.>>>>|> > Program |.>>>>|> > Function |.>>>>|> > Program |.>>>>|> > Program |.>>>>|> > Program |.>>>>|> > Program |.>>>>|> > Program |.>>>>|> > Program |.>>>>|> > Program |.>>>>|> > : Manual> |.>>>>|> D.1.Introduction |.>>>>|> D.2.Tutorial |.>>>>|> D.3.Syntax |.>>>>|> D.4.Solver Parameters and CLI |.>>>>|> D.5.Limitations of Current Inference |.>>>>|> Type systems are established natural deduction-style means to specify programs. Dependent types can represent arbitrarily complex properties as they use the same language for both types and programs. The type of the value returned by a function can itself be a function of the argument. Generalized Algebraic Data Types (GADTs) bring some of that expressiveness to type systems with data-types and parametric polymorphism, by introducing the ability to reason about the return type by case analysis on the input value. Work over the past decade (Pottier and Régis-Gianas , Schrijvers, Peyton Jones, SulzmannVytiniotis , LinSheard ) shows that type systems with GADTs can remain tractable from a compiler implementer's perspective if appropriately constrained, i.e. have principal typings and efficient type inference. Our work is based on Simonet and Pottier instead, which is the most general presentation of GADTs. Our methods are computationally intensive and involve search with backtracking. We expect to be able to infer types for more programs than all of the efficiency-oriented approaches. Our work could bear the title , but we stress that we do not compete with the work of , in particular. We are concerned with type inference for recursive definitions which are not given their type beforehand. This polymorphic recursion problem has been tackled by with GADTs, by Schrijvers and Bruynooghe without GADTs. The line of work following Unno and Kobayashi also tackles reconstruction of types for recursive definitions, but without ADTs and without polymorphic recursion. Our intended usage is that the generated types of recursive definitions be integrated into the source code, via integration with an IDE. Existential types hide some information conveyed in a type. We may opt to use them to expose a more abstract interface. However, sometimes we are forced to use existential types to hide what cannot be expressed in the type system. GADTs provide existential types by using local type variables for the hidden parts of the type encapsulated in a GADT. With no other way to express existential types, programmers need to introduce by hand spurious data-types for them. For example, if we want to hide the length of a list in OCaml, we need to define 'a elist>, where is the type of lists of length with elements of type . The type system in XiPfenning for a language called Dependent ML, a precursor for GADTs, has a more light-weight approach: explicit existential types. But has limited type inference, and we find its type system harder to grasp than the more recent presentations of GADTs. KnowlesFlanagan and UnnoKobayashi can be seen as performing type inference for forms of existential types. We provide full reconstruction of existential types. The feedback provided by type inference makes strongly typed programming more convenient in several ways. It softens the learning curve by enabling learning of types by experimentation. It facilitates rapid prototyping and code refactoring by reporting the types of functions when the programmer experiments with invariants of data-types. Besides providing certain correctness guarantees, types also serve as documentation -- it is good to keep them around. If type inference results are incorporated in the source code, type checking might suffice during slow evolution of a code base, while the rich types document the code. Our type system for GADTs differs from others in that we do not require any type annotations on expressions, even on recursive functions. Inference in our implementation sometimes requires guidance by clauses. Our implementation includes linear arithmetic in the language used to express invariants and postconditions, with the possibility to introduce more domains in the future. The arithmetic properties are conjunctions of equations and inequalities, where a side can be either a linear combination, or a maximum or minimum of (at most two) linear combinations. <\example> We can easily specify the data-type of AVL trees with height imbalance of at most 2: <\code> datatype Avl : type * num datacons Empty : >a. Avl (a, 0) datacons Node : >a,k,m,n \ \ [k=max(m,n) > 0>m > 0>n > n>m+2 > m>n+2]. \ \ \ \ \ Avl (a, m) * a * Avl (a, n) * Num (k+1) \ \ \ \ \ > Avl (a, k+1) A similar definition can be given in the DML and ATS languages by Hongwei Xi (see ). Given this type definition and AVL tree algorithms, automatically finds out that the height of a tree with added element can be the same as original tree or bigger by 1, and that removing an element can decrease the height of a tree by at most 1, returning, among others, the types: <\code> add : \ \ >a,n.a>Avl(a, n)>>k[k>n+1 > 1>k > n>k].Avl(a, k) remove : \ \ >a,n.a>Avl(a, n)>>k[n>k+1 > 0>k > k>n].Avl(a, k) There are no places requiring type annotations or informative assertions in the source code of AVL tree algorithms including the above functions and their helper functions. We reduce the type inference task to constraint satisfaction, which in addition to finding substitutions for first order variables, finds solutions to the predicate unknowns. As the predicate-finding techniques that we present in Chapter (especially abduction) improve, type inference will work for more programs. The downside is that we do not specify declaratively the limitations of type inference. That is, while we provide some guarantees that our approach to inference does not overlook solutions (completeness-like result at the end of Section ), there is no concise formulation of when type inference succeeds. Constraints appear in three contexts in programs and inferred signatures: <\itemize> In specifications of value constructors (symbolically \|\>.\\\\\\\|\>|)>>). We call the constraint (i.e. ) the invariant (of ). In type schemes, which usually are signatures of values (symbolically >.\>). We call the constraint (i.e. ) the invariant or the precondition (of ), interchangeably. In existential types (symbolically |\>.\>); existential types usually occur in result positions of function types in type schemes. We call the constraint (i.e. ) the postcondition (of the corresponding function or computation). In order to implement , we needed to resolve several issues, leading to our contributions: <\itemize> Design a type system that captures invariants (Section ) and postconditions (Section ).\ Reduce type inference to satisfaction of second order constraints (Sections and ). Employ invariant-finding abduction and postcondition-finding generalization in an algorithm that reconstructs correct types (Section ). Develop constraint abduction algorithms that handle universally quantified variables (Section ). Develop constraint generalization algorithms. Constraint generalization computes anti-unification in case of free terms and extended convex hull in case of linear inequalities (Section ). To summarize, the novelty of our work lies in: <\enumerate> performing type inference for GADTs with polymorphic recursion for more programs than in prior work (), introducing existentials into the GADT type system with minimal added complexity, by using GADT encodings, and performing type inference for them, implementing the type inference over a constraint domain with linear arithmetics, thus performing numerical precondition and postcondition generation for recursive functions (in a different manner than in Rondon, Kawaguchi and Jhala ). We discuss related work in Chapter and Section . There remains work to be done, as we discuss in Section and Section . can be found at >. It solves a vast majority of inference tasks we attempted, without type annotations. solves all but 3 tasks from Lin (2 unsolved are practical, one of them is solved after a slight meaning-preserving modification); the system from does not solve 8 of those tasks (7 unsolved are practical). We translated into all but 3 tasks from Rondon, Kawaguchi and Jhala -- all tasks that uses for comparison with Xi and Pfenning's DML system , . solves all but 2 of these inference tasks without any type annotation, and solves the remaining 2 tasks after a slight meaning-preserving change to the programs (still without any type annotation). The system from implementing the approach needs a type annotation for 3 of these inference tasks. The inference times of and are of the same order. Overall, the approach solves clearly more inference tasks than the approach, when the programs do not have higher-order functions that require universally quantified invariants for arguments, including existentially quantified invariants for arguments of arguments. In addition, we present a selection of new inference tasks, for programs manipulating lists with length, binary numbers and AVL trees of imbalance 2. They can serve as a baseline for future research. We expect that some of them are beyond the capabilities of any current type inference system, except . does not introduce new linear combinations into generated constraints, therefore will not solve some of these inference tasks. The recent system , see He Zhu, Aditya Nori and Suresh Jagannathan , cannot solve tasks like the AVL trees example, without any type annotations or assertions. To motivate the language constructs and type system rules, we start with some examples. The concrete syntax of is similar to that of OCaml. The sort of a type variable is identified by the first letter of the variable. ,,,,,,,... are in the sort of ``proper'' types. ,,,,,,,... are in the sort of linear arithmetic over rational numbers. Type constructors and value constructors have the same syntax: capitalized name followed by a tuple of arguments. They are introduced by the keywords and respectively. The result sort of is always and is omitted. By of a source file we mean the environment of names available for potential code appended to the end of the file. Values assumed into the toplevel without definition are introduced by the keyword . We can introduce existential types directly in type declarations. To have an existential type inferred, we have to use , or expressions, which differ from , and correspondingly only in that the (return) type is an existential type. To use, i.e. unpack, a value of an existential type, we have to bind it with a .. expression. An existential type will be automatically unpacked before being ``repackaged'' as another existential type. In a future version, it might be possible to use existential types without explicit introduction (the , or syntax) and explicit elimination (the need of .. expressions) at a cost of longer inference times. <\example> Table defines an artificial example using phantom types (i.e. types used for type information, without values), resembling binary numbers. The function erases the ``zeros'' and adds one .<\float|float|t> <\big-table> <\code> datatype Z datatype I : type datatype O : type datatype Binary : type datacons BinaryZ : Binary Z datacons BinaryO : >a. Binary a > Binary (O a) datacons BinaryI : >a. Binary a > Binary (I a) \; let rec erase_zeros = efunction \ \ \| BinaryZ -\> BinaryI BinaryZ \ \ \| BinaryO x -\> erase_zeros x \ \ \| BinaryI x -\> let y = erase_zeros x in BinaryI y \; We get >a.Binary a>>a.Binary (I a)>. The resulting type forgets the shape of the content, other than the fact that it starts with a . The first branch of returns a value directly. The second branch directly performs the recursive call -- the existential type of the result is unpacked and ``repackaged''. The third branch unpacks the result of the recusrive call explicitly. By design, the inlined variant BinaryI (erase_zeros x)> would not type-check. The type system does not allow passing values of existential types as arguments. commits to a type of a toplevel definition before proceeding to the next one, so sometimes we need to provide more information in the program. Besides type annotations, there are three means to enrich the generated constraints: indicates an unreachable code location and provides a negative constraint, >\=e>> and >=e>> provide positive constraints, and the syntax includes constraints of the use cases appearing after with the constraint of a toplevel definition. <\example> Table defines a function comparing values provided representation of their types. The value constructors , , are used to represent the types of values compared. The function checks whether the second and third argument are of the same type, and if so, whether they are equal.<\float|float|t> <\big-table> <\code> datatype List : type datacons Nil : >a. List a datacons Cons : >a. a * List a > List a datatype TypeRepr : type datacons TInt : TypeRepr Int datacons TPair : >a, b. TypeRepr a * TypeRepr b > TypeRepr (a, b) datacons TList : >a. TypeRepr a > TypeRepr (List a) external let eq_int : Int > Int > Bool = "(=)" external let b_and : Bool > Bool > Bool = "fun a b -\ a && b" external let b_not : Bool > Bool = "fun b -\ not b" external let forall2 : \ \ >a, b. (a>b>Bool) > List a > List b > Bool = \ \ "fun f a b -\ List.for_all2 f a b" external let zero : Int = "0" \; let rec equal = function \ \ \| TInt, TInt -\> fun x y -\> eq_int x y \ \ \| TPair (t1, t2), TPair (u1, u2) -\> \ \ \ \ \ (fun (x1, x2) (y1, y2) -\> \ \ \ \ \ \ \ \ b_and (equal (t1, u1) x1 y1) \ \ \ \ \ \ \ \ \ \ \ \ \ \ (equal (t2, u2) x2 y2)) \ \ \| TList t, TList u -\> forall2 (equal (t, u)) \ \ \| _ -\> fun _ _ -\> False \ \ \| TInt, TList l -\> \ \ \ \ (function Nil -\> assert false) \ \ \| TList l, TInt -\> \ \ \ \ (function _ -\> function Nil -\> assert false) test b_not (equal (TInt, TList TInt) zero Nil) \; We get >a,b.(TypeRepr a, TypeRepr b)>a>b>Bool>. To ensure only one maximally general type for , it is sufficient to provide either the two clauses, or the clause; both are illustrated above. The first assertion excludes independence of the first encoded type and the second argument. The second assertion excludes independence of the second encoded type and the third argument. The test ensures that arguments of distinct types can be given. Besides displaying types of toplevel definitions, also exports an OCaml source file with all the required GADT definitions and type annotations. In this chapter, we provide background knowledge and context by taking an in-depth look at a selection of related work. Sections and constitute a proper background for later chapters. The remaining sections describe alternative approaches to type inferece for GADTs, and more broadly to the task of automatic generation and verification of program specifications for functional programming languages like OCaml. Readers familiar with the works cited below may skip directly to the subsections , where we contrast the corresponding work with . The final chapter's Section provides a broader perspective on related work. The theoretical underpinnings of type systems for program specification trace back to the work on dependent types by Per Martin-Löf, for example . An early example of a practical programming language based on dependent types is Cayenne by Lennart Augustsson, . A currently popular example of such language is Idris by Edwin Brady , see also Brady, Herrmann and Hammond . But the family of approaches our thesis belongs to, maintains the separation of types and values characteristic of languages like Pascal, C, OCaml and Haskell. This separation allows to employ domain-specific decision procedures to reason about types, and also to automatically infer types. We start with Hongwei Xi and Frank Pfenning , which not only is a precursor of GADTs research, but also stresses the importance of existential types and type inference. We present the > system from Simonet and Pottier , to motivate and gain familiarity with the formalism of our constraint-based type system. We then present Schrijvers, Peyton Jones, Sulzmann and Vytiniotis , and Lin and Sheard , to illustrate one thread of approaches to type inference for type systems with GADTs. Then, we switch gears to discuss inference of invariants, known as from Rondon, Kawaguchi and Jhala , expanded in and . Finally, we describe Maher and Huang , which provides the basis for our constraint abduction algorithm for terms. We take liberties with the presentation of the systems described, except > where we stay close to the letter of . We apologize for any unfortunate resulting errors and misunderstandings, and encourage interested readers to consult the original publications. The work of Hongwei Xi and Frank Pfenning , see also , was at the forefront of research introducing type system features modeled on dependent types into practical programming languages of the ML family. These features mediate the dependence of types on terms by the use of strongly constrained types, including singleton types, i.e. types inhabited by single terms. They were later simplified and further developed to fit within the polymorphic (non-dependent) type systems. Together with an independent work at the time by Christoph Zenger , and an earlier work by Konstantin Läufer and Martin Odersky , these efforts are the origins of Generalized Algebraic Data Types. Hongwei Xi's > is parameterized by a constraint domain , and, like , the implementation includes linear arithmetics. We will discuss a small selection of type system rules and then the approach to type inference taken by the DML system. The reader should not expect to gain understanding of DML from this short exposition, in part because it is a complex system. Type judgments in > have naturally a different form for patterns than for expressions. For pattern , type >, formula >, and environment assigning expression variables to types >, we write \\;\|)>> to mean that pattern , when matched against an expression of type >, allows us to type-check its corresponding branch in the context of an environment enriched by > and under a constraint enriched by >. In our notation: \\\|\>|]>\>. The fresh type variables |\>> are in fact introduced inside > in >. For expression , type >, formula >, type environment > assigning sorts to type variables, and environment > assigning types to expression variables, we write ;\;\\e:\> to mean that expression has type > in the context of the environments ,\> and the constraint formula >. In our notation: ;\\e:\>, because we discriminate the sorts of type variables by the names of the variables. One of the most interesting rules of > connects these two forms of judgments: <\equation*> \\;\|)>\\\;\;\\\e:\|\;\;\\p\e:\\\> The notation \\> is used instead of a function type \\> to indicate an ``internal'' use of a pattern matching branch: it is always a part of a pattern matching syntactic construct. The premise \\;\;\\\e:\> means that for type-checking the body of a pattern matching branch, we have available not only the pattern variables from >, but also properties > of their types. Another interesting aspect of > is the presence of both universal and existential types. Universal types are as in system F. Rules for existential types: <\equation*> ;\;\\e:\\i|]>\\i:\|\;\;\\|ie|\>:\\:\.\> <\equation*> ;\;\\e:\\:\.\\\\:\;\|}>\e:\|\;\;\\>> |\x|\>=e >> e:\> where > is a sort in the multisorted logic of . The |ie|\>> construct pairs an expression with a witness for the existential type \:\.\>. In fact, the concrete language of DML does not have this construct. Rather, it is introduced by type inference, as discussed below. To facilitate type inference for the concrete language of DML, the system is equipped with two mutually recursive kinds of judgements called : the judgment ;\\e\\\e>>, and the judgment ;\\e\\\e>>. The synthesizing judgments introduce fresh type variables when needed, which are solved from the constraints >. The types for lambda expressions and recursive definition expressions are not synthesized. To see the interaction between synthesizing and checking judgments, consider the rule for function application: <\equation*> ;\\e\\\\\e>\;\\e\\\e>|\;\\e*e\\\e>*e>> Since > is synthesized as part of the function type by ;\\e\\\\\e>, subsequently it only needs to be checked for the argument >. Synthesis for variables is done by referring to the environment, and for data constructors by referring to the respective datatype definition. Checking for variables and data constructors refers back to synthesis, and we employ constraint solving to decide whether the types agree: <\equation*> ;\\x\\\e>\\\>\|\;\\x\\\e>> With existential types, the situation is further complicated by the need to introduce, during elaboration, ``witnesses'' into expressions of existential type. DML relies on a judgment , whose one of most interesting rules is: <\equation*> \coerce,\\i|]>|)>\E\\i:\|\\coerce,\:\|)>.\|)>\|iE|\>> where we see existential witness introduced when an existential type is encountered. The judgment is connected to synthesizing judgments via checking rules. Let us look at the other rule for function application: <\equation*> ;\\e*e\\\e>\\coerce,\|)>\E|\;\\e*e\\\E>|]>> where is an expression context with a single hole. The work on > is foundational to . While we chose to build on the more elegant formalism of >, we share some of the goals of DML, diverging on one: <\enumerate> The formalism behind is parametrized by the domain of constraints, just as >. The implementation handles linear arithmetic constraints, and can be extended to other domains, similarly to DML. Both DML and place emphasis on the seamless use of existential types, aided by type inference. However, existential types are not synthesized by DML. DML and share concern with covering a sufficient portion of ML-family language features, in particular pattern matching with deep patterns. DML requires type annotations on all functions that cannot be typed in the Hindley-Milner type system. In exchange, > has the principal type property and type inference in DML is efficient. takes the opposite stance, not requiring any type annotations. Unlike DML, does not currently support first-class universal types, i.e. function arguments which can be used polymorphically, with different types within a function. Introducing inferred universal types to is left as future work. The type inference for universal types of function arguments would work similarly to how type inference for recursive definitions (which admits polymorphic recursion) works currently. DML performs A-transformation, which is a source level transformation introducing >>> bindings for subexpressions. In this way, all occurrences of expressions with existential types are unpacked, with the existential type eliminated. In interests of type inference times, does not perform A-transformation. However, passing expressions of an existential type as arguments to functions is prohibited in 's type system, therefore A-transformation would be a conservative extension. This captures errors where the programmer forgets to unpack the existential type, without limiting expressivity. In , introductions of existential types need to be marked in the source by adding a single character to the corresponding concrete syntax keywords: , and . In DML, existential type introductions do not figure in the concrete syntax, but existential types need to be spelled out in type annotations. In , inference of existential types will find out how many existential parameters are needed, including the case when none are needed, i.e. the type is not in fact existential. Therefore, a more sophisticated approach might introduce existential types automatically, at cost of increased type inference times. > Formalization> In parallel to the development of DML, Martin Odersky, Martin Sulzmann and Martin Wehr in developed a general framework > for expressing type systems extending the Hindley-Milner type system and parameterized by a constraint domain. Hongwei Xi and collaborators further developed the ideas behind DML into an extension of type systems for languages in the ML family -- Standard ML, Haskell, OCaml -- they originally called , see , later to become known as or GADTs. GADTs were independently investigated at that time by James Cheney and Ralf Hinze as in , and by Tim Sheard as in . Vincent Simonet and Franēois Pottier in brought these two lines of research, > and GADTs, together, by designing an elegant type system >. While the of Christoph Zenger and dependent types of DML refine ML but do not make more ML programs typeable, GADTs extend ML, i.e. make some programs typeable -- provided appropriate datatype definitions -- that would not type-check otherwise. We present the call-by-value >-calculus behind > since we will defer the semantics of to >. The rest of this section follows closely , starting with pages 12-14.<\float|float|t> <\big-table> <\math> p\x\|0\|1\|p\p\|p\p\|K > c\p.e e\x\|K >\|>> x=e >> e\|e e\|\>|)>\|\ x.v v\K >\|\>|)> >> Let and range over disjoint denumerable sets of variables and data constructors, respectively. For every data constructor , we assume a fixed nonnegative arity. The syntax of patterns, expressions, clauses, and values is given in Figure . Patterns include the empty pattern , the wildcard pattern , variables, conjunction and disjunction patterns, and data constructor applications. Defined program variables > are the unique variables in . The pattern is considered ill-formed for nonlinear patterns (i.e. patterns with repeating variables). Expressions include variables, functions, data constructor or function applications, recursive definitions, and local variable definitions. Functions are defined by cases: a >-abstraction, written ,\,c|)>>, consists of a sequence of clauses. A clause is made up of a pattern and an expression and is written ; the variables in > are bound within . We occasionally use to stand for a clause or an expression. Values include functions and applications of a data constructor to values. Within patterns, expressions, and values, all applications of a data constructor must respect its arity: data constructors cannot be partially applied.<\float|float|t> <\big-table> <\eqnarray*> v|]>>||>>|v|]>>||>>|\p\v|]>>||\v|]>\\v|]>>>|\p\v|]>>||\v|]>\\v|]>>>|\p\K v\v|]>>||\v|]>\\\\v|]>>>>> >> Whether a pattern matches a value is defined by an extended substitution v|]>> that is either undefined, which means that does not match , or a mapping of > to values, which means that does match and describes how its variables become bound. Of course, when is a variable , the extended substitution v|]>> coincides with the ordinary substitution v|]>>, which justifies our abuse of notation. Extended substitution for other pattern forms is defined in Figure . Let us briefly review the definition. The pattern matches no value, so v|]>> is always undefined. Conversely, the pattern matches every value, but binds no variables, so v|]>> is the empty substitution. In the case of conjunction patterns, > stands for (disjoint) set-theoretic union, so that the bindings produced by \p> are the union of those independently produced by > and >. The operator > is strict\Vthat is, its result is undefined if either of its operands is undefined\Vwhich means that a conjunction pattern matches a value if and only if both of its members do. In the case of disjunction patterns, > stands for a nonstrict, angelic choice operator with left bias: when > and > are two possibly undefined mathematical objects that belong to the same space when defined, \o> stands for > if it is defined and for > otherwise. As a result, a disjunction pattern matches a value if and only if either of its members does. The set of bindings thus produced is that produced by >, if defined, otherwise that produced by >. Last, the pattern \p> matches values of the form \v> only; it matches such a value if and only if > matches > for every ,n|}>>.<\float|float|t> <\big-table> <\eqnarray*> .e\p.e|)> v>|>|e\v|]>>>| x.v>|>|\ x.v|]>>>|>> x=v >> e>|>|v|]>>>|>|>||]>e\e>>|||>||>|> >\| e\|v \|>> x= >> e>>>> >> The call-by-value small-step semantics, written >, is defined by the rules of Figure . It is standard. The first rule governs function application and pattern-matching: .e\p.e|)>> reduces to \v|]>>, where is the least element of ,n|}>> such that > matches . Note that this expression is stuck (does not reduce) when no such exists. The last rule lifts reduction to arbitrary evaluation contexts. > Type System> > supports subtyping. The language of constraints is as follows: <\eqnarray*> >|>|\|\\\\|\,\,\|)>>>|>|>|\|\>>||>| |\>\|C\C\|C\C\|\\.C\|\\.C\|C\C>>>> where > are types, > are constraint relations and > is a subtyping relation, are constraint formulas. Environments > assign variables to type schemes, e.g. \|}>>, where type schemes are triples: <\equation*> \\\|\>.\ indicating a value of type > polymorphic wrt. variables |\>>, constrained by formula . A novel concept is that of an , a triple: <\equation*> \\\|\>\ where > is a which assigns variables to types (not type schemes). Environment fragments are used to describe the static knowledge that is gained by successfully matching a value against a pattern. We write |\>\> for |\>|\>D|]>\>, and \\> for: <\equation*> \|\>|\>\D|]>\\|)> Structures in which types can be interpreted have to meet three requirements, see pages 18-19, of which we give two. Every constraint of the form \\\\|\>|)>> or |\>|)>\\\\> or |\>|)>\\|\>|)>> for \\>, is unsatisfiable. \\\\\\> entails \\\\\\>. Judgments about expressions retain the same form as in >: they are written \\e:\>, where represents an assumption about the judgment's free type variables, > assigns type schemes to variables, and > is the type scheme assigned to . Judgments about patterns are written p:\\\|\>\>, where the domain of > is >. Such a judgment can be read: under assumption , it is legal to match a value of type > against ; furthermore, if successful, this test guarantees that there exist types |\>> that satisfy such that > is a valid description of the values that the variables in > receive. carries the information unpacked from guarded data constructors : <\equation*> iC\D\p:\\\K\\|\>|\>.\\\\\\\|\>|)>|\>#FV|C\K p\p:\|\>|)>\\|\>\\\\|)>> Subsequently, the unpacked information is available when type-checking the expression in the corresponding branch: <\equation> p:\\\|\>\C\D,\\\e:\|\>#FV,\|)>|C,\\p.e:\\\> The type judgments involving clauses are used to derive types of >-abstractions, i.e. anonymous functions defined by cases: <\equation*> iC,\\c:\|C,\\\\c|)>:\> where > is always of the form \\>. Let us look at a selection of remaining rules. Patterns in a disjunction need to agree on the information they bring about: <\equation*> iC\p:\\\|C\p\p:\\\> However, we can make them agree by discarding irrelevant information: <\equation*> p:\\\C\\\\|C\p:\\\> where \\\> is defined in terms of interpreting environment fragments as sets of ground environments. Fortunately, we can equivalently define \\\> as D\\|\>.D\\\\>, where \\> is a shorthand for |)>=Dom|)>\Dom|)>>\\\> and =\|\>\>, =\|\>|]>\>. Note that D> is defined as C\D>, i.e. holding in the model, rather than C\D>, i.e. provability. To construct a value of a GADT, we need to check that the guard, or invariant, holds: <\equation*> iC,\\e:\K\\|\>|\>.\\\\\|\>|)>C\D|C,\\K e\e:\|\>|)>> The use of a variable is type-checked in the same manner, the variable is looked up in the environment >. The following rule can be derived in > and is a bit more clear than the original: <\equation> =\|\>.\C\\|\>.D|C,\\x:\> The rule for recursive definition is initially given in the Milner-Mycroft style to simplify proofs related to semantics rather than type inference: <\equation*> \|}>\v:\|C,\\\ x.v:\> A instead of an is used to prevent diverging definitions. The final form of >, as employed in proofs of equivalence with the constraint derivation-based presentation, enforces the type annotation: \\|\ |\>.\|)>.v>, where |)>\|\>>. A closed (i.e. without unbound variables) expression is if and only if \e:\> holds for some satisfiable constraint . We have the following type soundness results: <\theorem> \e:\> and e> imply \e:\>. <\theorem> If is well-typed and contains exhaustive case analyses only, then it is either reducible or a value. <\theorem> If is well-typed and contains exhaustive case analyses only, then it does not reduce to a stuck expression. The type inference for >, as well as for , starts by generating a constraint for an expression, whose satisfiability determines whether the expression is well-typed. The rules, or equations, for deriving the constraints form an alternative specification of the type system. Both specifications are readable, the specification by constraint derivation is actually more concise. As with the type system rules, we have constraint derivation equations for patterns, expressions, and pattern matching clauses. The constraint |p\\|\>> asserts that it is legal to match a value of type > against , while the environment fragment |p\\|\>> represents knowledge about the bindings that arise when such a test succeeds. (Note that our use of > and > has nothing to do with bidirectional type inference.) The rules for |p\\|\>> and |p\\|\>> are the same in as in >. They are described in on pages 32-33.<\float|float|t> <\big-table> <\eqnarray*> |\\x:\|\>>||\\>>|||>||\\\>:\|\>>||\\.\|\\c:\\\|\>\\\\\\>>|||>||\\e e:\|\>>||\.|\\e:\\\|\>\|e:\|\>>>|||>||K e\e:\|\>>|||\>|\>.\|\\e:\|\>\D\\|\>|)>\\>>|||K\\|\>|\>.\\\\\\\|\>|)>>>|||>||\\\|\>.\|)>.e:\|\>>|||\>.|\\|}>\e:\|\>\\\\>>|||>||\\e:\|\>.\|\>>|||\>.C\|\\e:\|\>>>|||>||>> x=e >> e:\|\>>|||\\\.\|}>\e:\|\>\\\.C>>|||C|\\e:\|\>>>|||>||\\p.e:\\\|\>>|||p\\|\>\\|\>.D\|\\\e:\|\>>>|||\|\>\|p\\|\>>>>> >: expressions and clauses> We provide the > constraint derivation rules for expressions and clauses in full in Table , because they are analogous to those in , but more concise. The novelty of > compared to > resides in the last rule, which deals with clauses. The following description comes from page 35. First, the function's domain type is required to match the pattern's type, via the constraint |p\\|\>>. Then, the clause's right-hand side is required to have type > under a context extended with new abstract types |\>> and a new typing hypothesis and under an extended environment >, all three of which are obtained by evaluating |p\\|\>>. The specification of the type system in terms of constraints can be seen as even more declarative than the specification by natural deduction rules. Instead of requiring that the reader builds understanding by analysing the possible derivations, the constraint derivation rules reduce the meaning of type judgments to that of formulas, whose semantics is already known. There are three major differences between > and . To simplify the already daunting task, does not support subtyping. Recursive definitions do not carry type annotations -- we perform type inference for polymorphic recursion. The third difference is the requirement in that the guards, or invariants, in type schemes and in value constructor definitions are existentially quantified conjunctions of atoms rather than arbitrary formulas. This is necessary to limit the space of candidate solutions to predicate variables in the task of synthesizing types and invariants of recursive definitions. But the restriction is also motivated by the need that the invariants be readily understandable to the programmer. Logically complex formulas, especially involving implications, are likely to not be sufficiently self-explanatory. As a consequence of restricting type scheme invariants to conjunctive formulas, we cannot use the approach from Table to let-polymorphism. Instead, we perform ``division of labor'': we have monomorphic bindings with a pattern on the left-hand-side >> p=e >> e>, and polymorphic bindings, possibly recursive >> x=e >> e>. > System> The design of the Schrijvers, Peyton Jones, SulzmannVytiniotis > type system is a follow-up to the algorithm from in a broader context parameterized by a constraint logic. The type judgments in > are similar to >. \e:\> means that in a context where the constraint is available, and in type environment >, the term has type >. The important difference is that is a conjunction of atoms rather than an arbitrary formula. Therefore, we cannot formulate an alternative, constraint derivation based specification of the type system, with the elegant connection expressed by results like Theorem . Another difference between > and > is that > is defined against a background of a proof system for checking satisfiability of formulas rather than against an abstract model. The relevance is that having a model gives more flexibility for the implementer of type inference, while having a proof system (i.e. a logic) gives more flexibility for the designer of the type system. The third, related difference is that > uses quantifiers sparingly. Instead, it introduces a distinction into type variables and type variables. > has rules for type checking programs as well as single expressions. Notably, the rule for un-annotated bindings makes use of abduction: <\equation*> ,\\e:\|\>=FV|)>\\C\C\,\\|\>.\|}>\prog|\,\\f=e,prog> We determine the constraint > which is required to make e typeable with type > in >. Next, we allow the invariant of be a simplified version of >, namely . Intuitively, is the \Pextra information\Q, not deducible from >, that is needed to show the required constraint > (see page 15). In our terms, is an answer to an abduction problem \C>. Constraint generation in > is similar to that in >, but the formulation is less concise, and the generated constraint does not have alternating quantifiers. In our opinion, it makes the semantics of the constraints less clear. The constraints are also more restrictive than if quantifier scope was used to determine which solutions are consistent, even for programs without type families or GADTs. page 20 defines a , which is equivalent to our notion of an answer to a simple abduction problem, and a , which is equivalent to our notion of a fully maximal answer to a simple abduction problem. Type inference in > uses a solver of simple abduction problems, but the abduction answers are not allowed to participate in the inferred types. Instead, for type inference to succeed, the abduction answers to implications have to be limited to substitutions of local variables, which are subsequently ignored. To make the exposition more concrete, we rewrite the solver infrastructure specification from page 41. Let ,C> be conjunctions of atoms. Let Abd>,C|)>> mean that is an answer to the simple abduction problem \C> under theory >, i.e. \D\A\C>. Let Simple\Implic> be a decomposition of a constraint into a conjunction of atoms > and a conjunction of existentially quantified implications >. For a substitution |\>\|\>|]>=\\,\,\\\|]>>, let >=|\>>|\>=\>\\\\\>\>. We define the solver recursively: <\equation*> \>\Abd>,Simple|)>Dom\|\>>>||\>.D\C\Implic|)>.Solve;C\C\D;|\>;C|)>\,R|)>>>>>>|Solve;C;|\>;C|)>\,R|)>> While it appears that the type inference solution is built out of abduction answers ,R|)>>, the interesting simple abduction problems \C> are required to have abduction answer (|\>>) limited to variables |\>>, which can be subsequently ignored. Motivated by considerations of efficiency and avoiding ambiguity, restricts the abduction algorithms to those only searching for fully maximal answers. conjectures that the algorithm they provide is complete wrt. fully maximal answers to simple abduction problems. > might not be able to use the abduction algorithm complete wrt. fully maximal answers to simple abduction problems from , even when limited to GADTs, because the > type system is based on a logic instead of on fixed models like Herbrand structures. The > project exposition lists multiple challenges as being in its focus. Of these, addresses GADTs, and is open to address , although the corresponding sort has not been implemented. The other challenges fall outside of the scope of : type-class constraints, multi-parameter type classes with functional dependencies, and type families with type family axioms. Some of these type system features, when implemented directly, violate the requirement on the interpretation of types that we preserve from >: ``Every constraint of the form \\\\|\>|)>> or |\>|)>\\\\> or |\>|)>\\|\>|)>> for \\>, is unsatisfiable.'' (In , we have equality >> instead of subtyping >.) argues strongly against selecting an arbitrary correct type when a definition does not have a most general type. does select an arbitrary type without guarantees, although the implementation is designed to pick useful types; e.g. if possible, with the return type of a function sharing a parameter with an argument type. is intended to provide type signatures for toplevel definitions to the programmer. The programmer would then either accept the signature, modify the program and re-generate the signature, or modify the signature directly. > shares with the restriction of type scheme invariants, and guards of data constructors, to conjunctions of atoms. On other points of difference between > and >, follows >. Both > and infer types for toplevel definitions one at a time. Finally, the type inference algorithm of > is much weaker than that of , as illustrated in our presentation of the central step of the algorithm in terms of abduction. While our algorithm uses abduction to search for the solution of the type inference problem, > only uses abduction to verify a partial solution found by unification. Chuan-kai Lin in , see also LinSheard , presents a type inference algorithm for GADTs. Just as , the type system Pointwise GADTs and the algorithm > from does not require type annotations. The Pointwise GADTs is not a constraint-based type system. Also, it does not support deep patterns. Let us look at the two most important type system rules. The recursive definition rule captures polymorphic recursion: <\equation*> \|\>.\|}>\e:\>||\>#FV|)>>|\|}>\e:\>>>>>|\\>> x=e >> e:\> The rule for pattern matching expressions is straightforward, nearly the same as the corresponding derived rule in >. We turn to the pattern matching branch rule: <\equation*> \|\>.>\\ >>|||\>#FV,>,\|)>>>|\ >>\ >|)>>||>\>|}>|)>\e:S|)>>>>>>|\\K >.e:\ >\\> \> stands for . It is a limited form of unification. If \>t|)>>, then =U>, but also: for \Dom>, if =\>, i.e. has variable > at position , then =U|)>>; similarly, if =\>, then =U|)>>. The type inference algorithm > is deliberately more restrictive than the type system Pointwise GADTs. In particular, it uses to infer a tight type for the pattern-matched expression, so that the pattern matching has a better chance of being exhaustive given the type. Algorithm > is based on Robin Milner's algorithm > as in , and its modification by Alan Mycroft to handle polymorphic recursion as in . See pages 152-184 for detailed presentation. We reproduce details of the algorithm >, because \ algorithm > provides a base-line wrt. which type inference for GADTs not relying on type annotations can be compared. We defer the reader who finds the current section cryptic to Chuan-kai Lin . It might be worthwhile to collect the major pieces of algorithm > together: <\eqnarray*> ,e e|)>>||>|,\|)>>||,e|)>>>|,\|)>>||,e|)>>>|>||>\\\|)>\>>|||,S,S|)>>>||||)>|)>>>|||>|,>> x=e|)>>||,\\.\|)>>>|,\|)>>||>|,\|)>>||\|}>,e|)>>>||\>>|||)>\\FV\|}>|)>>>|>|||\>.\>>|>|||)>=\>>|>|| S,\|)>>>|>|| S,\|)>>>|||>|, e .e|\>|)>>||>|,u|)>>||,e|)>>>|,u,\|)>>||,\,p.e|)>\>>|||,\,\|)>>>|||,u|)>>,u,\,u|)>|)>>>|||>>|>||,S,\>\|)>|)>>>||\>>||\Dom|)>|)>>>||\>>||\\|\>>>||||\>,|\>|)>>>|||FV|)>,|\>|)>>>||||\>,trt,btt|)>>>||||)>|)>>>|||>|,\,K >.e|)>>||>||\>.>\\ >>|||\>>>||)>>||r|\>|}>,e|)>>>||\>>|||\>\\FV|)>\FV|)>|)>>>||\>>||\\|\>\retain|\>,S,\|)>|}>>>|>|||\>\FV>|)>>>|>||>>|>|||\>=\>>|>||\\|]> S,\ |\>,\ >|)>|\>>>|>||\\|]> S,S|\>,\ >|)>|)>,\ >|)>>>|||>||\>,S,\|)>>||>||)>=\ >>|>|>>||)>=\>|>|\\|\>.\\\\\\FV|)>|)>>>|||>||\>,\|)>>||>|>|||\>#FV|)>>>|>||\>>|>||>|=\ >>|>| |\>,r|)>|\>>>|=\>|>|>>>> The operation > is a combination of substitutions having the effect of unification of the corresponding equations: <\equation*> \,\,S|)>=\>|)>=\|\>,\,|\>|)>>|\>|)>,\,S|\>|)>|)>|)>|\>=Dom|)> \ The algorithm is designed after algorithm >. However, it is made more modular by the use of >. This can be seen as a ``concealed'' form of constraint derivation based type inference, where the partial constraints are solved during collection. The case ,>> x=e|)>> is the Mycroft's modification of algorithm > to handle polymorphic recursion. It introduces iteration of type inference, for each recursive definition separately, till the definition's type converges. The ,\,\|)>> subroutine used in , e .e|\>|)>> is , a special case of what we will call . It computes the type for the expression as specific as possible while agreeing with all types imposed by the pattern matching branches. The complications in handling variables in ,\,K >.e|)>>, in particular the failure condition |\>\FV>|)>>, are analogous to the fact that the variables |\>> would be universally quantified by >, and thus cannot be part of, for example, the domain of the resulting substitution. The aspect of algorithm > that is closest to the intricacies of term constraint abduction is the joint use of the and subroutines (not presented above). They decompose respectively the pattern-matched expression type, and the pattern-matching branch body type, when the types start with the same type constructor > across branches. When the types across branches do not agree, but a column corresponding to a subterm of the result type, i.e. branch bodies type, is unifiable (branch-wise) with exactly one column, then the subterm of the result type is replaced by the corresponding subterm of the pattern-matched expression type. Algorithm > is designed to infer types for GADT programs without relying on type annotations. This is the major goal of , alongside inference of existential types and ease of extension with novel sorts. The type system behind algorithm > is not constraint based, and in particular, it has no mechanism for extension with, for example, numerical invariants. The Pointwise GADTs type system is much more restrictive than the plain GADTs type system around which is designed. Algorithm > is very efficient compared to , but still quite capable. Some inspirations for can be drawn from algorithm >. The examples from motivated the extension of simple constraint abduction algorithm for terms in to non-fully-maximal answers. The extension allows guessing equations between invariant parameters. The use of anti-unification in algorithm > is interesting and the prospect of using constraint generalization in to infer a tighter type when otherwise a pattern matching expression would not be exhaustive, is intriguing, but we leave it as future work. Finally, table-based approach to in algorithm >, via the and subroutines, might inspire future work on augmenting the sequential approaches to joint constraint abduction, by ``simultaneous'' stages, operating jointly on all branches. Tim Freeman and Frank Pfenning's predates even the Odersky, Sulzmann and Wehr . Refinement types are so called because they refine the ML type system, rather than extending it as GADTs do -- they do not make new programs typeable. Refinement types became the universally and existentially quantified types of DML. More recently, they were independently developed in an inference-friendly way by Cormac Flanagan and Knowles and Flanagan . The work was continued by Ranjit Jhala, Patrick Rondon and collaborators, and their systems and have become more popular. They are fully focused on automatic invariant inference. The work behind (, expanded in and ) is the topic of this section. cites the work on predicate abstraction , as precursory for this kind of invariant inference; and Jeffrey Scott Foster on Type Qualifiers , as inspiring some aspects of inference. Type refinements can be seen as preconditions (or postconditions) when they refine the argument type (or the result type) of a function. The term introduced by comes from ``logically qualified types'', a restriction of an otherwise more depent-types-like type system, limiting type refinements to conjuctions of atoms from a sort of linear inequalities and uninterpreted functions. The refinements are over base (i.e. non-function) types, and are written: :Be|}>>, where is a base type like , is a conjunction of atoms, and > is a singled-out variable constrained by . (In the formalism used by , the letter > will play the role of > here.) Recall the typing judgment form \e:\> we encountered in systems described earlier: assuming constraint holds, in environment >, expression has type >. Although the Liquid Types typing judgment \e:T> (where stands for a liquid type or type scheme) seems simpler, here is a part of >. The assumed constraint is: <\equation*> |\|\>\\\>e\:Be|}>\\>e\x|]> The Liquid Types type system is based on subtyping rather than type equality. Here, subtyping implicitly captures the requirements on the assumed constraint. The subtyping judgment has the form \T\:T>, which means: |\|\>> implies that > is a subtype of >. The function type arguments are indexed by the variable corresponding to the >-abstraction introducing the type: \\x.e:\T|)>>. Together with the following rules: <\equation*> =:Be|}>|\\x::B\>x|}>> <\equation*> \e:S\;x:S\e:T|\\>> x=e >> e> this avoids the use of existential quatification in inference constraints. The crucial rules relevant for invariants are: <\equation*> \e:Bool\;e\e:T\;\e\e:T|\\>> e >> e >> e:T> <\equation*> |\|\>\e\e|)>|\\:Be|}>\::Be|}>> In the first rule, the expressions > are limited to well-formed formulas of the constraint domain. Note how the former rule resembles the > Rule in that the local constraint is enhanced by the information pertaining to the conditional branch. The latter rule resembles the Rule in that the local constraint is used as a premise to ensure the validity of the use of a value. Similarly to >, the system first generates the inference constraint for the whole toplevel expression, and then proceeds to solve the constraint. uses an oracle to solve the Hindley-Milner polymorphic type inference subproblems, and the resulting type shapes guide the construction of the constraint. In this way, the constraint describes purely the subtyping issues, rather than both the typing and subtyping issues. Each subtyping requirement contributes what would be an implication in a normalized constraint. The Liquid Type Inference Algorithm, including constraint generation, can be found in , page 9, Figure 4. Liquid Types inference introduces >, standing for unknown invariants. (In , we call them >.) The inference task is to find a substitution for the liquid type variables such that all the implications corresponding to subtyping constraints are valid. We present the liquid type variable solving part of the inference algorithm: <\eqnarray*> \:B\\\|}>|)> A>||\A|)>\;\:B\\:Bool|}>|]>>>|\:B\|}>\::B\\\|}>|)> A>||\A|)>|A|)>|\>\A|)>\\|}>|]>>>|||>>|||>|\c\CA>||>>|||>>> The pair \\> of a substitution > and liquid type variable > is a , see Knowles and Flanagan . Entry above ensures that the solution formulas are well-formed. Entry filters out the atoms which are not implied by the premise of the implication considered. Entry is the failure case: the offending implication cannot be made valid. It cannot be weakened, as it does not contain a liquid type variable in the conclusion, and the premise is already as strong as possible. The initial call to passes as the initial solution , for each liquid type variable >, a conjunction of atoms over the potential parameters of invariants appearing in constraints. It will be illuminating for Chapter to compare the solver of with that of . In a single iteration of the main algorithm of: , a single invariant (i.e. > substitution) is updated; , all invariants (i.e. > substitutions) are updated. This makes: in , a single implication valid, given before-update substitution of liquid type variables in premises; in , all implications valid, given before-update substitution of ``liquid type'', i.e. predicate variables in conclusions. focuses on the role liquid type variables play in conclusions, and ignores their role in premises, other than to verify validity of implications. focuses on the role all predicate variables play in premises, but also, using a different mechanism, on postcondition predicate variables in conclusions. starts with a full initial solution (a conjuction of all atoms, trivially contradictory); starts with an empty initial solution (an empty conjunction, trivially satisfiable). finds the most specific (least general) solution for all invariants. finds the least specific (most general) solution for preconditions, and the most specific solution for postconditions given these preconditions. Here are three arguments in favor of over . The major limitation of is the need to generate all the atoms as the initial solution; in , the addition of atoms to the solution is driven by the conclusions that need to be explained. Least general preconditions are less useful than most general preconditions. Furthermore, in principle, there can be solutions that are overlooked by solving one invariant at a time. There are two shortcomings of relative to that should inspire future work; we start with the major one. prohibits passing values of an existentially quantified type as arguments, and it does not allow type schemes as argument types. Thus functions like from the example, see Appendix Subsection , require manual packing and unpacking for the argument of the function passed to the higher-order function. manages to infer types for such higher-order functions, and this ability is further improved in Abstract Refinement Types: Vazou, Rondon and Jhala . The other shortcoming is that, while is faster with simple input programs, is faster with more complex programs for which it is able to find a solution. There are two reasons. One is that entirely eliminates variables which cannot be invariant parameters before starting the solution process, i.e. intermediate variables of the Hindley-Milner inference process. deploys the general mechanism of abduction to solve for all variables. The other reason is that only checks all constraints for contradiction once every update of an invariant >. checks all constraints for contradiction for every candidate atom to be added during an update of invariants. We have invoked ``abduction'' multiple times already, it is time to define the term. is a form of inference where we find an explanation of a target formula (often referred to as an observation) given background knowledge. Given a signature > and a set of variables , a is a pair ,\|)>> where > is a >-structure and > (the language of constraints) is a set of >-formulas closed under conjunction and renaming of free variables. is a formalization of abduction in the context of a constraint domain. is the task of solving an implication C>, where \> are conjunctions of atoms. The constraint abduction answer \> is a solution to the implication C> if and only if \B|)>\C> and \\FV.A\B>, where |)>> finds the free variables of an expression. > and play the role of background knowledge -- > general, and context specific. plays the role of observation, and of explanation. If C> is a conjunct in a type inference constraint, then contains the background information about a particular location in a program's source code, coming from the pattern matching patterns that ``are the case'' -- the location is in their scope. contains the requirements imposed by the source at that location, for example the preconditions of the functions that are called. The answer explains what needs to be the case for the requirements to be met. is the task of solving implications \C|)>>, where ,C\\> are conjunctions of atoms and \> stands for \\\\>. The answer \> to this Joint Constraint Abduction problem has to meet the conditions: \B|)>\C> and \\FV|)>.A\B>, for all . The suitability of joint constraint abduction for GADTs type inference was probably first observed by Martin Sulzmann, Tom Schrijvers and Peter J. Stuckey, see (originally ) and . Michael Maher has studied constraint abduction for terms (, ) and linear arithmetic (). Michael Maher and Ge Huang provided the basis for our Simple Constraint Abduction algorithm for terms, which we describe in this section. An abduction answer is , when for every other abduction answer >, if \A\A>, then \A\A>. An abduction answer to C> is , when it is maximally general and \B|)>\C|)>>. A fully maximal answer does not ``guess'' any fact not entailed by the formulas considered.<\float|float|t> <\big-table> > \ \ returns the set of positions of the term in the right-hand-side of >>|> \ replaces all terms in the right-hand-side of occurring at a position>>| by a new variable (that is existentially quantified)>>|> \ \ \ is the set \\S\pos,t\Vars|}>>>>|>| >>>| B\C> >>>| be the standard form of C>>>|>>| > be >>>|A\\.\A\B\C|)>> >>| \> such that A\B\C>>>>>>>>>>>>>|>|>>|\AAi|}>>>>|exist \> and s.t. B> is unsatisfiable in >, \\\\>>>|=\> >>>| exist \\> s.t. \A\A> and A>, \\\\>>>|>>>>>>>>>>> Let =\=T,Vars|)>> be the free algebra of terms over signature > with variables and =\\>> be existentially quantified conjunctions of equations. In Table we quote the fully maximal abduction algorithm from , Figure 4, page 13. The following theorem is Theorem 6 from , page 14. <\theorem> Algorithm outputs all fully maximal answers to the SCA problem over \>> and terminates. Now let us turn to the joint problem. The following proposition is Proposition 8 from , page 9. In Table we quote the corresponding algorithm . <\proposition> Consider a joint constraint abduction problem composed of SCA component problems. Let =AAi|}>>. If is a maximally general answer to the JCA problem then \>. The JCA problem has no answers iff no constraint in > is an answer. Sulzmann, Schrijvers and Stuckey and inspired the approach taken by the project. Maher and Huang forms a basis of our simple constraint abduction solver for the Herbrand domain. It turns out however, that fully maximal answers are insufficient for type and invariant inference. We go beyond the algorithms from Table as follows. We extend the > algorithm by considering atoms >y>, where Vars>, >t> and >t> belong to the solved form of C>, \Vars> and \Vars>, and >t> is satisfiable. These conditions limit the number of pairs of variables to consider. There are many potential SCA problems where we still will not be able to find an answer, but they appear not to be relevant: we have not encountered a practical example where the algorithm would need further extension. We extend the algorithm by using the partial solution, i.e. starting from C\A> instead of C>, when solving the th component SCA problem. We propose a novel algorithm (not based on ) for constraint abduction for the linear arithmetic domain. The main idea of this work is that useful properties of functions can be generated by solving ordinary-looking constraints under a quantifier prefix (without resorting to Herbrandization), derived via a GADTs-based type system. The content of Sections and is based on Simonet and Pottier . To our knowledge, the idea behind the rule is novel. The content of Sections and is novel. We start by introducing notation. By the bar >> we denote a sequence (or a set, depending on context) of elements , by we mean disjointedness. With a free index , |\>> means ,\,e|)>> for some associated with the index ; i.e. |\>> or >> is a sequence ,\,e|)>> and > is an th element of the sequence. Similarly, \> denotes \\\\>. For convenience, we treat a conjunction of atoms c> as a set of atoms ,\,c|}>>. Sometimes we write >> for a sequence of variables related to but distinct from a variable . In some contexts, for a quantifier prefix > we write > to denote the set of variables quantified by >. Let be a generic function returning the free variables of any expression. For a quantifier prefix > and variables in >, by >y> we denote that is to the left of in > and they are separated by a quantifier alternation, by >y> that it is not the case that >x>. By |\>\>|]>>, \t|\>|]>>, or \t;\;\\t|]>>, we denote a substitution of terms >> for corresponding variables |\>> in the formula > (where |\>> and >> are finite sequences of the same length). Equality with a dot >> is an object-level equality, i.e. a relation in the language > introduced below. Equality is a meta-level equality, usually syntactic equality on terms or formulas. By >>>> we denote s>t>, where >=,\,s|)>> and >=,\,t|)>> for some . We use letters to denote substitutions. For a substitution |\>\>|]>>, we write substitution application as |)>=\|\>\>|]>>; we write >=|\>>>>; and we denote the substitution corresponding to a formula >=|\>>>> by >. We say that a substitution |\>\>|]>> agrees with a quantifier prefix >, when \.|\>>>> and in case of >\\|\>>>> for variables ,\>, we have \>\>. Syntactically, this means that > is not to the right of variables in >: \\FV|)>>, \>\>. We use letters ,r,s,t,u> to denote terms and letters ,\,v,x,y,z> to denote variables. We are interested in a multi-sorted first order language > with equality, interpreted in a given, fixed model >. Even when we write \>, it is usually a shortcut notation for validity of a formula > in the model >: \\>. The sort of terms or ``types proper'', denoted > and in the concrete syntax of , plays a special role. In the current presentation, we abstract from details of the language, posing the necessary properties as assumptions.<\float|float|t> <\big-table> <\equation*> ||>|>|\|\\\\|\|\>|)>\|Num|)>>>|>|>|\|k*\\|\+\\|k>>||>|\|1\|-1\|2\|-2\|\>>|>|>|\|\>>|>|>|>\>>|>|>|>\\|\\\>>|||>max,\|)>\|v>min,\|)>>>|||\max,\|)>\|min,\|)>\v>>||>|\|a\|\|)>\|\,\|)>>>||>|\|v=\\|\\|\>>|>|>|v>.>|]>.v\|\>>|]>.\>>>>> In Appendix , we introduce a Henkin semantics for existential second order logic > extending > by predicate symbols |)>> that we call . > is tailored to our needs of invariant and postcondition inference. Let |)>> be the set of predicate variables in any expression. We define to be existentially quantified conjunctions of atoms |\>.A> without predicate variables. An interpretation of predicate variables > substitutes predicate variables by solved form formulas. In Table , we present a particular instance of >, introducing a numerical constraint domain. The terms of > are >, and are the atomic formulas, as currently implemented in . There are two sorts: > with terms > and relations >, and > with terms > and relations >. Variables of distinct sorts are disjoint; > stands for variables of sort . The remaining entry > is built on top of > rather than part of it. The notation > stands for the same variable of sort > in both occurrences. Besides >, we also use the letter for terms of >. Rarely, in interests of readability we use the letters besides ,\> to denote variables of >. By > we mean terms of sort >. Define > as \.\>, where is either a solved form formula |\>.E> or a predicate variable |)>>, and > is a variable of sort >. A (or ) maps variables to types >. An (or ) maps variables to type schemes >. When a simple environment is appended to an environment, we identify > and \>\|]>.\> for \FV|)>>. When operations pertaining to formulas are applied to a type scheme \|\>.E|]>.\> or \|)>|]>.\>, they are performed on the formula |\>.E> or |)>>. \|\>>\\E|]>.\> is a notational variant of \|\>.E|]>.\>. When operations pertaining to type schemes (types) are applied to (simple) environments >, they are performed on the image of >. Define > to be triples |\>.\> of variables |\>>, atomic conjunctions in > and simple environment >. Table presents expressions currently in , more domain-specific > and > clauses can be added. The table defines several expression languages, underlying the corresponding type systems: >, its supersets -- in terms of expressions and system rules -- > and >>, and >> which is a union of > and >>. The domain-independent languages > and >> are extended with some expressions specific to the numerical sort in > and >>. The language > and model > for > and >> are arbitrary. We fix the language > for > and >> as having besides > only a linear arithmetic sort. We discuss the type system > shortly, and extend it to >> in Section . Disjunctive patterns are not yet implemented in , we omit them in the presentation for brevity.<\float|float|t> <\big-table> <\math> p\x\|0\|1\|p\p\|K > c\ MMG: p.e MMG: \|p >> e|\>.e e\ MMG: x\|K >\|>> p=e >> e\|e e\|\>|)>\|>> x=e >> e \|>> \|>> e=e;e \|>> e MMG: \|>> e\e;e MMG>: \|\> \|\> First, we present the type system in the standard, natural deduction style. The \e:\> or \e:\> is composed of a formula without predicate variables, an environment >, an expression and a type > or type scheme >. Not mentioned explicitly is a set of data constructors >, which is fixed when typing an expression.<\float|float|t> <\big-table> Syntax-directed: ||>|>|>>|0:\\\\|]>>>|1:\\\\|]>> \ \ \ \ \ >|x:\\\\|]>\|}>>>>|||>|>||>>|i>|D\p:\\\>|\|\>|\>.\\\\\\\|\>|)>>||\>#FV>>>>>|C\K p\p:\|\>|)>\\|\>\\\\|)>>>>>||iC\p:\\\|C\p\p:\\\\\>>>>>>>> \; \; Non-syntax-directed: ||>||>||>>|p:\\\>>|\>\>>>>>|C\p:\\\>>>>||p:\\\>>|\\\>>>>>|C\p:\\\>>>>||p:\\\>>||\>#FV,\|)>>>>>>|\|\>.C\p:\\\>>>>>>>> >> <\float|float|t> <\big-table> Syntax-directed: |||||||||>||>>|=\\|\>.D|]>.\>|D>>>>>|C,\\x:\>>>>||i C,\\e:\C\D>>|\|\>|\>.\\\\\|\>|)>>>>>>|C,\\K e\e:\|\>|)>>>>>>|||>|>||>>|\e:\\\>>|\e:\>>>>>|C,\\e e:\>>>>||i C,\\c:\\\|C,\\\\c|)>:\\\>>>>>|||>|>||>>|\\|)> e:\|C,\\>> p=e >> e:\>>>>||\e:\>|\e:\>>|=\\|\>.D|]>.\>|=\\|}>>>>>>|C,\\>> x=e >> e:\>>>>>|||>|>||>>||\e:Num|)>>||\\\>>|\e:Num|)>>||\e:\>>>>>|C,\\>> e\e;e:\>>>>|||\e:\>||\>\>>|\e:\>||\e:\>>>>>|C,\\>> e=e;e:\>>>>>|||>|>||>>||\>>>>>|C,\\>>:\>>>>||\s:String|C,\\>> s:\>>>>>>>> \; \; Non-syntax-directed: |||>||>||>||>>|D,\\e:\>>||\>#FV,C|)>>>>>>|C\\\|\>.D,\\e:\\|\>.D|]>.\>>>>||\e:\|\>.\>>|D|\>\|\>|]>>>>>>|C,\\e:\|\>\|\>|]>>>>>||\e:\>>||\>#FV,\|)>>>>>>|\|\>.C,\\e:\>>>>||\e:\>>|\>\>>>>>|C,\\e:\>>>>>|||||||>|>||>||||>|\e:\>||\e:\>>>>>|C\D,\\e:\>>>>||,\\e:\>>>>||||>>>> >: expressions> If alternative sets of constructors are considered, we make them explicit by writing ,\\e:\>. By > we denote substitutions of predicate variables >. By interpretations we mean substitutions leading to ground formulas, which have truth value in the model. The intended meaning of the type judgment ,\\e:\> is: for every interpretation ,R>, if ,R\C>, then the expression has a ground type |)>> in a ground environment |)>|)>>; and with constructors |)>> but this only becomes relevant starting from Section . We define derivability of type judgments in Tables and , where we use pattern-related derivations from Table . For example, the rule : =\\|\>.D|]>.\>|D>>>>>|C,\\x:\>> means that we can derive a type > for , with properties , if the properties of > are implied by the judgement constraint . And the standard rule : \e:\\\C,\\e:\|C,\\e e:\>> means that a type for an application e> can be derived if a function type can be derived for > and the corresponding argument type can be derived for >. The type is a datatype; we denote datatypes in general by the label >.<\float|float|t> <\big-table> Clauses ||>|>|D,\\\m:Num>|)>>|\e\>>\\\>>|D,\\\n:Num>|)>>|\\\.>>|)>|)>>>|p:\\\|\>\|\>#FV,\|)>>|D\\>\\>,\\\e:\>>>>>|C,\\p >> \m\n.e:\\\>>>>|>||>|>|>|D,\\\m:Num>|)>>|>>\\\>>|D,\\\n:Num>|)>>|\\.>>|)>|)>>>|p:\\\|\>\|\>#FV,\|)>>|D\\>\\\>\\>,\\\e:\>>>>>|C,\\p >> \m\n.e:\\\>>>>|>||>|>|>|D,\\\m:Num>|)>>|p:\\\|\>\|\>#FV|)>>>|D,\\\n:Num>|)>>|D\\>\\\>\\>,\\\s:String>>>>>|C,\\p >> \m\n.>> s:\\\>>>>|>>>> >: clauses> Top-level definitions introduce new entries into a global value constructor environment > or a global variable environment >. Here we present the most interesting case of a recursive definition with a test clause. The type information flow from the test > to the definition > is through the shared type scheme > in >. Other cases are analogous. In particular, toplevel definitions, unlike > expressions, are polymorphic, and, like > expressions, allow binding to a pattern. <\equation*> \e:\>|\e:Bool>|>|=\\|\>.D|]>.\>|=\\|}>>|\C>>>>>|C,\\>> x=e >> e\\> A for a > (recall that the sort > holds two categories of elements: datatypes and function types) has definition \|\>|\>.\\\\\\\|\>|)>> where ,\,\|)>\|\>|\>>. is a conjunction of atoms. At this point the construction is a syntactic sugar for single branch patterns -- if polymorphic is needed, use . We identify clauses of > with >> .e> where the type system rules are like the rules for >> \m\n>, only with the subformula \>\\>> removed (i.e. replaced by >). Note that and are unrelated to Constraint Generalization we introduce in the next chapter. Most of the rules in Tables and are close to > rules well described in Simonet and Pottier . A salient difference is the rule for clauses whose right-hand-side is an expression. Rather than unifying the type of the function argument with the type of the pattern, we want the discrepancy between these types be a possible reason of unreachability of the pattern matching clause. Without the distinct treatment of clauses with as right-hand-side, the -based variant of the example would fail. The notation using > in the rules and represents a check whether an expression is a cascade of function abstractions with a single case (i.e. a single pattern matching branch), the last function abstraction having a function body . The similar rule is an ``escape hatch'' for cases which cannot be ruled out by the type system. An expression is given ,\> when ,\|)>=\> and ,\\e:\> holds for some satisfiable constraint . For simplicity, only admits type and invariant annotations from the user on toplevel definitions. In Tables , and , we present type judgments declaratively by reducing them to constraints. The presentation is a little bit heavy due to explicit capture-avoidance conditions. For example, |\\x:\|\>=\\|\>.D|\>\\|\>|]>\\>\\=\\|\>.D|]>.\,\|\>#FV,\|)>> introduces a constraint over the type > required by the properties of stored in the environment >. The constraint |\\e e:\|\>=\\.|\\e:\\\|\>\|\\e:\|\>,\#FV,\|)>> for typing the result of application of > to >, imposes a function type on >, and a type on > -- represented by the fresh variable > -- that matches the argument type of >. The constraint for a pattern matching clause without the guard becomes more readable: |\\p.e:\\\|\>=|\p\\|\>\\|\>.D\|\\\e:\|\>> where |\>\=|\p\\|\>>. The premise derived from the pattern provides context-specific information for typing the expression .\ The two presentations are equivalent, in the sense of the and theorems. The proofs are in Section . <\theorem> (expressions). For all environments >, expressions and types >, |\\e:\|\>,\\e:\> is derivable. <\theorem> (expressions). Let > be a first order language with equality >> and a model >. Let > be an extension of > with predicate variables |)>>. Let > be an environment, a formula in >, an expression and > a type. If |)>=\> and \e:\> is derivable, then there exists an interpretation of predicate variables > such that ,\\C\|\\e:\|\>>. In Theorem , we explicitly introduce all symbols used. We often state propositions and theorems in a more compact manner, with symbols introduced implicitly. <\corollary> If \e:\|\>.\> and |\>#FV|)>>, then there is an interpretation > such that ,\\C\|\>.D\|\\e:\|\>|)>>. <\float|float|t> <\big-table> Constraint generation: <\eqnarray*> |\0\\||\>|\>>||>>|||>||\1\\||\>|\>>||>>|||>||\x\\||\>|\>>||>>|||>||\p\p\\||\>|\>>|||\p\\|\|\p\\||\>|\>|\>|\>>>|||>||\K p\p\\||\>|\>>|||\>.\|\>|)>>\\\|\>.D|\>|\>\|\>|\>|]>\\|p\\|\>|\>\|\>|\>|]>||\>|\>>>|||>|||K\\|\>|\>.\\\\\\\|\>|)>,|\>|\>#FV,\|)>>>>> Environment fragment generation: <\eqnarray*> |\0\\||\>|\>>||\|]>>>|||>||\1\\||\>|\>>||\|]>>>|||>||\x\\||\>|\>>||\|]>\|}>>>|||>||\p\p\\||\>|\>>|||\p\\|\|\p\\||\>|\>|\>|\>>>|||>||\K p\p\\||\>|\>>|||\>|\>|\>|)>>\\D|\>|\>\|\>|\>|]>|]>(\|p\\|\>|\>\|\>|\>|]>||)>|\>>>|||>|||K\\|\>|\>.\\\\\\\|\>|)>,|\>|\>#FV,\|)>>>>> <\float|float|t> <\big-table> <\eqnarray*> |\\x:\|\>>||x\Dom|)>>>|||>||\\x:\|\>>||\|\>.D|\>\\|\>|]>\\>\\=\\|\>.D|]>.\,\|\>#FV,\|)>>>|||>||\\>>:\|\>>||>>|||>||\\>> s:\|\>>|||\\s:String|\>>>|||>||\\>> e\e;e:\|\>>||\\.|\\e:Num|)>|\>\|\\e:Num|)>|\>\\\\\|\\e:\|\>,\\#FV,\|)>>>|||>||\\>> e=e;e:\|\>>||\\.|\\e:\|\>\|\\e:\|\>\\>\\|\\e:\|\>,\\#FV,\|)>>>|||>||\\\>:\|\>>||\\.|\\>:\\\|\>\\\\>\,\\#FV,\|)>>>|||>||\\e e:\|\>>||\.|\\e:\\\|\>\|\\e:\|\>,\#FV,\|)>>>|||>||\\K e\e:\|\>>|||\>|\>.(\|\\e:\|\>|\>\|\>|\>|]>|\>\D|\>|\>\|\>|\>|]>\\|\>|)>>\)>>|||\\K\\|\>|\>.\\\\\\\|\>|)>,|\>|\>#FV,\|)>>>|||>||\\>> x=e>> e:\|\>>||\|)>\|\\\|)>|]>.\|}>\e:\|\>|)>|)>\\.\|)>|)>\|\\\|)>|]>.\|}>\e:\|\>>>|||\#FV,\|)>,\#PV|)>>>|||>||\\|\>:\\\|\>>|||\\c:\\\|\>>>|||>||\\e:\|\>.\|\>>|||\>.D|\>\|\>|]>\|\\e:\|\>\|\>|]>|\>,|\>#FV|)>>>>> <\float|float|t> <\big-table> <\eqnarray*> |\\p >> \m\n.e:\\\|\>>|||\p\\|\>\\|\>.\\|\>.D\\|\\\m:Num|)>|\>\|\\\n:Num|)>|\>>>|e\\>||\\\\\|\\\e:\|\>|)>>>|>>\\\>||>|\\\.>>|)>|)>>||>|||\|\>\|\p\\|\>,|\>\|\>#FV,\,\|)>>>|||>||\\p >> \m\n.e:\\\|\>>||\.|\p\\|\>\\|\>.\\|\>.D\\|\\\m:Num|)>|\>\|\\\n:Num|)>|\>>>|e=>>\\\>||\>\\\\\\|\\\e:\|\>|)>>>|\\.>>|)>|)>>||>|||\|\>\|\p\\|\>,|\>\\|\>#FV,\,\|)>>>|||>||\\p >> \m\n.e:\\\|\>>||\.|\p\\|\>\\|\>.\\|\>.D\\|\\\m:Num|)>|\>\|\\\n:Num|)>|\>>>|e=>> s>||\>\\\\\\|\\\s:String|\>|)>>>|||\|\>\|\p\\|\>,|\>\\|\>#FV,\,\|)>>>>> <\float|float|t> |||||||||||>||>>|>|)>>||>>| e|)>>|||)>>>|\e|)>>||>>|>> x=e >> e|)>>|||)>>>|.e|\>|)>>||>>|>> p=e >> e|)>>||>>|>> e\e;e|)>>|||)>>>|>> e=e;e|)>>|||)>>>|>> s|)>>||>>|>>|)>>||>>>>>>|Expressions that directly handle an existential type> <\float|float|t> ||||||||||>||>>|>,v|)>>|||)>|\>>>| e,v|)>>||,v|)>\\,\|)>>>|\e,v|)>>||\,\|)>>>|>> x=e >> e,v|)>>||,\|)>\\,v|)>>>|>> \n|\>.e,v|)>>||\,\|)>\\,\|)>>>|||\>>|>,\|)>>||\|)>|\>>>|>,\|)>>|||)>|\>>>|>> p=e >> e,v|)>>||,\|)>\\,v|)>>>|>> e\e;e,K|)>>||,\|)>\\,\|)>\\,v|)>>>|>> e=e;e,K|)>>||,\|)>\\,\|)>\\,v|)>>>>>>>|Collect introduced value constructors> In Definition , we describe a class of type judgments that is a better target for type inference. First, we introduce a normal form of constraints that simplifies formal considerations. <\proposition> For any ,e,\>, the formula |\\e:\|\>> is equivalent to a prenex-normal, normalized form: there is a quantifier prefix > and pairs of conjunctions of atoms ,C>, such that <\equation*> \\|\\e:\|\>\\.\\C|)> We put |\\e:\|\>|)>=\.\\C|)>>. <\definition> We call the formula |\\e:\|\>> the for environment >, expression and type >. Let \|\\e:\|\>\\.\> with =\\C|)>> as in Proposition . Let > be a conjunction of atoms without predicate variables. We call |\>.F,\> a |\\e:\|\>> when ,\\F\\> (i.e. \F\\|)>>), \\.F|\>\>|]>> for some >>, and for every implication in >, if ,\\\FV|)>.D> then ,\\\FV,F|)>.D\F>. We are more interested in finding an unambiguous, directly given solution to a type inference problem, as introduced in Definition , than in derivability of a judgement \e:\> for some satisfiable . By Theorems and , these notions are close. Therefore, unlike in >, we say that an expression is in > under environment > with type >, when the type inference problem |\\e:\|\>> has a solution. The class of programs admitting a solution to the type inference problem can sometimes be expanded by enriching the languages of constraint domains. Note that both the derivability of \e:\> and the existence of a solution to the type inference problem |\\e:\|\>> allows for dead code in , i.e. unreachable cases of pattern matching. We offer an option to reject programs with dead code, according to the following definition: We call |\>.F,\> a |\\e:\|\>> when ,\\F\\> (i.e. \F\\|)>>), \\.F|\>\>|]>> for some >>, and for every implication in >, if \\> then ,\\\FV,F|)>.D\F>. However, some datatype-related dead code cases are rejected regardless of this option, due to constraints introduced by |\p\\||\>|\>> for patterns . In context of GADTs, existential types play a prominent role, beyond the traditional role of abstraction in software engineering. Without existential types, computations would need to express parameters of the output datatype invariant as a function of parameters of the input datatype invariant. Since GADTs are introduced to curtail the expressiveness of types compared to full dependent type systems, opportunities for such functional dependency are rare by design. We need the capacity in the type system to express whatever relations it can of the resulting datatype parameters to the input datatype parameters. Traditionally in GADTs we package the result into a custom datatype. This is tedious and contrary to the benefits of type inference. We automate this process, in effect introducing inferred existential types to our type system. Since the modification of the type system is minimal, formal guarantees carry over to it and it will be familiar to users of GADTs. Existential quantifiers in (contravariant) argument positions of function types are redundant: they can be lifted to be traditional, polymorphic variables constrained by the invariant of the function. However, they may sometimes be needed in nested positions of higher-order function types. We prohibit the use of inferred existential types in argument positions in the current version of the type system. We introduce a new expression construct >>, where is a value constructor, but is not available in concrete syntax, and >> are pattern matching clauses. In the implementation, the parser introduces a fresh and forms >> for >>>. We also introduce a corresponding construct >>. >> is either eliminated or replaced by >> in a normalization step. When \|\>|\>\.\\\|\>|)>\\> is such a data constructor absent from concrete syntax, the pretty-printer for types prints |\>|)>> as |\>\|\>\|\>|]>|]>.\>, or |\>|\>\|\>|]>|]>.\> when implies >\>. We also parse |\>.\> generating a fresh \|\>|\>.\\\|\>|)>\\> in the toplevel >, where |\>=FV|)>\\|\>>. Let > defined in Table determine whether an expression introduces or eliminates an existential type. It is used in the normalization process described below. Let all occurrences of > in use distinct . Let \n|)>>, defined in Table , flatten nested introductions of existential types. Let \\|)>>, defined in Table , collect value constructors introduced for existential types. The normalization-related functions ,v|)>> and ,v|)>> are defined for both expressions and clauses. The >> typing rules that differ from > are provided in Table . We put the normalization step into the type system as a rule . W.l.o.g. can be used once at the beginning of a derivation. performs a normalization of the expression and shares the job of introducing existential types with the rule . The relation can be introduced into the model > by induction on the structure of the first argument: \\,\|)>\RetType,\|)>> and |\>|)>,\|)>\\|\>|)>>\>. is the elimination rule for existential types. Although and resemble ``syntactic sugar'', their application is non-deterministic. We include value constructor environment in judgments to facilitate the completeness proof. We modify the rule to exclude function arguments that have existential types. We achieve that by introducing a new atomic predicate > to the sort >: |)>> iff \\|\>.\>\|\>|)>>, i.e. > is not an existential type.<\float|float|t> <\big-table> <\eqnarray*> |)>>||>> x=n|)> >>K x>>|K\\\l=\>||>||)>>||>|>,\|)>>|||)>|\>|)>>>| e,K|)>>||,K|)> n,\|)>>>|\e,\|)>>||,\|)>\n,\|)>>>|>> x=e >> e,K|)>>||>> x=n,\|)> >> n,K|)>>>|>> \n|\>.e,K|)>>||>> ,\|)>\n,\|)>|\>.>> n|)>>>|e=>> s>||>|>> \n|\>.e,K|)>>||>> ,\|)>\n,\|)>|\>.n|)>>>|e\>> s>||>|>,\|)>>|||\>|)>>>|>,K|)>>|||)>|\>|)>>>|K\\>||>|>> p=e >> e,K|)>>||>> p=n,\|)> >> n,K|)>>>|>> e\e;e,K|)>>||>> n,\|)>\n,\|)>;n,K|)>>>|>> e=e;e,K|)>>||>> n,\|)>=n,\|)>;n,K|)>>>>> <\float|float|t> <\big-table> <\itemize> ||>||>|>||,\\e:\\\>|>|,\\e:\>||)>>>>>>|C,\,\\e e:\>>>>||||\>|)>\>|C,\,\\e:\>>|,\\K p.e:\\\>|>>>>|C,\,\\>> p=e >> e:\>>>>|>||||>|>||>|>||)>\\Dom|)>=\>>|,\\n:\>>>>>|C,\,\\e:\>>>>||RetType,\|)>|)>>>|\\>:\>>>>>|C,\\\>:\>>>>|>>>> \; >>> <\float|float|t> <\big-table> <\eqnarray*> |\\e e:\|\>>||\.|\\e:\\\|\>\|\\e:\|\>\|)>,\#FV,\|)>>>|||>||\,\\e:\|\>>|||\,\\n:\|\>>>|\\\>||\=\\\\,\|)>|]>.\\\|)>|\>\>>>|||>||\\>> p=e >> e:\|\>>||\.|\\e:\|\>\|\\p.e:\\\|\>\|)>\>|\\K p.e:\\\|\>|)>>>|||>|||\=K\\|\>|\>.\\\|\>|)>\\|}>>>|||>||\\\>:\|\>>||\.RetType,\|)>\\.\>\|)>\\|)>|)>\|\\\>:\|\>,\\#FV,\|)>>>>> <\definition> Let =\\\> and =\\\> be sets of value constructors related to each other as follows: <\itemize> |)>=\>, =\\\,\|)>|]>.\\\|)>|\>>, and =\|\>|\>\|]>.\\\|\>|)>|\>> where |\>|\>\.E> are solved form formulas. Define /\=\=|\>\|\>.F|\>|]>>, where =E\\>|\>> and |\>=|\>|\>>. \ Note that we do not lose generality by using single-argument datatypes |)>> rather than the general form |\>|)>>. Multiple parameters can be captured by providing a constraint \\\.\>\\\\\>, with existential variables \\>, as part of the constraints of constructors of |)>>. The single parameter > in condition RetType,\|)>|)>> of the rule is not consequential. In the implementation of , we recover the multiple parameter representation |\>|)>> of existential types, at the end of inference. Normalization defined in Table is responsible for introduction of existential types, but it also ensures that existential types never directly wrap around other existential types. This flattening enables the use of all information available to derive the postcondition, i.e. the existential type. To flatten nested existential types, we rename constructors to > in >,K|)>>, and eliminate potential existential type before introducing one in |)>> when \\\l=\>. Note the frequent need to use (and its syntax sugar forms and ) for all branches of a definition, as for example in function in Section . The branches bound by or would be required to have the exact same type, e.g. the same number , height of a tree or length of a list. The type inference uses predicate variables to determine the information bundled inside existential types. The constraint derivation rules related to existential types are provided in Table . For the initial call to |\|\>> (i.e. case \\>), we normalize the expression. We shorten |\,\\\:\|\>> to |\\\:\|\>>. Our tools for solving second order constraints only handle conjunctions of implications. We solve disjunctions early, which is problematic as selecting a disjunct may require information hidden in other disjunctions or in predicate variables. For example, in the normalization of constraints we need to associate each unary predicate variable with at most one inferred existential type that can occur as return type in its solution. The pragmatics we adopt in is that whenever the |\\p.e:\\\|\>> disjunct coming from the rule is satisfiable with the rest of the constraint, we select it for the solution. One can turn the pragmatics into semantics by adding the premise ,\\\|)> e:\> to the rule, but it would make the formalism more complex. The proof of the following theorem is in Section . <\theorem> Theorems (Correctness) and (Completeness) hold for the type system extended with and in the following sense. Recall the notation from Theorem . Correctness: For all ,\,e> and >, |\,\\e:\|\>,\,\\e:\> is derivable. Completeness: For all ,\,e> and >, if ,\|)>=\> and ,\\e:\>, then there exist interpretations of predicate variables ,\> such that |)>> are unary, |)>=K\\|}>>, and ,\\C\\|\,\\e:\|\>|)>|\>|)>|\>\|\>|)>|\>|]>>. The set of value constructors is updated in after a toplevel definition with a well typed body: from > to >, using the notation from Definition . <\example> Consider the function for lists with length. The >>> syntax is a syntactic sugar for the >>>>> syntax, which in turn is a syntactic sugar for >>>>> expressions. <\code> datatype List : type * num datacons LNil : >a. List(a, 0) datacons LCons : \ \ >n, a [0>n]. a * List(a, n) > List(a, n+1) \; let rec filter = fun f -\ \ \ efunction LNil -\ LNil \ \ \| LCons (x, xs) -\ \ \ \ \ eif f x \ \ \ \ then let ys = filter f xs in LCons (x,ys) \ \ \ \ else filter f xs As an aside, an example interaction with might look as follows: <\code> $ ./invargent -inform examples/filter.gadt val filter : \ \ >n, a. \ \ (a > Bool) > List (a, n) > >k[0 > k > k > n].List (a, k) InvarGenT: Generated file examples/filter.gadti InvarGenT: Generated file examples/filter.ml InvarGenT: Command "ocamlc -w -25 -c examples/filter.ml" exited with code 0 Below we show the corresponding type inference constraint, slightly simplified by hand for readability. Constructors such as >|)>> identify an occurrence of an existential type, here \.\,\|)>> in a constructor environment with \\\\,\|)>|]>.\\\>|)>>. <\eqnarray*> ||\.\\.\n\\\.\k\\.\\\\\\.\\\\\.\n\\\\.>||>||||)>>>||>|>||)>>|>|>List,n|)>\\>\\List,n|)>\\>>||>|>|,0|)>>List,n|)>\\|)>>|>|>\>|)>\\,0|)>,\|)>>>||>|>|,k+1|)>>List,n|)>\>|>|>\\Bool\>>|k\\|)>>||\List,k|)>\\>|)>|)>\>>|||\List,k|)>\\>|)>|)>>>||>|>|>|)>>\>|)>\\,\|)>\>|>|>\>|)>\\,\|)>\\>List,n|)>\>>|,k+1|)>>List,n|)>\>||>List,n+1|)>\0\n>>|k\\|)>>||>||>|>|>|)>>\>|)>\\,\|)>\>|>|>\\\>\>|)>\\,\|)>>>|,k+1|)>>List,n|)>\>||>|k\\|)>>||>>> Branch ensures that the invariant is satisfiable. Branch decomposes the type of the recursive definition and ensures that the second argument is a list. Branch is the case of empty list. Branch handles the two recursive calls. Branch is the case of kept element: the recursive call result > has length one-shorter than the result >. Branch is the case of a dropped element: the recursive call result > and the function result > are the same. >> The typing rules that importantly differ between > and >> are: , , , , , , . The remaining, crucial difference lies in having predicate variables among constraints. However: <\itemize> , and can be seen as ``desugaring'' a program to a core language, pattern matching branches that invoke are unreachable and so can be dropped, pattern matching branches that invoke can be dropped, because they lead to runtime failure, computationally equivalent to a match failure, in >> is a restricted form of its variant from >. Therefore, if an inference problem constraint |\,\\e:\|\>> holds, then we can build environment >, constructor environment > and an expression > such that ,\\e:\> is derivable in > for a satisfiable constraint >. For the reduction to be a convincing argument for soundness of the type system, we also need to show that the ``desugared'' expression > preserves the intended meaning of . For the details of the > type system, we refer the reader to Simonet and Pottier . <\definition> Consider a constructor environment > and an > expression . A of w.r.t. > is an expression achieved by iteratively replacing each subpattern > of with Dom|)>> by > and each subexpression > of with Dom|)>> by >. Consider an >> expression . An of is an > expression achieved by iteratively replacing each subexpression >> and >> of by >>, each subexpression >> e=e;e> of by >, each subexpression >> s> by a function call , and each subexpression >> x=e >> e> in by >> x=\ x.e >> e>. The HMG-form from Definition captures the intended meaning of programs. We provide semantics for the >-calculus underlying >>, by reducing each expression to its HMG-form and referring to the semantics for > provided in . In terms of concrete syntax, the HMG-form of a program is the program with clauses dropped, keywords replaced by , and replaced by . <\definition> For our purposes, let be the smallest congruence relation > such that >> x=e >> e\x.e|)> e> for any expressions ,e>, and .e|\>|)>\\.e|\>unreach|)>\\failure|)>>|)>> for any sequences of clauses .e|\>>. The condition is defined by: \e=>>\.e|)>\unreach|)>|)>> and \e=>> s\.e|)>\failure|)>|)>>. Expressions >> x=e >> e> and x.e|)> e> have the same result of reduction at the outermost context: e|]>>. Subexpressions >>> in a well-typed program are guaranteed to be unreachable in both >> and > type systems. Subexpressions >> s> are intended to halt a program, so we assume they are computationally equivalent to match failures (matching against a value not covered by any pattern matching case). The proof of the follwing theorem is in Section . <\theorem> Let ,\\e:\> be a typing judgment in >>. If |\,\\e:\|\>> is satisfiable, we can construct a satisfiable constraint >, an > environment >, constructor environment > and an expression > such that ,\\e:\> is derivable in >, and the tag erasure of > w.r.t. > is computationally equivalent to the HMG-form of (see Definitions , ). An expression is when it does not contain variables not bound by a >>>- or >>>-expression, or a pattern. A closed expression is if it is neither reducible nor a value, as defined in . <\corollary> . If a closed expression is well-typed under some constructor environment, then its HMG-form does not reduce to a stuck expression. Least Upper Bounds and Greatest Lower Bounds computations are the standard tools for finding unknowns involved in an order structure, see e.g. Knowles and Flanagan Section 6.3. In case of implicational constraints, constraint abduction (see Maher and Huang , Sulzmann, Schrijvers and Stuckey ) and constraint generalization belong to this tool-set. under Quantifier Prefix is the task of finding for an implication .D\C>, where > is a quantifier prefix and are conjunctions of atoms, a weakest solved form formula |\>.A> such that \|\>.A|)>\C|)>>, equivalently \|\>.A|)>\D\C>, \\FV.A\D> and \ \\.A|\>\>|]>> for some >>. under Quantifier Prefix handles several implications, i.e. .\\C|)>>, simultaneously: each condition holds for each ,C> pair. It is used to solve for a predicate variable appearing in multiple premises -- where we are interested in the GLB of the corresponding conclusions, ``modulo'' the corresponding premises. answer to a disjunction D> of conjunctions of atoms is a solved form formula |\>.A> such that for each , \D\\|\>.A>. It is used to solve for a predicate variable appearing in multiple conclusions -- where we are interested in the LUB of the corresponding premises. Equipped with these tools, consider first solving an un-normalized constraint > for invariants -- unary predicates |)>>. We want the invariants to be as weak as possible, to make the use of the corresponding > definitions (toplevel expressions) as easy as possible: the weaker the invariant, the more general the type of the definition. We solve for the predicate variables in multiple steps, maintaining partial solutions |\>>.F>|\>> and iterating till the solutions converge (see e.g. Cousot and Cousot ). We start with , |\>>=\>, >=\> for \PV|)>>. In each step, we solve the first order constraint .\\C|)>> achieved by reducing |\>\|\>>.>|\>|\>|]>> to prenex-normal form and duplicating shared premises. Let |\>=|\>>|\>>. We perform joint constraint abduction under prefix > (with parameters |\>>), let |\>.A> be one of the abduction answers. We divide the atoms of the answer |\>.A> into solutions to predicate variables >> and a remainder, or residuum, =A\\\>A>>, depending on the variables in the atoms and so that the residuum holds under the quantifiers: \.A>. Let |\>>.F>=\|\>>|\>.F>\A>>\\|]>>. If in th iteration, =A>, we are done. From \.A> and A\\\C|)>>, it follows that the constraint holds: \\> for =|\>\|\>.>|\>|\>|]>>. When >\\> for some >, we need to perform another iteration. It might be that the constraints added by a positive occurrence of > -- a recursive call -- cannot all fit in next iteration's \.A> and have to be a part of next iteration's >>. For postconditions, we want the strongest possible solutions, because a stronger postcondition provides more information at use sites of a definition. Therefore, in each iteration, we use constraint generalization to solve for binary predicate variables ,\|)>> without ``hurting'' the constraint. The generalization results |\>>.G>> are used to get the first order constraints for abduction |\>\|\>>.F>|\>;|\>\|\>>.G>|\>|]>>. However, we have more work when due to recursive calls of functions returning values of existential types, >\\>. Note that postconditions of each iteration are constructed from scratch, they do not accumulate. The way we utilize answers >> is by performing second-stage abduction. Let D>> be the constraint generalization problem resulting in the postcondition >>. We form the joint constraint abduction problem .\>\A>|)>>, and split its answer >> in the same way as for the first-stage abduction described above. We include the result in the partial solutions: |\>>.F>=\|\>>|\>.F>\>\A>>|)>>\\|]>>. This way, >> may be strong enough to imply >>, and hopefully >=\>. But we are still in trouble. Without the postcondition already in place, branches with recursive calls have too little information to imply what the postcondition should be. Therefore, during initial iterations ( and ), we only include non-recursive branches in the constraint generalization process. This leads to ``overshooting'': the initial postconditions may reflect properties specific to base cases. These properties get relaxed during successive iterations, and we only end with success after reaching a fix-point. The termination condition of the iteration might not be met. Actually, reports type inference failure if the solutions >> not converge after a fixed number of iterations. We have only observed diverging solutions due to numerical constraints. Abduction is a reasoning technique concerned with the search for explanations. An abduction problem is usually given by a background theory > and a formula , and the answer is a formula such that \\C> (relevance), \\A> (consistency), and has some restricted syntactical form, see Marta Mayer and Fiora Pirri . We are however interested in problems, with constraints expressed over a fixed model >. A constraint abduction problem is then given by a pair of formulas , and is its answer when (at least) \A|)>\C> (relevance) and \\FV.D\A> (consistency), see Michael Maher . We extend the formulation of joint constraint abduction (see ) to constraints with quantifiers. In general abduction, where a model is built as a solution, the quantifiers could be eliminated by Herbrandization. However, Herbrandization (and Skolemization) are operations on the level of a logic, not within a model -- they do not return equivalent formulas and do not work in a fixed model. The introduced functions are uninterpreted. We opt to keep the model > and handle quantification explicitly. We develop a combination procedure for abduction algorithms when their domains of constraints are combined in a very simple way (yet sufficing for type-inference-driven invariant generation). In joint, also called simultaneous, problems, we expect a single answer to solve several problems, here: to solve a conjunction of implications. A is a syntactically specified class of formulas, associated with a class of problems, for which satisfiability is trivial to check. We restrict solved forms to existentially quantified conjunctions of atoms, |\>.A>. The variables |\>> of a solved form |\>.A> that is an abduction problem answer, are ``free parameters'' of the answer, they are required to be ``unconstrained''. Due to the iterative nature of the main algorithm, we need to account for prior parameters |\>> similar to the new parameters |\>>. The constraints that we need to solve form a ( problem for short) of the form .\\C|)>>, where > and > are conjunctions of atomic formulas, and > is an arbitrary quantifier prefix. We assume that \C|)>)\\>. We also have a set |\>> of of the invariants. The conditions on abduction answers |\>.A> are as follows: <\enumerate> : \\\A\C|)>>, : \\.A|\>|\>\>|]>> for some >>, : \\\FV\A|)>.D\A>, condition: for all atoms A> such that \\.c> and \|\>\\>, and for all \FV> such that \|)>\\>, there exists \FV\|\>> such that \>\>. <\enumerate> is a stronger variant we use for sorts whose solved forms are substitutions. For all atoms >t\A> such that \|\>>, if \FV> such that \|)>\\>, then \>\>. <\definition> |\>.A> is an answer to a JCAQP problem .\\C|)>> with parameters |\>> for model >, written |\>.A\Abd,|\>,,C|\>|)>>, when is a conjunction of atoms, |\>#FV\C|)>,|\>|)>>, meeting the relevance condition, validity condition, consistency condition and condition. We can also consider Joint Abduction under a Quantifier Prefix problems for a logic, checking relevance condition: \\A\C|)>> and validity condition: \.A|\>|\>\>|]>>. The consistency conditions: for all , \\A>, are always met. The natural setting for constraint abduction problems is with a fixed model. Above we extend the definition to the case where instead of a model just a logic is given, just to shed light on relations between constraint abduction, general abduction, and decision (i.e. validity or satisfiability) problems. We call a JCAQP problem .D\C> (i.e. a non-simultaneous problem) a problem SCAQP. We write JCAQP>> to indicate the model. <\proposition> If the JCAQP>> problem .\\C|)>> without parameters has an answer, then \\.\\C|)>>. We say that JCAQP>> answer |\>.A> is than |\>.B>, when there exist terms >> such that \B\A|\>\>|]>>. <\example> For a free term algebra > over signature containing binary functors and constants , and JCAQP>> problem \x,y,z.>f\z>a|)>\>f\z>b|)>>, the most general answer is \.y>f|)>>. Indeed, \\x,y,z.y>f|)>\y>f> holds with ,y=f|)>,z=a> and \\x,y,z.y>f|)>\y>f> holds with ,y=f|)>,z=b>. For the SCAQP>> problem \x,y,z.>f\z>a|)>>, the set of maximally general answers is \.y>f|)>,z>a|}>>. Consider a conjunction of atoms interpreted in any free term algebra > over a signature . If is satisfiable, let > be a conjunction of equations whose left-hand-sides are variables not occurring in any of the right-hand-sides, such that \C\\>, otherwise let =\>. Let .C|)>> in case >\.C> be >, and otherwise be as before but with equations directed so that variables later in the prefix are on the left. .C|)>> can be computed by unification with linear constant restrictions, see Baader and Schulz . In effect: if for some >t\\> such that t|)>\\> (e.g. is not a variable) and x|)>\\>, then .C|)>=\>; if for some >t\\> such that x|)>\\>, there is a FV>, y|)>\\> and >y>, then .C|)>=\>; otherwise .C|)>=\>. Let |\>>.C|)>> be |\>>\\|\>|}>|)>\|\>.C|)>>, i.e. |\>>.C|)>=\.C|)>> where variables |\>> are existentially quantified in > and otherwise > is like >. Computing |\>|\>>.A|)>> decides the validity condition for =T>. <\definition> An abduction algorithm for JCAQP>> with parameters |\>>, ,|\>,,C|\>|)>>, generates a sequence of quantified conjunctions of atoms |\>.A|\>>, possibly infinite. The algorithm is if for every , |\>.A> is an answer to the JCAQP>> problem .\\C|)>> with parameters |\>>. It is if for every JCAQP>> answer |\>.A>, there is a and some >> such that \A\A|\>\>|]>> (with variables renamed so that |\>#FV|)>>). If the sequence is empty, we write ,|\>,,C|\>|)>=\>. Note that we do not require that only maximally general answers are returned. Although this would be preferrable, it is costly to guarantee in many constraint domains even with incomplete algorithms. We provide a plug-in architecture where to add a new sort to the logic it is enough to give an algorithm solving the JCAQP problem. Define an (cf. ) of a term > of sort > to be a maximally large subterm of > of sort s>: a subterm that is not a subterm of a subterm of sort \s>. Let |}>>. Let =Tsorts>X|)>> be a language interpreted in a multi-sorted free term algebra usorts>D|)>> which, besides the term variables >>, has usorts>X>. Let > be a quantifier prefix and ,C> be atomic conjunctions in > that form a joint abduction problem .\\C|)>>. For the purpose of Theorem , let > be complete JCAQP algorithms for usorts> and > be a complete JCAQP algorithm for the free term algebra . We start the multi-sorted abduction procedure ,|\>,,C|\>|)>> by performing > on the > part of constraints with alien subterms replaced by variables. For each JCAQP solution |\>.A>, we replace the > part of the th premise by the ``residual'' formula > and of th conclusion by ``residual'' formula >, defined in Table . We split the resulting JCAQP problem into single-sort problems for each sort usorts>, and we solve them using > algorithms. Finally, we build answers as conjunctions of answers for each sort. Let > be a quantifier prefix and ,C> be atomic conjunctions in > that form a joint abduction problem .\\C|)>> with parameters |\>>, and \|\>\\>. Let > be correct and complete JCAQP algorithms for usorts> and > be a correct and complete JCAQP algorithm for language =Tsorts>X|)>> and model usorts>D|)>>. We define the algorithm ,|\>,,C|\>|)>> in Table .<\float|float|t> <\big-table> \\D> and \\C>, where, for sorts>, ,C> are atomic conjunctions in >.>>| ,C> be formulas >,C>> with subterms >> replaced with fresh variables >|\>>>>|\X> for of sort )>>|>> are all alien subterms in >,C>>>>>>>>>| >|\>=|\>\|\>>, |\>|\>=>|\>\>|\>>>>| > is not satisfiable for some , ,|\>,,C|\>|)>\Abd,|\>,,C|\>i>|)>>>>| > is not satisfiable for some , ,|\>,,C|\>|)>\\>>>| D=\|)>>, C=\|)>> be solved forms of >, >>>| for which \D> is not satisfiable for some usorts>.>>| ,|\>|\>|\>,>,C>|\>|)>=\>, ,|\>,,C|\>|)>\\>>>| |\>.A|\>=Abd,|\>|\>|\>,>,C>|\>|)>>>>| > be > with alien subterms replaced by distinct fresh variables |\>>, |\>=|\>|\>>>>| =>t\\>\A|)>\|x\X,s\s|}>>>>| =>t\\>\C>\A|)>\|x\X,s\s|}>>>>| =\A>, \\>>>| =Abd,|\>|\>,\\A|)>|\>|\>\>|\>|]>,C\\A|)>|\>|\>\>|\>|]>|\>|)>\\|}>>>>| >|\>.A>|\>=Abd,|\>|\>,\\A|)>|\>|\>\>|\>|]>,C\\A|)>|\>|\>\>|\>|]>|\>|)>>,>>|\usorts>J>>>| for some usorts>, =\>, ,|\>,,C|\>|)>\\>>>| ,|\>,,C|\>|)>\|\>>|\>.A\A>|\>|\>:j\\J>>,>>||\>>|\>> are |\>>|\>|\>\FV\A>|)>>,>>|>|\>|\>> is a concatenation of >|\>> for usorts>,>>|\J>, |\>> span the cartesian product usorts>Abd> of solutions for fixed >>>>>>>>>> ,|\>,,C|\>|)>>> In this algorithm, we separate formulas into single-sorted formulas, we perform abduction for terms, and we perform abduction for other sorts with additional equations due to abduction for terms. The proof of the following theorem is in Section . <\theorem> Assume the conditions listed above. Then meets Definition and algorithm conditions. Introducing new variables |\>> puts additional burden on abduction in other sorts. In the current implementation of , we only replace > with > in the first iteration, when abduction in other sorts is not performed. For the details of the implementation, see Section . In Table , we assumed abduction algorithms are returning sequences of answers, from which the answers of interest are extracted. We implement abduction algorithms differently. We maintain a -- a list of answers to avoid, and the algorithms return the first answer they find which does not imply any answer in the discard list. Besides the discard list, the simple abduction algorithms take another argument: the partial answer. By starting the search for an answer to an implication from the joint solution to already solved implications, we ensure by construction that the final answer to the joint constraint abduction problem meets validity and consistency conditions. The relevance and no escaping variables conditions would be met regardless of starting from the partial answer. However, the search is greatly facilitated, because simple constraint abduction does not need to rediscover relevant parts of the answers to already solved implications. Sometimes such rediscovery is not possible. Abduction answer |\>.A> to C> is when \|\>.D\A|)>\D\C>. The notion was introduced by Michael Maher, see e.g. , to curb the difficulty of finding all abduction answers. Even equipped only with fully maximal abduction algorithms, by accumulating answers across implications we can still solve problems where some implications do not have fully maximal answers. To this effect, we vary the order in which implications are solved, so that when an implication C> without fully maximal answers is encountered, the answer |\>.A> to previous implications is such that A\C> has a fully maximal answer. In fact, our simple constraint abduction algorithms go beyond fully maximal answers. Rather than testing permutations blindly, we use a search scheme which might not capture all opportunities to solve a JCA problem, but detects unsolvable JCA problems earlier. We set aside branches that do not have any answer extending the partial answer so far. After all branches have been tried and the partial answer is not an empty conjunction (i.e. not >), we retry the set-aside branches. If during the retry, any of the set-aside branches fails, we add the partial answer to discarded answers -- which are avoided during simple abduction -- and restart. Restart puts the set-aside branches to be tried first. If, when left with set-aside branches only, the partial answer is an empty conjunction, i.e. all the answer-contributing branches have been set aside, we fail -- return > from the joint abduction. Before starting joint constraint abduction, we separate out negative constraints, as explained in Section . To ensure the overall consistency and validity conditions without needless backtracking, we pass a validation suite to SCA algorithms. The validation ensures that the partial answers are consistent with all implications of the constraint. That is, we reject the partial answers such that \\\FV\C\A|)>.D\C\A>. For the details of the algorithm, see Section . JCA problems for most interesting domains are unknown to be decidable, because the corresponding SCA problems are not known to have effective characterizations of the sets of answers. Maher introduces subsets of answers which are more amenable to search: abduction answer |\>.A> to SCA problem C> is fully maximal when \|\>.D\A|)>\D\C>. We can search for fully maximal answers using various forms of a brute-force approach: starting from an C> and generalizing until we find a formula, implied by C>, which meets all conditions for a correct SCA answer and all its further generalizations do not imply . It turns out that fully maximal answers are insufficient. We have come up with two additional ways to introduce initial candidates. One is to add -- guess -- atoms constraining variables which are already significantly constrained by the premise . The ``significant constraint'' condition limits the number of guesses to try. The other way is to decompose the SCA problem C> into subproblems c> for atoms D,c\C> and add their answers to initial candidates. In many domains, all maximally general answers to c> can be easily enumerated. Even considering all initial candidates described in this paragraph does not ensure finding all maximally general answers. We preprocess the initial SCA answer candidate > by trying to eliminate universally quantified variables, using the premise of the SCA problem. We define this preprocessing, separately for the different sorts, as >,|\>,D,C|)>>. It makes the valididty condition of the resulting answer, \\.A>, easier to meet. See Dillig, Dillig, Li and McMillan for a similar approach. The JAQP problem for first order logic with function symbols and equality is undecidable, because it is equivalent, by Herbrandization, to simultaneous rigid E-unification (see Degtyarev and Voronkov ): the substitution that is a solution to simultaneous rigid E-unification when expressed as a conjunction of equations has the same properties as a JCAQP answer (therefore the existence of JCAQP answers coincides with intuitionistic satisfiability). Remember that outside of Definition , we use \> as a shorthand for \\>. The decision problem \\.\\C|)>> is decidable, see Comon . Actually, provides a disjunction as a solution, each disjunct meeting the relevance and validity conditions of the JCAQP>> problem. It is often the case though that each disjunct does not meet the consistency condition, despite the JCAQP>> problem considered having answers. The JCAQP problem for free term algebra > is unknown to be decidable. A limited form of JCA is to find the fully maximal answers, introduced in , using non-simultaneous abduction algorithm from Maher and Huang . refers to as establishing that there are finitely many fully maximal answers. gives an algorithm finding fully maximal answers for simple (i.e. non-simultaneous) constraint abduction problems. Let us recall why Herbrandization is insufficient and therefore we cannot apply the algorithm from without some adjustments. Take a formula x.>b\x>b|)>\\>. In the original model >, the formula is equivalent to x.\>, because >b> is equivalent to falsehood. However, it is a Herbrandization of x.b.a>b\x>b|)>\\>, which is equivalent to >. Fully maximal answers are not sufficient for the practical application of joint constraint abduction. Consider a constructor >:\\\.Term|)>\Term|)>\Term,\|)>|)>> and a pattern matching branch that we could add to our function: (eval y1, eval y2)>. It leads to an implication: <\equation*> \>Term,\|)>|)>\\>,\|)> where ,\> are universally quantified and ,\> are existentially quantified. The expected abduction answer >Term|)>\\>\\\>\> is not fully maximal because: <\equation*> \>Term,\|)>|)>\\>,\|)>\\>\\\>\ In the case of , the inference problem is solved by our JCA scheme even based on fully maximal abduction. But examples from Chuan-kai Lin (for example the and functions) motivated a development that goes beyond fully maximal answers: guessing equations between variables. To show how we eliminate universally quantified variables, we slightly abuse notation: <\eqnarray*> |||\>\|\>|]>FV|)>\|\>\\,\|\>\\\\D\>,>>|>||>\|\>|]>>\|\>,\|\>\\\\D\C\>,>>|>,|\>,D,C|)>>||c=x>t\C,x=Sc=Sc=S*S|}>>>>> is a substitution of subterms rather than a regular substitution of variables. \ To solve C> the algorithm from page 13, reproduced in Table , starts with C|)>> and iteratively replaces subterms by fresh variables \|\>> for a final solution |\>.A>. If the same subterm occurs at multiple positions, we try replacing by the same variable at subsets of these positions. We start from >,|\>,\A|)>,\\D\C|)>|)>>, where |\>.A> is the solution to previous problems solved by the joint abduction algorithm. Optionally, we also substitute-out in the initial candidates, constants \\> when >\\\A|)>>. The modification going beyond fully maximal answers, is to consider candidate atoms not implied by C>, even in the case without an initial partial answer: =\>. A natural choice is to consider equations >\> for parameters \\|\>>. To curtail the search space, we limit the choices of pairs ,\> to cases \D\C\\>\\\>\> where > and > are not variables but are unifiable. For the details of the algorithm, see Section . We start with some insights into abduction for linear arithmetic, and then discuss our algorithm. Unlike in term abduction, there is no need to introduce variables. <\proposition> The domain of linear arithmetic has the following property: for every constraint (i.e. conjunction of atoms) and variables |\>> there exists a constraint > such that \|\>.A|)>\A>. With inequalities, it can happen that there are no maximally general answers, there can also be infinitely many maximally general answers outside of fully maximal answers. The of a conjunction is a conjunction of equations of biggest rank such that \C\E> and are linearly independent of equations in . <\proposition> p. 14 Lemma 10>Suppose C> has implicit equalities . Then A\D\C> iff A\D\E> and D|)>\>. Consider the SCA problem >2r\y>2s\z>2t> and a maximally general answer y>z\r+s>t>. It is not fully maximal, because D> does not imply any relation between and . To simplify the search in presence of a quantifier prefix, we preprocess the initial candidates by trying to eliminate universally quantified variables: <\eqnarray*> |||\>\|\>|]>\|\>\\\\D\>,>>|>,|\>,D,C|)>>||c\C,\\\.c|\>\>|]>>c=cc=S|}>>>>> We approach solving for equations >t\C> and inequalities \t\C> differently. For equations, we construct initial candidates as linear combinations of and selected equations from . For inequalities, we construct the initial candidates by finding the abudction answers to c> for each inequality D>. To find the abduction answers to c>, pick a common variable \FV\FV> or the constant =1>. We have four possibilities: <\enumerate> \\d>> and \\c>>: the abduction answers are and >\c>>, \\d>> and c>\\>: the abduction answer is only , d>\\> and \\c>>: the abduction answer is only , d>\\> and c>\\>: the abduction answers are and >\d>>. Thanks to cases (1) and (4) above, the abduction algorithm can find some answers which are not fully maximal. To check whether B>, we check for each B>: <\itemize> if >y>, that =A>, where |)>> is the substitution corresponding to equations and implicit equalities in ; if |\>y>, that y|\>x> is not satisfiable. For more details of the algorithm, see Section . We define as the task of finding common consequences, as specific as possible, of conjunctions of atomic formulas. Notice that there is at most one maximally specific constraint generalization answer. Therefore the completeness condition for constraint generalization reduces to requiring most specific answers. <\definition> A quantified conjunction of atoms |\>.A\\> is a to D>, where > are conjunctions of atoms in >, when \\\\|\>.A|)>>. A constraint generalization answer is when: for every solution |\>.A> with \\\\|\>.A|)>>, \A\\|\>.A> (with variables renamed so that |\>#FV>). By |\>|)>> we denote the most general constraint generalization answer to D>, by |)>> an algorithm that computes it. Consider an -like example, where the disjuncts include the conjunctions of premises and conclusions of a type inference constraint. We are interested in finding <\eqnarray*> \C|\>|)>>|LUB>|>\\\\\>Term\\>Int,\>\\\\\>Term\\>Bool,\>\\\\\>Term|)>\\>\|)>>>>> for which the solution is \.\>\\\\\>Term|)>\\>\>. We discuss issues specific to postcondition inference in Section . First order most specific anti-unifiers are closely related to constraint generalization. <\definition> A sequence of substitutions |\>> is an of a same-length sequence of terms |\>> when there is a term > such that i,S|)>=t>. The term > is called a of |\>>. An anti-unifier |\>> is a of |\>> when given any other anti-unifier |\>> there exists a substitution > such that =S\>. We call > such that |)>=t> the (MSG) of |\>>. We require, without loss of generality, that variables used by anti-unification are fresh: XS\x|}>#FV|\>|)>>. We define an (cf. Baader and Schulz ) of a term > of sort > to be a maximally large subterm of > of sort s>. Let |\>|)>> give most specific constraint generalization answers to D> for conjunctions of atoms of sort for s>. We define |\>|)>=\|\>.A> in Table .<\float|float|t> <\big-table> D\D> where > is of sort >>| > be >> with all alien subterms |\>> replaced by fresh variables |\>> of corresp. sorts>>| =|\>>|\>> and D\D> where > is in sort >>| D\\|)>> where > is of sort >>|>:>>| ,|\>\i\t.x>t\D>|}>>>>| |\>,g,|\>S=|\>\>|]>,S|)>=t|}>>>>|t|\>,|\>|)>\V|}>> for each >>| =\|\>>>> and =D>\D>>>| =>yx>t\D,y>t\D,\\D\t>t|}>>>>| >=\x>g\\D|)>>>>|>b,b>a> appears anywhere>>| |\>>=|\>|\>>>>>>>>>| D\D> for > of sort >>|s>:>>| |\>.A=LUB\|~>\D|)>|\>|)>>>>| |\>|\>|\>|\>.\A>>>>>> |\>|)>=\|\>.A>> The algorithm separates formulas into single-sorted formulas, computes anti-unification of terms equal to the same variable in each disjunct, and calls constraint generalization for other sorts. It adds to the disjuncts passed to generalization for other sorts, equations binding the generalization variables (introduced by anti-unification) of the particular sort. To find the anti-unifiers, we adapt the anti-unification algorithm provided in Ųstvold , fig. 2. The proof of the following theorem is in Section . <\theorem> |\>|)>> from Table meets the Definition conditions for most specific constraint generalization answer to D>. In our actual implementation, we do not separate alien subterms, i.e. we do not compute > and >. Rather, we rely on our implementation of unification > to separate out equations in sorts other than >. Equality under premises within linear arithmetic: \>\> can be decided by checking whether the polytopes \\\> and \\\> are empty, which can be done by Fourier-Motzkin elimination. In contrast to the free term algebra, for the logic of linear inequalities over real or rational numbers we have the following quantifier elimination property. For all |\>.A\\>, there is a conjunction of atoms > such that \A\\|\>.A>. Therefore, we need not introduce new variables. A system of linear inequalities is when the set of solutions is not contained in an affine subspace of dimension smaller than the number of variables. In other words, a full-dimensional system of inequalities does not have implicit equalities. The task of constraint generalization |\>|)>> for full-dimensional inequalities is equivalent to finding the convex hull of the half-space represented, possibly unbounded polytopes >. Fukuda, Liebling and Lütolf provide a polynomial-time algorithm to find the half-space represented convex hull of closed polytopes. The algorithm can be generalized to unbounded polytopes. When all variables of an equation >b> appear in all branches >, we can turn the equation >b> into pair of inequalities b\b\a>. We eliminate all equations and implicit equalities which contain a variable not shared by all >, by substituting out such variables. We conjecture that the resulting algorithm meets the correctness and completeness conditions. More details of the algorithm implemented in can be found in Section . It turns out that constraint generalization as we defined it is insufficient. Consider replacing by in a function of type \\> for which type inference works fine. We expect the resulting type to have the form \\.\>, i.e. without existential type variables. But while unification reconstructs > from the result types of the branches, constraint generalization will fail to generate > when a branch under-constrains the result, does not ``care'' about the specific type. To mitigate this problem we introduce and modify our anti-unification algorithm. Constraint generalization in the numerical domain does not need such modification. We extend the notion of constraint generalization: <\definition> Substitution and solved form formula |\>.A> are an answer to problem |\>> given a quantifier prefix > when: <\enumerate> i|)>\\U|)>\\|\>\\FV.A>; If \Dom>, then \|)>\\> -- variables substituted by are existentially quantified; i|)>\\\|)>\|)>\\Dom|)>.D>. The sort-integrating algorithm changes only minimally. We adapt the anti-unification algorithm to compute the substitution from Definition . For details of the algorithms, see Section . We collect implication branches with conclusion =\> and do not pass them to abduction or constraint generalization. For the numerical sort, optionally but by default, we try to turn the negative constraint \\> into a positive contribution to constraints under assumption that the numerical domain is integer numbers rather than rationals. We convert D> into disjunctive normal form, and replace strict inequalities 0> with weak inequalities -1>, assuming w.l.o.g. integer coefficients in . We eliminate each disjunct inconsistent with some branch \C>. If exactly one disjunct remains, it is the solution to the negative constraint \\>. After a joint constraint abduction answer has been found, we check whether all negated constraints, i.e. > for =\>, are inconsistent. If not, we backtrack: redo abduction with > put into the discard list. Moreover, we include in simple constraint abduction a heuristic to prefer partial answers which make more negated constraints inconsistent. For details of the algorithm, see Section . Faced with an inference problem >, we solve it using iterated abduction. Let <\equation*> \\\\\\\.\\C|)>=\\NF|)> where ,C> are conjunctions of atoms, be quantifier alternation-minimizing normalization of > (the variable > is used just to bring existentially quantified variables to the front, if possible). Using the prenex-normal form simplifies formal presentation. <\definition> We will say that a quantifier prefix and a solved form formula |\>.A> are in |\>>>, when: variables |\>> are in the same quantifier alternation in >, \\.A|\>|\>\>|]>> for some >>, and the following two conditions hold: <\enumerate> there are no properties expressed in in a way constraining parameters |\>|\>> that can also be expressed without constraining them: if there are conjunctions of atoms such that \D\C\A> and \\.D>, then there exists a conjunction of atoms such that A>, \\.B> and \C\>, where is a conjunction of atoms in that are not in ; all properties expressed in in a way constraining parameters |\>|\>> are also expressed using only variables \>> (for any \|\>>) and |\>|\>>: if there is a conjunction of atoms A> such that \\|\>|)>\|\>|\>|)>|]>.C>, then there is a conjunction of atoms A> such that \\\>|\>|\>> and \\|\>|)>\|\>|\>|)>|]>.D\C>. The atomized form is |\>>|\>>> when it is an atomized form with respect to parameters |\>>> for all |\>>\|\>>|\>>. <\proposition> Let .|\>>>\|\>>>> be a formula in > with sorts > and the linear arithmetic sort. If |\>\>;|\>\>|]>> is a substitution, |\>\>|]>> agrees with quantifier prefix > and |\>\|\>|\>>, then |\>.|\>>>\|\>>>> is in atomized form w.r.t. parameters |\>>. Symbolically we denote an atomized form that is equivalent to by >. For inequalities, > can be recovered during the Fourier-Motzkin procedure by keeping some of the inequalities implied by . Atomized forms are required so that we can distribute the constraints among the predicate variables -- implicit constraints are made explicit. Take a conjunction of atoms \>, a quantifier prefix >, and variables |\>,|\>>|\>>, where > varies over |)>>. Let us discuss the routine ,|\>,A,|\>>|\>,>|\>|)>> defined in Table <\float|float|t> <\big-table> <\eqnarray*> |\\>||\>\\\>\\\\>\\\\|\>>|\>\\\|\>>|\>|)>>>|\>>||>\\A\\|\>>|\>\\|)>\\\\\\|}>>>|>||\>>>|>>||A\\\FV.\|)>\\\\\>\>\\\PrimCV\\\|\>>|\>\\\PrimCV|}>>>|>>|||\>>|\>,A>|)>>>|>>||>\\\>A>>>>> \\.\>A>|)>|\>\>|]>>> > >|\>\\>>\A>|)>\\\.>A>\A|)>|\>\>|]>>>: \ \ \ >,|\>>|)>\\> \ \ \ > \ \ \ <\eqnarray*> |\>>,A>,A>>||>,|\>>|)>>>|>>||>\A>>>||\>>>|||\>\FV>|)>>>||\>>>|||\>>\\>\>|\>>|)>|\>>>>|>||>A>>>|>||\|~>\>A>|)>>>>> \ \ \ \ \ \ >|\>>\\\\>A>\\> \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ ,A,|\>>.A>|\>\> \ \ \ \ \ \ \ \ \ \ \ \ |\>>|\>\|\>>\|\>>|)>|\>|]>,|\>\\>|\>>,A\>A>,|\>>\|\>>|\>,>|\>|)>> \ \ \ \ \ \ \ \ \ ,A\>\A,|\>>|\>>.A>|\>> \ \ \ \ \ \ \|\>\\>|\>>|)>,A\>\A,|\>>.A>|\>> |\>>|)>> is computed as follows: <\enumerate> for every A>, and for every \FV> such that \>\> for \|\>>>, if > is universally quantified in >, then return >; otherwise, introduce a fresh variable >, replace c\\|]>>, add >\> to >> and > to |\>>>, after replacing all such > add the resulting to >>. \; ,|\>,A,|\>>|\>,>|\>|)>>> . > stands for of an atom . These are the variables that can be separated to one side of the atom . For the sort of terms and the numerical sort, \PrimCV> if and only if: \>t>, or \\t>, or t\\>, for some including ,t|)>> and ,t|)>> for some ,t>. For other sorts, the definition of |)>> needs to be extended analogically. The selections of >|\>> we try are minimal with respect to pointwise set inclusion, i.e. wrt. > defined as >|\>\>|\>\\\.A>\A>>. The routine separates an answer formula into components that need to become (parts of) the predicate variable solutions, and the residual answer >. The residual answer is a satisfiable formula, it contains solutions to the existentially quantified variables. In particular, the types of expressions of interest can be extracted from the final residual answer. Note that due to existential types predicates, we actually compute ,|\>,A,|\>>>|\>,>>|\>|)>>, i.e. we index by >> (which can be multiple for a single >) rather than >. We retain the notation indexing by > as it better conveys the intent. Let ,|\>,A,|\>>|\>|)>> be ,|\>,A,|\>>|\>,|\>|)>>. In Table , we describe a single step of solving for predicate variables. The iteration of the algorithm starts by substituting the partial solutions to predicate variables from the previous iteration (Table , Eq. ). Next, it performs constraint generalization, to find the current solutions for postcondition-related predicate variables (Eq. ). The found postconditions are then substituted for predicate variables in premises, i.e. at places where a definition returning an existential type is used recursively (Eq. ). Having stronger premises simplifies, and sometimes enables, the subsequent abduction (Eq. ). The abduction answer is split into parts (Eq. ), that are added to the partial solutions to predicate variables (Eqs. , ). When abduction shows we need richer postconditions, an auxiliary round of abduction is performed (Eq. ). It infers additional preconditions that enable the required postconditions. We add these preconditions to the partial solutions (Eq. ). If the resulting partial solutions differ from the initial partial solutions, we continue with another iteration of the main algorithm.<\float|float|t> <\big-table> <\eqnarray*> ||||\>,k>.F>|\>>||>>|||>>|||S.>>|>\C>\RS|)>>||\,\>|)>\C>,>>|||>|\>=D\C\S|)>\D\D>|}>>>|>|||)>\>>|>,\|\>>.G>,|\>>||,>\\D>\C>|\>\|\>>|)>>>||\>>>||\FV>|)>\\\\|\>>\|)>\\\\\|\>>|\>\\|\>>|}>|\>>>||\>>.G>|)>>||FV|\>>,G>|)>\\\\.\>|\>>\G>>>||\>>.F>|)>,\>|||)>,\|\>>.G>|)>|)>>>||)>>|||\>>.F>>>|,\|)>|)>=P|)>|)>>||>|\>>>>|>>||>|\>|)>\\|\>>|)>|\>>,|\>|)>|]>|]>>>|>|||\>,k>\FV>|)>\>\>\|}>.F>|\>>>|.\\C|)>\\\|)>>||PS\>U>|)>>>||\>.A>||,|\>=>|\>>|\>,,C|\>|)>>>|||\NegElimSimpl|)>\\|\>>|\>.D|)>,A,,C|\>|)>>>|||>>|,A,|\>>>.A>>|\>|)>>||,|\>,A,>|\>>|\>|)>>>||\>>>|||~>|\>>|)>|)>|\>>>||)>>|||\>,k>|\>>>|\>|\>>\\FV|\>>|)>.\>|\>>\|~>>\\\>\|)>\>A>>>|\>>>|\>\|\>,k>|\>|]>>>|>||A>>>|\>>>|\>\|\>,k>|\>|]>FV\FV|)>|)>|}>>>||\>.A>||,>|\>>|\>\\>|\>>|\>,|)>,A|\>|)>>>|,\,|\>>>.A>>|\>|)>>||,|\>|\>,\A,>|\>>|\>\\>|\>>|\>|)>>>||)>>|||\>,k>.Simpl|\>>>|\>.F>\A>>>|\>>|\>\|\>,k>|\>|]>\A>>|)>>>>> \; of solving for predicate variables> Recall Definition of solutions to a type inference problem >. <\proposition> If a solution to the inference problem > exists, then there is an interpretation of predicate variables > such that ,\\\>. Define <\equation*> \=,|\>,|\>|)>|}>\=,|\>,k>.F>|\>,|\>,k>.F>|\>|)>\\>\,|\>,k>.F>|\>,|\>,k>.F>|\>|)> where the operator > such that |\>.A,S,R|)>\\,S,R|)>> for =|\>,k>.F>|\>>, =|\>,k>.F>|\>>, is defined in Table . The convergence condition is: <\eqnarray*> ||\|)>S|)>\S|)>,>>||>|\|)>R|)>=R|)>,>>||>|\>|)>A>>=\,>>||>|1>>>> \ We argue for the truth of the following theorem in Section . <\theorem> . Let =|\>\|\>>.F>|\>;|\>\|\>.F|\>|]>> be an interpretation of predicate variables for an inference problem >. If |\>.F,|\>>.F>|\>,|\>>.F>|\>|)>\\,|\>>.F>|\>,|\>>.F>|\>|)>>, then ,\\\>. To prove Theorem , we have to assume that there are no existential type predicate variables, i.e. for an inference problem >, |)>=PV|)>>; and also that in the definition of > is a complete abduction algorithm returning an atomized form formula. Since the completeness of abduction assumption is not met, Theorem does not describe an actual implementation. We argue for the truth of Theorem in Section . <\theorem> Let |\>.F,|\>>.F>|\>|)>> be any solution to an inference problem > with |\>=PV|)>=PV|)>>. Assume that in the definition of > is a complete abduction algorithm returning an atomized form formula. Then there is a chain |\>.F,|\>,k>.F>|\>|)>\\>, with |\>,k+1>.F>|\>|)>\\,|\>,k>.F>|\>|)>>, such that for all 1>, \\>F>\>F>|)>|\>,k>|\>\>|]>> for some >>. For more discussion on the implementation, see Section . : Tests and Limitations> In this chapter we present types and inference times of tested examples, measured on a laptop with processor at 2.30GHz, 3MB cache. The implementation does not use parallelism. Table contains examples using the plain GADTs type system, without numerical constraints and existential types. Consider the examples from Chuan-kai Lin's . We tested 7 longer examples where algorithm > finds the expected type. does not have problems with these cases either, except the function. We also reproduce all 8 examples from where algorithm > fails, adapting them only to accomodate to the type system > behind . fails on two examples. One, the function , was contrived to not have a clear intended type. The other, the function , can be slightly modified to work with 's type inference. There is also one example, function , which requires non-default parameter setting (passing a parameter to ). In a future version, will attempt multiple parameter settings before giving up. Overall, we consider the behavior of on this test suite to be a success.<\float|float|t> <\big-table> \; ||||||||||||||||||||||||||||||||||||>|>|>>|>|>a.R a>Int>>|0.01s>>| examples from within the scope of algorithm > |<\cell> >a.Dir>Int>RoB (Black, a)>Dir>Int> RoB (Black, a)>RoB (Red, a)>RoB (Black, S a)>> |>||>a, b.Zip2 (B, a)>b>a>>>|>||<\cell> >a.AVL a>Int>AVL (S (S a))> Choice (AVL (S (S a)), AVL (S (S (S a))))>> |>||>a.Int>AVL a>Choice (AVL a, AVL (S a))>>>|>||>a, b.Path b>Tree (b, a)>a>>>|>||>a, b.b>State (b, a)>(b, a)>>>|>||>a, b.List (a, S b)>a>>>|>>>| examples from outside the scope of algorithm > |<\cell> >a.Split (a, a)>a>> |0.01s>>||<\cell> >a.Int>AVL a>AVL (S (S a))> Choice (AVL (S (S a)), AVL (S (S (S a))))>> |>||<\cell> >a.AVL (S a)> (Int, Choice (AVL a, AVL (S a)))>> |>||<\cell> >a, b, c.FunDesc (c, b)>FunDesc (b, a)> FunDesc (c, a)>> |>||>a, b.Zip1 (List b, a)>b>a>>>|>||>a.Nat a>NatLeq (a, a)>>>|0.01s**>>||>a, b.b>State (b, a)>(b, a)>>>|>||>|>>>>>|<\cell> >a.Term a>a>> |>||<\cell> >a,b.(Ty a, Ty b)>a>b>Bool>> |>>>> * Slight meaning-preserving modification of test program ** Needs a non-default option Table contains examples using numerical constraints and existential types. The examples are organized around several data structures: lists and arrays with length, binary numbers, AVL balanced search trees. We provide the inferred types in the hope that they are self-explanatory.<\float|float|t> <\big-table> \; |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||>|>|>>| lists with length and arrays with static bound checks |<\cell> >n,a[1>n].List (a, n)>a>> |0.01s>>||>a,n,k.List (a, n)>List (a, k)>List(a, n+k)>>>|>||<\cell> >n, a. List ((a, a), n) > List (a, 2 n)>> |>||<\cell> >n, a. List ((a, a, a, a), n) > List (a, 4 n)>> |>||<\cell> >n, a. (a > Bool) > List (a, n) > >k[0 > k > k > n].List (a, k)>> |>||<\cell> >a,b,n,k.(List (a,n), List (b,k))> >i[i=min(n, k)].List ((a,b),i)>> |>||<\cell> >n, a[0 > n]. a > Array (a, n) > >k[0 > k + 1 > k + 1 > n].Num k>> \ |>||<\cell> >i, j, k, n, a[1 > j > 0 > n > 0 > k > i + k > j > i + n > j]. Array (a, j) > Num n > Num k > Num i > ()>> |>||<\cell> >i, j, k, n[0 > n > 0 > k > 0 > j > j > i]. Matrix (n,j) > Matrix (i,k) > Matrix (n,k)>> |>||<\cell> >n,k,i.Carry i>Binary k>Binary n>Binary (n+k+i)>> |>||<\cell> >n.Binary n>Binary (n + 1)>> |>||<\cell> >k, n. Binary k > Binary n > >i[k > i > n > i > i > n + k].Binary i>> |>| AVL trees, imbalance of 2 |<\cell> >k, n, a[0 > n > 0 > k > n > k + 2 > k > n + 2]. Avl (a, k) > a > Avl (a, n) > >i[i=max (k + 1, n + 1)].Avl (a, i)>> |>||<\cell> >k, n, a[0 > n > n + 2 > k > k > n + 3]. Avl (a, k) > a > Avl (a, n) > >n[k > n > n > k + 1].Avl (a, n)>> |>||<\cell> >n, a. a > Avl (a, n) > >k[1 > k > n > k > k > n + 1].Avl (a, k)>> |>||<\cell> >n, a[1 > n]. Avl (a, n) > >k[n > k + 1 > k > n > k + 2 > 2 n].Avl (a, k)>> |>||<\cell> >k, n, a[n > k + 2 > k > n + 2]. (Avl (a, n), Avl (a, k)) > >i[n > i > k > i > i > n + k > i>max (k + 1, n + 1)].Avl (a, i)>> |>||<\cell> >n, a. a > Avl (a, n) > >k[n > k + 1 > 0 > k > k > n].Avl (a, k)>> |>||<\cell> Total time for , and helper functions: |>>>> Table contains examples of static array (and matrix) bounds checking. These tests originally date back to the Hongwei Xi's DML system. They were selected, by , to demonstrate the abilities of the Liquid Types system inference implementation . The reported times come from and . The example lists two times: the shorter time is inferred from a program without an unused nested definition of . We extracted the corresponding computation as the example in Table . The shorter time for the example corresponds to a variant where some helper functions are separated out as toplevel definitions, while the longer time is for a variant with a single toplevel definition. For the example program without assertions we again have two variants, but they both simplify the original example. They remove a redundant level of nesting in a helper, nested definition . One of the variants requires passing a non-default option to guide inference, the other slightly generalizes the algorithm by passing a different matrix dimension in two places. Since our type system does not allow existential types as function arguments, for the FFT examples we introduce an explicit datatype . The FFT example with assertion requires non-default option . On the whole, we believe that the approach taken by shows promise in this comparison. It is clear that faces increasing difficulties when analysing more complex programs. We propose remedies to the issues encountered as future work.<\float|float|t> <\big-table> \; ||>|<\cell> |<\cell> > >|>||>|>||>|>||>|>||>|>||>| no assertions>||>>>| with assertion>||>|>||>|>||>| no assertions>||>| with assertion>||>|>||>| no assertions>||>| with assertion>||>>>> * Slight meaning-preserving modification of test program ** Needs a non-default option *** Needs a non-default option The code of examples from Tables , and can be found in Appendix . Failure Cases> Type inference for the type system underlying is undecidable. Constraint abduction itself is not known to be decidable. Rather than trying to enumerate all possible answers, we devised constraint abduction algorithms that only consider answers of restricted forms. The example from fails due to such limitation. However, the practical problems we encountered are not of such nature. Each subsection below describes a class of problematic cases, exhausting the types of inference failures we encountered. Near discuss the prospects of improving the situation. The one function from that needed modification to be type-inferred is . Take a look at the fragment of original definition that needed modification: <\code> let fd_comp = fun fd1 fd2 -\> \ \ let o = fun f g x -\> f (g x) in \ \ match fd1 with \ \ \ \ \| FDI -\> fd2 \ \ \ \ \| FDC b -\> ... The modified form: <\code> let fd_comp = fun fd1 fd2 -\> \ \ let o = fun f g x -\> f (g x) in \ \ match fd1 with \ \ \ \ \| FDI -\> \ \ \ \ \ \ (match fd2 with \| FDI -\> fd2 \| FDC _ -\> fd2 \| FDG _ -\> fd2) \ \ \ \ \| FDC b -\> ... Type inference needs to know the structure of both arguments to be able to infer the resulting type. If this problem proves cumbersome, we can devise heuristics for automatic expansion of pattern variables. The above problem is more pronounced in the numerical domain. Fortunately, here it can have a principled solution. Consider the following list appending example that does not type-check: <\code> let rec append = \ \ function LNil -\> (fun l -\> l) \ \ \ \ \| LCons (x, xs) -\> (fun l -\> LCons (x, append xs l)) We can mitigate the problem by expanding the pattern, as in Example : <\code> let rec append = \ \ function LNil -\> (function LNil -\> LNil \| LCons (_,_) as l -\> l) \ \ \ \ \| LCons (x, xs) -\> \ \ \ \ \ \ (function LNil -\> LCons (x, append xs LNil) \ \ \ \ \ \ \ \ \| LCons (_,_) as l -\> LCons (x, append xs l)) But we can also provide the ``hidden'' information explicitly, by either a positive assertion, or a negative assertion as below: <\code> let rec append = \ \ function \ \ \ \ \| LNil -\> \ \ \ \ \ \ (function l when (length l + 1) \<= 0 -\> assert false \| l -\> l) \ \ \ \ \| LCons (x, xs) -\> \ \ \ \ \ \ (function l when (length l + 1) \<= 0 -\> assert false \ \ \ \ \ \ \| l -\> LCons (x, append xs l)) One can investigate a modification to the type system so that each datatype is associated with an invariant common to all constructors of the datatype. In case of lists, the shared invariant is that the length of a list is non-negative. In the modified type system, when it becomes determined that a pattern variable's type is a datatype, the corresponding invariant is made available for inference. <\example> Consider the following variant of the example from : <\code> datatype Z datatype S : type datatype List : type * num datacons LNil : >a. List(a, Z) datacons LCons : >a, b. a * List(a, b) > List(a, S b) \; let head = function \ \ \| LCons (x, _) -\> x \ \ \| LNil -\> assert false We introduced the assertion to disallow the overly general type >a, b. List (a, b) > a>, which is the correct most general type for x>, because the type system does not enforce exhaustiveness of pattern matching. The above function has type >a, b. List (a, S b) > a>, but type inference fails to find it. The problem stems from the inability to express disequations \t> in the sort of terms as conjunctions of atoms. We already implemented a workaround in for the case of datatypes with only constant constructors. <\example> In the following variant of the example it turns out to be too hard to infer the full postcondition. <\code> datatype Array : type * num external let array_make : \ \ >n, a [0>n]. Num n > a > Array (a, n) = "fun a b -\ Array.make a b" external let array_get : >n, k, a [0>k > k+1>n]. Array (a, n) > Num k > a = \ \ "fun a b -\ Array.get a b" external let array_length : \ \ >n, a [0>n]. Array (a, n) > Num n = "fun a -\ Array.length a" datatype LinOrder datacons LE : LinOrder datacons GT : LinOrder datacons EQ : LinOrder external let compare : >a. a > a > LinOrder = \ \ "fun a b -\> let c = Pervasives.compare a b in \ \ \ \ \ \ \ \ \ \ \ \ \ \ if c \< 0 then LE else if c \> 0 then GT else EQ" external let equal : >a. a > a > Bool = "fun a b -\ a = b" external let div2 : >n. Num (2 n) > Num n = "fun x -\ x / 2" \; let bsearch key vec = \ \ let rec look key vec lo hi = \ \ \ \ eif lo \= hi then \ \ \ \ \ \ \ \ let m = div2 (hi + lo) in \ \ \ \ \ \ \ \ let x = array_get vec m in \ \ \ \ \ \ \ \ ematch compare key x with \ \ \ \ \ \ \ \ \ \ \| LE -\> look key vec lo (m + (-1)) \ \ \ \ \ \ \ \ \ \ \| GT -\> look key vec (m + 1) hi \ \ \ \ \ \ \ \ \ \ \| EQ -\> eif equal key x then m else -1 \ \ \ \ else -1 in \ \ look key vec 0 (array_length vec + (-1)) \ We get the result type >n[0 > n + 1].Num n> instead of >k[k > n > 0 > k + 1].Num k>. The inference of the intended type succeeds after we introduce an appropriate assertion, e.g. . Alternatively, we can include a use case for where the full postcondition is required. It would be challenging to guess the assertion or use-case automatically. The need to pass options, in examples like the function and the function with assertions, stems from the failure of our search strategy for partial solutions across iterations of the main algorithm (rather than within a single call to abduction). Our search can recover from choices leading to contradictions in the following iteration, but not from choices leading down blind alleys. The problem might be more serious than it appears, because the heuristics (i.e. the default options) have been tuned in favor of our test suite. The solution to the problem is : processing a fixed number of partial solutions, those with highest scores. A score measures heuristically the quality of a partial solution: penalizing complexity, rewarding locality of scope of parameters in an atom, etc. The variant of the program without assertions and with more nesting illustrates a problem with nested definitions introducing existential types. To arrive at the postcondition of the inner definition, we need to propagate information from the use-site of the outer definition. The postconditions are tied in the sense that the postcondition of the outer definition depends on the postcondition of the inner definition. We need to further investigate the issue to see what can be done. In this chapter, we summarize our work in its broader context. Perhaps Xi and Pfenning can be considered the earliest work on GADTs with invariants over a constraint domain; see Section . Its numerical constraint language contains and operations enabling e.g. a concise definition of AVL trees datatype as in Chapter . Its presentation of existential types is similar to ours. opted to automate existential type elimination by : e|)>=>> x=A|)> >> >>y=A|)> >> x y|)>>. Thanks to the modified rule, performing A-translation during the normalization step would make strictly more programs typeable in >>. The DML language from and its successor the ATS language do not perform type inference for recursive functions. We base our type system on the > type system from Simonet and Pottier ; see Section . In the tradition of the Milner-Mycroft type system (see Henglein ), we drop the type specifications on recursive definitions from program terms. We also naturally restrict > by limiting the user-specified and inferred invariant constraints to use conjunction as the only logical connective. We call the resulting type system >. The traditional framework for loop invariant generation of Cousot and Cousot inspired the iterative aspect of our solver. Mycroft's modification in of algorithm > to polymorphic recursion is also iterative, but it solves each recursive definition separately. We solve all nested definitions jointly in a single iteration. Initially we were only aware of the work in Knowles and Flanagan in the framework of , which applies Dijkstra's weakest precondition calculus to general refinement types. An interesting question is whether work similar to ours could be done by application of the weakest precondition calculus to the Hoare logic of Regis-Gianas and Pottier , with the conditions inserted by type inference. Work on by Rondon, Kawaguchi and Jhala is a continuation of this approach closer to in that it does not use weakest precondition calculus explicitly; see Section . by Vazou, Rondon and Jhala is a continuation of Liquid Types in an interesting direction beyond the scope of current , opening an area for future work. Early work on applying abduction to type inference was an inspiration for us. The work by Sulzmann, Schrijvers and Stuckey and closely relates to our work in their application of fully-maximal constraint abduction to GADTs type inference. But without annotations, this would ``throw the baby out with the bathwater'' by rejecting, as not having an intuitive type, for example any variant of that computes for pairs: >a, b. Term a * Term b > Term (a, b)>, >a, b. Term (a, b) > Term a> and >a, b. Term (a, b) > Term b>. The corresponding implications do not have fully maximal answers. and use Herbrandization but solve the resulting constraints in the free algebra of terms, which we find problematic (see Section ). Maher and Maher and Huang introduce fully maximal constraint abduction; see Section . Our algorithm for injective terms with multi-sorted is extensible to any constraint domain, given algorithms for the new domain, as long as the domains do not interact. Allowing the domains to interact would require considerable work, Baader and Schulz might be relevant. Abduction algorithm for the term algebra is provided in , although further work driven by practical issues was needed. The linear arithmetic constraint abduction in Maher turned out not to be useful as a basis for an algorithm, our algorithm is novel. Maher studies constraint domains where a (single) most general Simple Constraint Abduction answer exists, and gives a closed formula for SCA answer for the case of Boolean lattices. The work in Unno and Kobayashi can be seen as extending Knowles and Flanagan with reasoning by Boolean cases. Their programming language and type system is in several ways less expressive than the ML language with polymorphic recursion and the full GADTs type system: no inductive types (and therefore no pattern matching), refinement predicates over integers only instead of over arbitrary domains including types. The recent work of Zhu and Jagannathan (building on Kobayashi, Sato and Unno ) pushes the envelope on both expressiveness and efficiency of inference of a refinement types based approach. It is further developed in Zhu, Nori and Jagannathan , the implementation is called . The work includes features beyond the scope of , for example effect tracking. Wrt. invariant inference, is similar to in that it starts with coarse invariants and refines them. However, rather than deriving the invariants mostly from the definitions they describe, generates test cases to refine the invariants. It still cannot solve, for example, the AVL trees inference task, without assertions in the source code. is slower than , at least for those of the tests reported in which belong to our test suite (Table ). Schrijvers and Bruynooghe shares the objective with our work: softening the learning curve and facilitating rapid prototyping. It reconstructs algebraic data types. An interesting direction of future work would be to reconstruct GADTs using the mechanisms already present in . In fact, reconstructs GADT constructors that serve as existential types. There is a surge of work on type inference for GADTs over the last decade, not contributing to our approach. Works such as Pottier and Régis-Gianas (older), Schrijvers, Peyton Jones, Sulzmann and Vytiniotis , Lin and Sheard (see also ) modify the GADTs type system to make it more amenable to type inference (rejecting some reasonable programs as untypeable), and develop less declarative inference algorithms. These works also do not allow other domains (than the free term algebra) to express invariants, but Schrijvers, Peyton Jones, SulzmannVytiniotis extends the system to arbitrary domains, see Section . and stand out from our point of view as they handle type inference for polymorphic recursion: by iteration, see Section , and using an algorithm by Henglein. from the recent work Dillig, Dillig, Li and McMillan are closely related to fully maximal joint constraint abduction answers. However, employs a richer language of answers, including implications. We decided to limit solved forms, thus preconditions and postconditions, to conjunctions of atoms, to not tax with complexity both algorithms and users. Exploring in context of may be fruitful, by improving on 's abduction algorithm for linear arithmetic. One improvement is to perform quantifier elimination of universal variables (as in ) when they cannot be substituted out. An improvement would be constraint abduction that generates and relations, which in current are only introduced by constraint generalization, but here does not help directly. would gain by incorporating ideas from our abduction algorithm. A related work by Deepak Kapur is part of an interesting research program of Deepak Kapur and Enric Rodrķguez Carbonell, for example , , . generates loop invariants for imperative programs, by quantifier elimination. The variables that are not eliminated are the invariant parameters. In fact, the generated invariant is an abduction answer to the corresponding invariant inference constraint; compare how uses abduction to solve for preconditions. On the other hand, uses constraint generalization, iterating it until convergence. This is in effect how solves for postconditions. and use polynomial equations as the language of invariants. This suggests, as future work, that including in a domain of polynomial equations. In case of the free algebra of terms, constraint generalization reduces to anti-unification. Anti-unification was first introduced by Plotkin and Reynolds . Bulychev, Kostylev and Zakharov is a recent work on anti-unification, with an example application to invariant inference. Our constraint generalization algorithm for linear inequalities has inspirations from Fukuda, LieblingLütolf . Let us collect together proposed directions for future work.\ <\itemize> Implement beam search, where several answers are maintained and inferior answers (less general precondition, less specific postcondition), or answers with worse heuristic score (more complex, etc.), are dropped. Address other issues discussed in Section : handle constraints shared by constructors of a datatype, handle use-site constraint propagation for nested definitions with tied postconditions. Explore extending the >> type system to handle the use of invariants in arguments of higher-order functions, as in Rondon, Kawaguchi and Jhala and especially in abstract refinement types of Vazou, Rondon and Jhala . Work on error reporting for . Trace use-site location and program path location associated with implications, separately; see Zhu and Jagannathan . Integrate with an IDE. Add more constraint domains to . We presented the type inference problem for >, a Milner-Mycroft style variant of the > type system without subtyping, as satisfaction of second order constraints over a multi-sorted domain. We provided a minimal extension >> of this type system that enables inference and easy use of existential types. Although insertions of introduction and elimination of existential types are not automated by the inference process, they are seamlessly integrated into expressions. We demonstrated several use cases using the > system. \ Our Joint Constraint Abduction under Quantifier Prefix algorithm builds on the fully maximal Simple Constraint Abduction answers algorithm from Maher and Huang , extended to guess equalities of parameters. Thanks to aggregating answers during JCA, it can find answers to some cases of joint problems where it would fail to solve some of the implications independently. Our SCA algorithm for linear arithmetic is novel. Consider programs not using the numerical sort. Undecidability of type inference for polymorphic recursion does not enforce an unbounded number of iteration steps of the main algorithm, because there can be infinitely many (maximally general but not fully maximal) term abduction answers. We encountered examples that need two iteration steps: one to generate a solution, and the following step to discard a wrong solution and accept the correct one. However, with numerical sort constraints, a series of programs can be written needing unbounded number of iteration steps. We define the Constraint Generalization problem. In case of free terms it is equivalent to anti-unification and in case of linear equations and inequalities it is equivalent to finding extended convex hull. In the former case, we extend the notion to Abductive Constraint Generalization, providing more specific answers. As we do for abduction, we provide a combination-of-domains algorithm for constraint generalization. We implemented an algorithm solving for predicate variables of the existential second order constraints generated for our type system. It uses abduction to find requirements on invariants, augmented by constraint generalization to find postconditions. The inference times in are sufficient for interactive use with toplevel definitions of small-to-moderate size. <\bibliography|bib|tm-plain|biblio.bib> <\bib-list|61> TilakAgerwalaJayadevMisra. Assertion graphs for verifying and synthesizing programs. , University of Texas Technical Report 83, 1978. LennartAugustsson. Cayenne -- a language with dependent types. , ICFP '98, 239--250. New York, NY, USA, 1998. ACM. FranzBaaderKlaus U.Schulz. Unification in the union of disjoint equational theories: combining decision procedures. , CADE-11, 50--65. London, UK, 1992. Springer-Verlag. SergeyBerezin, VijayGaneshDavid L.Dill. An online proof-producing decision procedure for mixed-integer linear arithmetic. , TACAS'03, 521--536. Berlin, Heidelberg, 2003. Springer-Verlag. EdwinBrady. Idris, a general-purpose dependently typed programming language: design and implementation. , 23:552--593, 9 2013. EdwinBrady, Christoph A.HerrmannKevinHammond. Lightweight invariants with full dependent types. , 161--177. 2008. PeterBulychev, EgorKostylevVladimirZakharov. Anti-unification algorithms and their applications in program analysis. AmirPnueli, IrinaVirbitskaiteAndreiVoronkov, , 5947, 413--423. Springer Berlin / Heidelberg, 2010. JamesCheneyRalfHinze. A lightweight implementation of generics and dynamics. , Haskell '02, 90--104. New York, NY, USA, 2002. ACM. HubertComon. Disunification: a survey. , 322--359. MIT Press, 1991. PatrickCousotRadhiaCousot. Automatic synthesis of optimal invariant assertions: mathematical foundations. , 12(8):1--12, aug 1977. AnatoliDegtyarevAndreiVoronkov. Simultaneous rigid e-unification is undecidable. Hans KleineBüning, , 1092, 178--190. Springer Berlin Heidelberg, 1996. IsilDillig, ThomasDillig, BoyangLiKenMcMillan. Inductive invariant generation via abductive inference. , OOPSLA '13, 443--456. New York, NY, USA, 2013. ACM. CormacFlanagan. Hybrid type checking. , 41(1):245--256, jan 2006. Jeffrey ScottFoster. . PhD dissertation, University of California, Berkeley, Department of Computer Science, December 2002. TimFreemanFrankPfenning. Refinement types for ml (extended abstract). , 268--277. ACM Press, June 1991. KomeiFukuda, Thomas M.LieblingChristineLütolf. Extended convex hull. , 20, 13--23. 2001. SusanneGrafHassenSaļdi. Construction of abstract state graphs with pvs. , CAV '97, 72--83. London, UK, UK, 1997. Springer-Verlag. FritzHenglein. Type inference with polymorphic recursion. , 15(2):253--289, 1993. DeepakKapur. Automatically generating loop invariants using quantifier elimination. FranzBaader, PeterBaumgartner, RobertNieuwenhuisAndreiVoronkov, , 05431Dagstuhl Seminar Proceedings, 10--10. Dagstuhl, Germany, 2006. Internationales Begegnungs- und Forschungszentrum für Informatik (IBFI), Schloss Dagstuhl, Germany. Kenneth W.KnowlesCormacFlanagan. Type reconstruction for general refinement types. , 4421, 505--519. Springer, 2007. NaokiKobayashi, RyosukeSatoHiroshiUnno. Predicate abstraction and cegar for higher-order model checking. , 46, 222--233. ACM, 2011. Chuan-kaiLin. . PhD dissertation, Portland State University, Department of Computer Science, 2010. Chuan-kaiLinTimSheard. Pointwise generalized algebraic data types. , TLDI '10, 51--62. New York, NY, USA, 2010. ACM. KonstantinLäuferMartinOdersky. Polymorphic type inference and abstract data types. , 16(5):1411--1430, sep 1994. MichaelMaher. On parameterized substitutions. , IBM Research Report RC 16042, 1990. MichaelMaher. Abduction of linear arithmetic constraints. MaurizioGabbrielliGopalGupta, , 3668, 174--188. Springer Berlin Heidelberg, 2005. MichaelMaher. Herbrand constraint abduction. , 397--406. Washington, DC, USA, 2005. IEEE Computer Society. MichaelMaher. Heyting domains for constraint abduction. , AI'06, 9--18. Berlin, Heidelberg, 2006. Springer-Verlag. MichaelMaherGeHuang. On computing constraint abduction answers. IlianoCervesato, HelmutVeithAndreiVoronkov, , 5330, 421--435. Springer Berlin / Heidelberg, 2008. PerMartin-Löf. Constructive mathematics and computer programming. , 167--184. Upper Saddle River, NJ, USA, 1985. Prentice-Hall, Inc. Marta CialdeaMayerFioraPirri. First order abduction via tableau and sequent calculi. , 1(1):99--117, 1993. RobinMilner. A theory of type polymorphism in programming. , 17:348--375, 1978. AlanMycroft. Polymorphic type schemes and recursive definitions. , 217--228. London, UK, UK, 1984. Springer-Verlag. MartinOdersky, MartinSulzmannMartinWehr. Type inference with constrained types. . 1997. Gordon D.Plotkin. A note on inductive generalization. , 5:153--163, 1970. FranēoisPottierYannRégis-Gianas. Stratified type inference for generalized algebraic data types. , POPL '06, 232--244. New York, NY, USA, 2006. ACM. John C.Reynolds. Transformational systems and the algebraic structure of atomic formulas. BernardMeltzerDonaldMichie, , 5, 135--151. Edinburgh, Scotland, 1969. Edinburgh University Press. EnricRodrguez-CarbonellDeepakKapur. Program verification using automatic generation of invariants. , 3407, 325--340. Springer-Verlag, 2005. EnricRodriguez-CarbonellDeepakKapur. Generating all polynomial invariants in simple loops. , 42(4):0, 2007. PatrickRondon. . PhD dissertation, University of California, San Diego, Department of Computer Science, 2012. Patrick MaximRondon, MingKawaguchiRanjitJhala. Liquid types. , 159--169. 2008. Patrick MaximRondon, MingKawaguchiRanjitJhala. Liquid types. , 2008. YannRégis-GianasFranēoisPottier. A Hoare logic for call-by-value functional programs. , 5133, 305--335. Springer, JUL 2008. TomSchrijversMauriceBruynooghe. Polymorphic algebraic data type reconstruction. , 85--96. 2006. TomSchrijvers, Simon PeytonJones, MartinSulzmannDimitriosVytiniotis. Complete and decidable type inference for gadts. , ICFP '09, 341--352. New York, NY, USA, 2009. ACM. TimSheard. Languages of the future. , 116--119. ACM Press, 2004. VincentSimonetFranēoisPottier. A constraint-based approach to guarded algebraic data types. , 29(1), JAN 2007. MartinSulzmann, TomSchrijversPeter J.Stuckey. Type inference for GADTs via Herbrand constraint abduction. Manuscript, July 2006. MartinSulzmann, TomSchrijversPeter J.Stuckey. Type inference via constraint abduction for EADTs. Manuscript, April 2006. MartinSulzmann, TomSchrijversPeter J.Stuckey. Type inference for GADTs via Herbrand constraint abduction. , K. U. Leuven Dept. of Computer Science, 2008. Report CW 507. HiroshiUnnoNaokiKobayashi. Dependent type inference with interpolants. , PPDP '09, 277--288. New York, NY, USA, 2009. ACM. NikiVazou, Patrick MaximRondonRanjitJhala. Abstract refinement types. , 209--228. 2013. DimitriosVytiniotis, Simon L. PeytonJones, TomSchrijversMartinSulzmann. Outsidein(x) modular type inference with local assumptions. , 21(4-5):333--412, 2011. HongweiXi. . , Department of Mathematical Sciences, Carnegie Mellon University, December 1998. HongweiXi, ChiyanChenGangChen. Guarded recursive datatype constructors. , POPL '03, 224--235. New York, NY, USA, 2003. ACM. HongweiXiFrankPfenning. Eliminating array bound checking through dependent types. , PLDI '98, 249--257. New York, NY, USA, 1998. ACM. HongweiXiFrankPfenning. Dependent types in practical programming. , 214--227. San Antonio, January 1999. ChristophZenger. Indexed types. , 187(1-2):147--165, nov 1997. HeZhuSureshJagannathan. Compositional and lightweight dependent type inference for ml. RobertoGiacobazzi, JoshBerdineIsabellaMastroeni, , 7737, 295--314. Springer, 2013. HeZhu, Aditya V.NoriSureshJagannathan. Dependent array type inference from tests. DeepakD'Souza, AkashLalKim GuldstrandLarsen, , 8931, 412--430. Springer, January 2015. Bjarte M.Ųstvold. A functional reconstruction of anti-unification. , Norwegian Computing Center, Oslo, Norway, 2004. We work with a first order language > interpreted in a model >, the language of constraints for our type inference problem. We assume that the logic is multi-sorted, but the sorts are combined only via a sort of finite trees, whose leaves can belong to other sorts. I.e., there is a single sort > whose terms can contain subterms from other sorts and for any its terms \ f|\>|)>>g|\>|)>> implies and \s>t>. The sorts ,\> for s> are single-sorted logics and =|\>\>. Let > be an interpretation of types, that is an assignment of elements of > to variables in the corresponding sort, extended homomorphically to terms in the standard way. In the main text, we used rather than > to avoid unnecessary formality. For \\>, let ,\\\> denote the interpretation of a formula > in the model > under the interpretation >, in the standard way, for example ,\\\> if and only if |)>> holds in >, where predicate symbol > in > corresponds to predicate > in >, etc. Of the model > of > we require the following. For the sort of types >: <\enumerate> For any function symbols such that g>, and arbitrary >,>>, there is no interpretation > such that ,\\f>|)>>g>|)>>. For any {\}\|\>> and arbitrary |\>i\ar>,|\>i\ar>>, for any interpretation >, if ,\\f>|)>>f>|)>>, then ,\\\i\ar>s>t>. and every sort is nonempty. Let > be > with: a set of unary predicates |)>>, which stand for invariants of recursive definitions in the constraints we will derive for type inference problems. And a set of binary predicates ,\|)>>, which will be put as constraints of data constructors when we introduce inferred existential types. We call > and > . Let |)>>, resp. |)>> be the set of unary, resp. binary predicate variables in any expression, and |)>=PV|)>\PV|)>>. We define to be existentially quantified conjunctions of atoms |\>.A> without predicate variables. Let ,\> be fixed variables of sort >. <\definition> For a formula >, let |\>=PV|)>>, resp. |\>=PV|)>>, and let ,k>|)>|\>>, resp. ,\|)>|\>> be all occurrences of >, resp. > in >. We call an assignment =|\>\|\>>.F>|\>;|\>\|\>.F|\>|]>> an >> when <\enumerate> |\>.F|\>|\>.F|\>> are solved form formulas, |\>>#FV\,k>|)>> and \|\>#FV\\\|)>>, for every variable \FV>|)>\\\|\>>>, there is a quantifier that binds > at every position of ,k>|)>> in >, |)>\\\|\>>. For an interpretation of predicate variables =|\>\|\>>.F>|\>;|\>\|\>.F|\>|]>>, define the corresponding substitution of predicate variables in a formula > by: <\eqnarray*> >|)>|)>>|||\>>.F>\\>|]>>>|>,\>|)>|)>>|||\>>.F>\\>;\\\>|]>>>|>||a\\>>|.\|)>>||.\|)>\>>|\\|)>>|||)>\\|)>\>>>> Define a statement ,\,\\\> by: > is an interpretation of predicate variables for >, > is an interpretation of types, and ,\\\|)>>. Define ,\\\> as: for all interpretations of types >, ,\,\\\>. Define \\> as: for all interpretations of predicate variables > for >, ,\\\>. Sometimes we write \\>, resp. \>, instead of ,\\\>, resp. \\>, since the model is fixed. We write ,C\\>, resp. \>, for \C\\>, resp. C\\>. We say that a formula > is , if and only if there exists an interpretation of predicate variables > for >, such that \\FV|)>.\>. As seen above, we extend the notion of substitution to handle predicate variable atoms, where the replacement of each occurrence of a variable depends on the argument of that variable. For interpretations of predicate variables ,\> with disjoint domains, we write their composition \|)>=\|)>|)>>. Above we in effect introduce a Henkin semantics for existential second order logic, tailored to our needs of invariant and postcondition inference. Let C> mean here \D\C>. Set \\|\>.\> and \\|\>|]>.\> such that |\>#FV|)>>, |\>#FV|)>> and |\>#C>. Let \\> denote \\|\>.Dom|)>>\>\|)>> when |)>=Dom|)>>, and otherwise a falsehood (compare lemma 3.5 of ). Let \\> denote |\>|\>D|]>.\|\>\>, and |\>|]>\> denote |\>|\>D|]>.\>. <\proposition> Properties of environment fragments (see lemma 3.15). <\description> \\\|\>.\>. \C\|]>\\|]>\>. \\\\\\\>. |\>.\\\\|\>.\|)>\|\>.\|)>>. \\\\\\\\\\>. <\proposition> Constructor \|\>|\>.\\\\\\\|\>|)>> where |\>.A>, is equivalent to \|\>|\>|\>|\>.|\>>|\>\A|]>.\\\\\\\|\>|)>>. <\proposition> Constructors of the form \|\>|\>.\\\\\\\|\>|)>> where |\>.A>, are equivalent to constructors of the form \\|\>|\>|\>.\>\\\\\\A|]>.\\\\\\\|)>> when all uses of ,\,\|)>> are translated to \\\\|)>>. <\lemma> (patterns and expressions). Assume \C>. If \p:\\\> (resp. ,\\e:\>, ,\\e:\>) is derivable, then there exists a derivation of \p:\\\> (resp. ,\\e:\>, ,\\e:\>) of the same structure. The lemma follows from transitivity of > (B> and C> imply C>) by induction on the structure of the derivation. <\lemma> If \\> and p:\\\> (resp. \e:\>, \e:\>) is derivable with constructors >, then the same derivation works with constructors >. <\lemma> (patterns). |\p\\|\>\p:\\|\p\\|\>>. <\proof> By induction on the structure of . <\itemize> Cases , and : follow directly from , and respectively. Case \p>. <\enumerate> By the induction hypothesis, |\p\\|\>\p:\\|\p\\|\>> for . By weakening and we have the goal. Case \p>. <\enumerate> Let \K\\|\>|\>.\\\\\\\|\>|)>>. By the induction hypothesis, |\p\\|\>\p:\\|\p\\|\>> for ,n>. The rule says i D\p:\\\|)>/>C\p:\|\>|)>\\|\>\\\\|)>>, where \|\p\\|\>>. Applying it to (2) we get p:\|\>|)>\\|\>\\\\|)>> as long as D\|\p\\|\>>. Let |\>|\>#FV,\|)>> and \\|\>|\>\|\>|\>|]>,D\D|\>|\>\|\>|\>|]>>. Let > be > with unbound occurrences of |\>|\>> renamed to |\>|\>>. By weakening and , (3) gives |\>|\>>|\>|\>\\|\>|)>>\\C\p:\\\|\>\\\\|)>>. The conjunction of equations |\>|\>>|\>|\>> allows for renaming of the ``old'' variables |\>|\>> by the ``fresh'' variables |\>|\>>. By proposition , transitivity of >, and , we get |\>|\>>|\>|\>\\|\>|)>>\\C\p:\\\|\>|\>|]>\\\\|)>>. By applying to (6) with |\>>|\>\\|\>.D\\|\p\\|\>> and weakening, since w.l.o.g. |\>|\>> do not appear unbound in the goal, and D\|\p\\|\>>, we get the goal |\>.\|\>|)>>\\\|\>.D\\|\p\\|\>\p:\\\|\>|\>|]>\\\\|)>>. Proof of theorem . <\proof> By induction on the structure of . <\itemize> Case is . <\enumerate> If Dom|)>>, then the goal follows by applying . Otherwise, let > be \|\>.D|]>.\>. By , \x:\>. Let |\>#FV,\|)>>. By (1), weakening and , |\>>\|\>\D\\>\,\\x:\>, where \D|\>\\|\>|]>>. By and weakening, since w.l.o.g. |\>> do not appear unbounded in the goal, this implies the goal \|\>.\\>\|)>,\\x:\>. Case is >>>. The goal follows by . Case is >> m\n;e>. <\enumerate> Let \#FV,\|)>>. By the induction hypothesis, we have |\\e:Num|)>|\>,\\e:Num|)>>, |\\e:Num|)>|\>,\\e:Num|)>> and |\\e:\|\>,\\e:\>. By weakening and , this yields |\\e:Num|)>|\>\|\\e:Num|)>|\>\\\\\|\\e:\|\>,\\>> e\e;e:\>. By using (1), this gives the goal. Case is >> e=e;e>. <\enumerate> Let \#FV,\|)>>. By the induction hypothesis, we have |\\e:\|\>,\\e:\>, |\\e:\|\>,\\e:\> and |\\e:\|\>,\\e:\>. By weakening and , this yields |\\e:\|\>\|\\e:\|\>\\>\\|\\e:\|\>,\\>> e=e;e:\>. By using (1), this gives the goal. Case is >> s>. <\enumerate> By the induction hypothesis, we have |\\s:String|\>,\\s:String>. The goal follows from , since |\\>> s:\|\>=|\\s:String|\>>. Case is >> where >=,\,c|)>>. <\enumerate> Let \#FV,\|)>>. Induction hypothesis yelds |\\c:\\\|\>,\\c:\\\>. By (2), weakening and , |\\>:\\\|\>,\\\>:\\\>. By weakening and , (3) implies |\\>:\\\|\>\\\\>\,\\\>:\>. By (1) and , this implies |\\\>:\|\>,\\\>:\>. Case is *e>. <\enumerate> Let #FV,\|)>>. By the induction hypothesis, we have |\\e:\\\|\>,\\e:\\\> and |\\e:\|\>,\\e:\>. By weakening and , this yields |\\e:\\\|\>\|\\e:\|\>,\\e*e:\>. By using (1), |\\e*e:\|\>,\\e*e:\>. Case is *\*e>. <\enumerate> Let \K\\|\>|\>.\\\\\\\|\>|)>>. By induction hypothesis and weakening for each ,n> <\equation*> \|\\e:\|\>\D\\|\>|)>>\,\\e:\ Applying to (1) and (3) we obtain <\equation*> \|\\e:\|\>\D\\|\>|)>>\,\\K*e*\*e:\|\>|)> Let |\>|\>#FV,\|)>> and \\|\>|\>\|\>|\>|]>>, \D|\>\\|\>|]>>. <\equation*> |\>|\>>|\>|\>\|\\e:\|\>\D\\|\>|)>>\,\\K*e*\*e:\|\>|)> By , (1) and weakening, since w.l.o.g. |\>|\>> do not appear unbounded in the goal, |\\K*e*\*e:\|\>,\\K*e*\*e:\>. Case is >> x=e >> e>. <\enumerate> Let \#FV,\|)>> and #PV|)>>. Let =\\|)>|]>.\>, =\\|}>>. By the induction hypothesis, |\\e:\|\>,\\e:\> and |\\e:\|\>,\\e:\>. Let \.|)>\|\\e:\|\>|)>>. Since \|)>> implies |\\e:\|\>>, by weakening of (2), we have \|)>,\\e:\>. From (1) we have #FV,\|)>>, by we have \\.\|)>,\\e:\\|)>|]>.\>, by (1) and renaming we have <\equation*> D\\\.\|)>,\\e:\. By weakening of both (2) and (3), and by , we have |\\>> x=e >> e:\|\>,\\>> x=e >> e:\>. Case is . <\enumerate> > is of the form \\>. Write |\p\\|\>> as |\>\>, where |\>#FV,\,\|)>>. By induction hypothesis, |\\\e:\|\>,\\\e:\>. By lemma and (1), we have |\p\\|\>\p:\\\|\>\>. By instantiation of |\>> and weakening, (2) implies <\equation*> |\\p.e:\|\>\D,\\\e:\ By weakening, (3) implies |\\p.e:\|\>\p:\\\|\>\>. By (4), (5), (1), and , we obtain |\\p.e:\|\>,\\p.e:\>. Case is >> \m\n.e> and >>\\\e\\\\.>>|)>|)>>. <\enumerate> Let |\>\|\>#FV,\,\|)>>. Recall that |\\p >> \m\n.e:\\\|\>=\\|\>.\>, for =|\p\\|\>\\|\>.D\\|\\\m:Num|)>|\>\|\\\n:Num|)>|\>\\\\\|\\\e:\|\>|)>>. > is of the form \\>. Write |\p\\|\>> as |\>\>. By induction hypothesis, |\\\e:\|\>,\\\e:\>, and also |\\\m:Num|)>|\>,\\\m:Num|)>> and |\\\n:Num|)>|\>,\\\n:Num|)>>. By lemma and (1), we have |\p\\|\>\p:\\\|\>\>. By instantiation of |\>> and weakening, (3) implies <\eqnarray*> \D\\\\,\\>|>|>>|\D,\\>|>|:Num|)>>>|\D,\\>|>|:Num|)>>>>> By weakening, (4) implies \p:\\\|\>\>. By (5), (6), (1), and , we obtain ,\\p >> \m\n.e:\>. By (7) and , we get the goal. Case is >> \m\n.e> and >>\\\e=\\\.>>|)>|)>>. The proof is nearly identical to above. <\enumerate> Let |\>\|\>#FV,\,\|)>>. Recall that |\\p >> \m\n.e:\\\|\>=\\\|\>.\>, for =|\p\\|\>\\|\>.D\\|\\\m:Num|)>|\>\|\\\n:Num|)>|\>\>\\\\\\|\\\e:\|\>|)>>. > is of the form \\>. Write |\p\\|\>> as |\>\>. By induction hypothesis, |\\\e:\|\>,\\\e:\>, and also |\\\m:Num|)>|\>,\\\m:Num|)>> and |\\\n:Num|)>|\>,\\\n:Num|)>>. By lemma and (1), we have |\p\\|\>\p:\\\|\>\>. By instantiation of |\>> and weakening, (3) implies <\eqnarray*> \D\\>\\\\\,\\>|>|>>|\D,\\>|>|:Num|)>>>|\D,\\>|>|:Num|)>>>>> By weakening, (4) implies \p:\\\|\>\>. By (5), (6), (1), and , we obtain ,\\p >> \m\n.e:\>. By (7) and , we get the goal. >\> stands for x\Dom|)>\Dom|)>.\>\> and is false when |)>\Dom|)>>. Recall that for \\|\>.\> and \\|\>|]>.\> such that |\>#FV|)>>, |\>#FV|)>> and |\>#C>, \\\> denotes D\\|\>.D\\>\>. Observe, that \\\> iff \|\>.D\\|\>.D\\>\>. <\lemma> (patterns). Let =\|\>|]>\> and |\p\\|\>=\|\>|]>\=\>. p:\\\> implies |\p\\|\>> and \|\>.D\\|\>.\\>\|)>>, i.e. \\\>. <\proof> By induction on the derivation of p:\\\>. To slightly simplify the proof, the induction is actually on the lexicographic ordering: (# of applications of , # of other rules applications). <\itemize> Cases , , . |\p\\|\>=\>. |\p\\|\>> and > coincide: =\>, =D=\> and \|\>.\>\> holds because sorts are nonempty. Case . In this case =\\\,|\>=|\>|\>,D=D\D,\=\|\>\>. <\enumerate> 's premises are p:\\\>, which by induction hypothesis gives |\p\\|\>> and \|\>.D\\|\>.\\>\|)>> for . (1) gives |\p\p\\||\>|\>> as |\p\p\\|=|\p\\|\>\|\p\\|\>|\>|\>>. |\p\p\\|=|\p\\|\|\p\\|=\|\>|\>\D|]>\|\>\|\>|\>|\>|\>|\>|\>>. We will show \|\>|\>.D\D\\|\>|\>.\D\\|\>\>\|\>\|)>>. Assume w.l.o.g. |\>#|\>>, |\>#|\>>. Applying (1) for gives \|\>|\>.D\D\\|\>|\>.\D\\>\\\>\|)>>, which completes the goal. Case . In this case =\|\>|]>\\\\|)>>, and =\|\>|)>>, where \D|\>|\>\|\>|\>|]>> for \K\\|\>|\>|]>.\\\\\\\|\>|)>> and |\>#FV>. <\enumerate> 's premises are D\p:\|\>|\>\|\>|\>|]>\\>. Let |\>|\>#FV,|\>|\>,|\>|\>,C|)>>. Let \\|\>|\>\|\>|\>|]>>. By weakening and , (1) gives D\|\>|\>>|\>|\>\p:\\\>. By induction hypothesis we have D\|\>|\>>|\>|\>\|\p\\|\>> and D\|\>|\>>|\>|\>\\|\>.D\\|\>.\\>\|)>> for ,n>. Let \D|\>|\>\|\>|\>|]>>. From (4) follows |\>|\>>|\>|\>\D\\|\p\\|\>>. W.l.o.g. |\>|\>#FV\\|\p\\|\>|)>>. (5) gives |\>>|\>\\|\>.D\\|\p\\|\>> because we can drop |\>>|\>> from premises. (6) is equivalent to |\>>|\>\\|\>|)>>\|\>|)>\\|\>.D\\|p\\|\>> which by the nonempty domain property implies |\>>|\>\\|\>.\|\>|)>>\|\>|)>\\|\>.D\\|\p\\|\>>. Because by (6) we can drop |\>>|\>> from premises, (7) is equivalent to \|\>.\|\>|)>>\|\>|)>\\|\>.D\\|\p\\|\>>, which is the first part of the goal. From (4), |\>|\>>|\>|\>\D\\|\>\|\>.\D\\|\>\|\>.\\\>\|)>>. From (9) by (2) and (6), \|\>|\>.|\>|\>>|\>|\>\D\\|\>\|\>.\D\\|\>\|\>.\\\>\|)>>, which is equivalent to <\equation*> C\\|\>|\>|\>\|\>.|\>|\>>|\>|\>\D\D\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ >\|\>\|\>.\\\>\|)> Observe, that w.l.o.g. |\>\|\>|\>|\>\|\>>. Note by definition of |\p\\|\>>, that =\|\>|)>>\|\>|)>\D\D>. By the free generation property, D\|\>>|\>>. Observe, that >\\\>\|)>> and =D\D>. (10) and (11) imply <\equation*> C\\|\>.|\>>|\>\D\\|\>\|\>.D\\>\ Also, |\>=|\>|\>\|\>>. Because |\>#FV|)>>, because sorts are nonempty (12) gives \|\>.|\>>|\>\D\\|\>.D\\>\>, the other part of the goal. Case . <\enumerate> 's premises are: p:\\\>, which by induction hypothesis gives |\p\\|\>> and \\\>, for =\|\>|]>\> and \>\>. Observe by induction on , that \>\\|\p\\|\>> iff \>\\|\p\\|\>>, which by (1) and (2) gives the first part of the goal. Observe by induction on , that \>\\|\p\\|\>\|\p\\|\>>, i.e. \>\\\\\>, which by (1), (2) and transitivity of >, proves the second part of the goal. Case follows by transitivity of >. Case . <\enumerate> 's premises are \p:\\\> and |\>#FV,\|)>> for |\>.C>. By inductive hypothesis, \|\p\\|\>> and \\\\>. By induction on , |\p\\|\>|)>=FV|)>>. By (1), (2) and (3) we have |\p\\|\>>. By induction on , ,\|)>\FV|)>\|\>>. By (1), (2) and (3) we have \\\>. <\lemma> Let > be an environment and ,\> be simple (i.e. monomorphic) environments. For any >, \>\,\\\e:\> iff \>\,\\\e:\>. <\proof> Consider a derivation of \>\,\\\e:\>. The only case where > is referred to, is in the rule, which for a monomorphic environment simplifies to: =\/C,\\\x:\>. Replace > with > in judgments throughout the derivation. =\/C\\>\,\\\x:\> is not valid, correct it as =\/C\\>\,\\\x:\/C\\>\,\\\x:\>. Analogically follows the other direction of the equivalence of \>\,\\\e:\> and \>\,\\\e:\>. Proof of theorem . <\proof> We proceed by induction on the derivation of \e:\>. To slightly simplify the proof, the induction is actually on the lexicographic ordering: (# of structural rule applications , , , , , ; # of nonstructural rule applications , , , ). (The rules and are not needed when deriving the syntax-directed rules.) <\itemize> Case . <\enumerate> 's first premise is =\\|\>.D|]>.\>. 's second premise is D>. The goal is: ,C\\\|\>.|\>\\|\>|]>\\>\|)>>, where w.l.o.g. |\>#FV,\,\,|\>|)>>. (3) follows from (2) by instantiating > to >, because we assume that all sorts in > are non-empty. We can take an empty interpretation =\>. Case . 's premise is \>, we have the goal from \\\> holding for any >, and transitivity of >. Case . <\enumerate> 's premises are \e:Num|)>>, \e:Num|)>>, \\\> and \e:\>. Pick w.l.o.g. \\FV,\,\,\|)>>. By rule , (1) implies \>\\\>\,\\e:Num|)>>, \>\\\>\,\\e:Num|)>> and \e:\>. By induction hypothesis and weakening, (2) implies ,C\\>\\\>\\\\\\\> for =|\\e:Num|)>|\>>, , =|\\e:\|\>>. By (2) and nonemptiness of sorts, we have \\\.\>\\\>\\\\\|)>>. By (3), the premise and because D> implies \.C\\\.D>, we have \\,\\\.\>\\\>\\\\\|)>\\\.\\\\|)>>. By (4) and (5), we have the goal ,C\|\\>> e\e;e:\|\>> with =\\\>. Case . <\enumerate> 's premises are \e:\> for =\> and \>\>. Pick w.l.o.g. \\FV,\,\,\|)>>. By rule , (1) implies \>\\\>\,\\e:\> for . By induction hypothesis and weakening, (1) and (2) imply ,C\\>\\\>\\\>\\\> for =|\\e:\|\>>, , =|\\e:\|\>>. By (2) and nonemptiness of sorts, we have \\\.\>\\\>\\\>\|)>>. By (3), the premise and because D> implies \.C\\\.D>, we have \\,\\\.\>\\\>\\\>\|)>\\\.\\\\|)>>. By (4) and (5), we have the goal ,C\|\\>> e=e;e:\|\>> with =\\\>. Case . <\enumerate> 's premise is \s:String>. By induction hypothesis, (1) implies ,C\|\\s:String|\>> and thus the goal. Case . <\enumerate> 's premises are \e:\>, ,n>, D> and \|\>|\>.\\\\\|\>|)>>. =\|\>|)>>. Let w.l.o.g. |\>|\>#FV,\|)>>. By weakening and , (1) gives |\>|\>>|\>|\>,\\e:\|\>|\>\|\>|\>|]>>. Let =|\\e:\|\>|\>\|\>|\>|]>|\>>. By induction hypothesis, ,C\|\>|\>>|\>|\>\\>, ,n>. Observe, that (1) and (3) imply ,C\|\>|\>>|\>|\>\\\\D|\>|\>\|\>|\>|]>\\|\>|)>>\|\>|)>>. By non-emptiness of sorts and because the premise |)>=\> gives disjoint domains for the >, (4) and (2) imply \\,C\\|\>|\>.\\\D|\>|\>\|\>|\>|]>\\|\>|)>>\|\>|)>>. By (1) and (5), ,C\|\\K e\e:\|\>> for =\\\>. Case . In this case, \\\\>. <\enumerate> ' premise is \>:\\\>, which by induction hypothesis implies ,C\\> for =|\\p.e:\\\|\>>, ,n>. Let \#FV,\|)>>. Then, because sorts are nonempty, \\\.\>\\\>\|)>>. (1) and the premise implies \,C\\>\\\>\\\\\\\\>\\\>. Combining (2) and (3), \,C\\\\.\\\\\>\\\|)>>. By (1) and (4), \,C\|\\\>:\|\>>. Case . <\enumerate> 's premises are \e:\\\> and \e:\>. Pick w.l.o.g. \FV,\,\|)>>. By rule , (1) implies \>\,\\e:\\\> and \>\,\\e:\>. By induction hypothesis, (2) implies ,C\\>\\\> for =|\\e:\|\>>, \\\\,\\\>. By (2) and nonemptiness of sorts, we have \\.\>\|)>>. By (3), the premise and because D> implies \.C\\\.D>, we have \,\\.\>\|)>\\\.\\|)>>. By (4) and (5), we have the goal ,C\|\\e e:\|\>> with =\\>. Case . Let \\\|}>>. <\enumerate> 's premises are \e:\>, which can only be derived by from \D,\\e:\>, where =\\|\>.D|]>.\> and \\\|\>.D>; by induction hypothesis we get ,C\D\\> for =|\\e:\|\>>; and \e:\>; by induction hypothesis we get ,C\\> for =|\\e:\|\>>. |\>#FV,C|)>>. W.l.o.g., assume additionally that |\>#FV|)>>. ,C\\\.|\>.D|)>\\> iff ,C\|\>.D|)>\\> iff ,C\\|\>.D\\> iff ,C\D\\> iff ,C\D\\>, which is exactly (1). ,C\\\|\>.D\\\.|\>.D|)>\\> follows from (5), ,C\\\|\>.D\\\.\|\>.D>, and ,C\\> is exactly (2). From (4), (5) and the premise, \,C\\.|\>.D|)>\\|)>\\.\|\>.D|)>\\>. Let =\\;\\\|\>.D\\|]>>, where #PV,\,\|)>>. (6) gives ,C\\.\|)>\\|)>\\.\|)>|)>\\>, which is ,C\|\\>> x=e >> e:\|\>>. Case . <\enumerate> 's premises are: p:\\\|\>\>, D\\>\\>,\\\e:\>, D,\\\m:Num>|)>> and D,\\\n:Num>|)>>, and |\>#FV,\|)>>. Assume w.l.o.g. that |\>#FV|)>>. Let \#FV,\,>,\>|\>|)>>. Let |\p\\|\>=\|\>|]>\>, where |\>#FV,C,\,\,|\>|)>>. By lemma , (1) and (7) gives |\p\\|\>> and \|\>.D\\|\>.D\\>\>, which is equivalent to D\\|\>.D\\>\>. Recall that |\\p >> \m\n.e:\\\|\>=\\|\>.\>, for =|\p\\|\>\\|\>.D\\|\\\m:Num|)>|\>\|\\\n:Num|)>|\>\\\\\|\\\e:\|\>|)>>. By lemma , weakening and , (3) implies D\\>\\\>\>,\\\m:Num|)>> and D\\>\\\>\>,\\\n:Num|)>>. From (9) we have D\\>\>\\|\>.D\\>\\\>\>> and D\\>\>\\|\>.D\\>\\\>\>> for some >,\>>. By (11), and (12), we get D\\>\>,\\\m:Num|)>> and D\\>\>,\\\n:Num|)>>. By induction hypothesis applied to (13) we have ,C\D\\>\>\|\\\m:Num|)>|\>> and ,C\D\\>\>\|\\\n:Num|)>|\>>. By lemma and weakening, (2) implies D\\>\\\>\>\\>\>\\\\,\\\e:\>. By (15), and (12), we get D\\>\>\\>\>\\\\,\\\e:\>. By induction hypothesis, (16) gives ,C\D\\>\>\\>\>\\\\\|\\\e:\|\>>. By (8), (10), (14) and (17), we get |\>|\>\,C\\>\>\\>\>\\>. By nonemptiness of the domain, from (18) we get the goal |\>|\>\,C\\\|\>.\>. Case . The proof is nearly identical as above. <\enumerate> 's premises are: p:\\\|\>\>, D\\>\\\>\\>,\\\e:\>, D,\\\m:Num>|)>> and D,\\\n:Num>|)>>, and |\>#FV,\|)>>. Assume w.l.o.g. that |\>#FV|)>>. Let \\#FV,\,\,>,\>|\>|)>>. Let |\p\\|\>=\|\>|]>\>, where |\>#FV,C,\,\,\,|\>|)>>. By lemma , (1) and (7) gives |\p\\|\>> and \|\>.D\\|\>.D\\>\>, which is equivalent to D\\|\>.D\\>\>. Recall that |\\p >> \m\n.e:\\\|\>=\\\|\>.\>, for =|\p\\|\>\\|\>.D\\|\\\m:Num|)>|\>\|\\\n:Num|)>|\>\>\\\\\\|\\\e:\|\>|)>>. By lemma , weakening and , (3) implies D\\>\\\>\>,\\\m:Num|)>> and D\\>\\\>\>,\\\n:Num|)>>. From (9) we have D\\>\>\\|\>.D\\>\\\>\>> and D\\>\>\\|\>.D\\>\\\>\>> for some >,\>>. By (11), and (12), we get D\\>\>,\\\m:Num|)>> and D\\>\>,\\\n:Num|)>>. By induction hypothesis applied to (13) we have ,C\D\\>\>\|\\\m:Num|)>|\>> and ,C\D\\>\>\|\\\n:Num|)>|\>>. By lemma and weakening, (2) implies D\\>\\\>\\\>\>\\>\>\\>\\\\\,\\\e:\>. By (15), and (12), we get D\\>\\\>\>\\>\>\\>\\\\\,\\\e:\>. By induction hypothesis, (16) gives ,C\D\\>\\\>\>\\>\>\\>\\\\\\|\\\e:\|\>>. By (8), (10), (14) and (17), we get |\>|\>\,C\\>\\\>\>\\>\>\\>. By nonemptiness of the domains, from (18) we get the goal |\>|\>\,C\\\\|\>.\>. Case . The proof is nearly identical as above. <\enumerate> 's premises are: p:\\\|\>\>, D\\>\\\>\\>,\\\s:String>, D,\\\m:Num>|)>> and D,\\\n:Num>|)>>, and |\>#FV|)>>. Assume w.l.o.g. that |\>#FV|)>>. Let \\#FV,\,>,\>|\>|)>>. Let |\p\\|\>=\|\>|]>\>, where |\>#FV,C,\,\,|\>|)>>. By lemma , (1) and (7) gives |\p\\|\>> and \|\>.D\\|\>.D\\>\>, which is equivalent to D\\|\>.D\\>\>. Recall that |\\p >> \m\n.e:\\\|\>=\\\|\>.\>, for =|\p\\|\>\\|\>.D\\|\\\m:Num|)>|\>\|\\\n:Num|)>|\>\>\\\\\\|\\\e:\|\>|)>>. By lemma , weakening and , (3) implies D\\>\\\>\>,\\\m:Num|)>> and D\\>\\\>\>,\\\n:Num|)>>. From (9) we have D\\>\>\\|\>.D\\>\\\>\>> and D\\>\>\\|\>.D\\>\\\>\>> for some >,\>>. By (11), and (12), we get D\\>\>,\\\m:Num|)>> and D\\>\>,\\\n:Num|)>>. By induction hypothesis applied to (13) we have ,C\D\\>\>\|\\\m:Num|)>|\>> and ,C\D\\>\>\|\\\n:Num|)>|\>>. By lemma and weakening, (2) implies D\\>\\\>\\\>\>\\>\>\\>\\\\\,\\\s:String>. By (15), and (12), we get D\\>\\\>\>\\>\>\\>\\\\\,\\\s:String>. By induction hypothesis, (16) gives ,C\D\\>\\\>\>\\>\>\\>\\\\\\|\\\s:String|\>>. By (8), (10), (14) and (17), we get |\>|\>\,C\\>\\\>\>\\>\>\\>. By nonemptiness of the domains, from (18) we get the goal |\>|\>\,C\\\\|\>.\>. Case . <\enumerate> 's premises are \e:\>, which by induction hypothesis gives ,C\|\\e:\|\>>, and \>\>. Let >\|\\e:\|\>>. Observe, that > occurs in >> only as a subterm in a side of equation: >\>, >\\\>, >\\\|)>\|)>>. Therefore, >\\\>\\>>. (1), (2) and (3) imply that ,C\|\\e:\|\>>. Case . <\enumerate> 's premises are \e:\>, that by induction hypothesis gives ,C\|\\e:\|\>>, and |\>#FV,\|)>>. By (2), w.l.o.g. |\>#FV|\\e:\|\>|)>>. (1) implies that \\|\>.\|)>> which by (3) is equivalent to ,\|\>.C\|\\e:\|\>>. Case . ,\\\> holds for any >. Case . <\enumerate> premises are \e:\> and \e:\>. Induction hypothesis gives ,C\|\\e:\|\>> and ,D\|\\e:\|\>> for some interpretations of predicate variables ,\>. Therefore, we have ,C\D\|\\e:\|\>>, for both =\> and =\>. Proof of corollary . <\proof> \e:\|\>.\> can only be derived by the rule, therefore we have \D,\\e:\> for |\>#FV,C|)>> and \\|\>.D>. By theorem , there exists an interpretation > such that ,C\D\|\\e:\|\>>. ,C\D\|\\e:\|\>> iff \C\D\|\\e:\|\>> iff \\|\>.C\D\|\\e:\|\>> iff ,C\\|\>.D\|\\e:\|\>>. Therefore ,C\\|\>.D\|\\e:\|\>>. Proof of theorem . <\proof> By inspecting Table , note that e> subexpressions are absent from >. Thus > is empty in all cases other than . We therefore shorten these cases by not mentioning > and >. Below we extend the inductive proofs with the cases for expressions introduced by, or rule applications of, , and . <\itemize> Theorem (Correctness) |\,\\e:\|\>,\,\\e:\>. Case: \\>. <\enumerate> Induction hypothesis states |\,\\n:\|\>,\,\\n:\>. The goal follows by . Theorem (Correctness) Case: is >> p=e >> e>. <\enumerate> Induction hypothesis yields |\\K p.e:\\\|\>,\\K p.e:\\\>, |\\p.e:\\\|\>,\\p.e:\\\> and |\\e:\|\>,\\e:\>. By weakening, (1), and , we get |\\e:\|\>\|\\p.e:\\\|\>\|)>,\\\|)>e:\>. By we get |\\e:\|\>\|\\K p.e:\\\|\>,\\>> p=e >> e:\>, and by : |\\e:\|\>\|\\p.e:\\\|\>\|)>,\\>> p=e >> e:\>. By (3) and we get \ |\\e:\|\>\|\\p.e:\\\|\>\|)>|)>\>|\\e:\|\>\|\\K p.e:\\\|\>|)>,\\>> p=e >> e:\> for =K\\|\>|\>.\\\|\>|)>|}>>. By (4), weakening and , we get the goal. Theorem (Correctness) Case: is e>. <\enumerate> Let #FV,\|)>>. By the induction hypothesis, we have |\\e:\\\|\>,\\e:\\\> and |\\e:\|\>,\\e:\>. By weakening and , this yields |\\e:\\\|\>\|\\e:\|\>\|)>,\\e*e:\>. By using (1), |\\e*e:\|\>,\\e*e:\>. Theorem (Correctness) Case: is >>. <\enumerate> Let ,\#FV,\|)>>. By the induction hypothesis, we have |\\\>:\|\>,\\\>:\>. By weakening, , and , we have |\\\>:\|\>\RetType,\|)>\\\.\>\|)>,\\\>:\>. By weakening, this yields the goal. Theorem (Completeness) Case : premise ,\\n:\> for |)>\\Dom|)>=\>. <\enumerate> By induction hypothesis we have ,C\|\,\\n:\|\>>. Let =\\\\,\|)>|]>.\\\|)>|\>>. The goal is ,C\\|\,\\n:\|\>|)>|\>|)>|\>\|\>|)>|\>|]>>. The goal follows by setting =\/\>. Theorem (Completeness) Case . <\enumerate> 's premises are \e:\\\>, \e:\> and |)>>. Pick w.l.o.g. \FV,\,\|)>>. (1) implies \>\\|)>>. By rule , (1) implies \>\,\\e:\\\> and \>\,\\e:\>. By induction hypothesis, (2) implies ,C\\>\\\> for =|\\e:\|\>>, \\\\,\\\>. By (2) and nonemptiness of sorts, we have \\.\>\|)>>. By (2), (3), and because D> implies \.C\\\.D>, we have \,\\.\>\|)>\\\.\\\|)>|)>>. By (4) and (5), we have the goal ,C\|\\e e:\|\>> with =\\>. Theorem (Completeness) Case : premise \>> p=e >> e:\>. <\enumerate> 's premise is: \\|)> e:\>, derived by and from \p.e:\\\>, \e:\> and |)>>. Inductive hypothesis gives ,C\|\\p.e:\\\|\>> and ,C\|\\e:\|\>>. (1) and (3) imply ,C\|\\p.e:\\\|\>\|)>\>|\\K p.e:\\\|\>> as the first disjunct holds. As the premise |)>=\> gives disjoint domains for the >, we have ,C\|\\e:\|\>\|\\p.e:\\\|\>\|)>\>|\\K p.e:\\\|\>|)>> for =\\>. ,C\\\.|\\e:\|\>\|\\p.e:\\\|\>\|)>\>|\\K p.e:\\\|\>|)>> by abstracting =\>. Theorem (Completeness) Case :premise \>> p=e >> e:\>. <\enumerate> 's premises are: \K p.e:\\\> and \e:\>, Inductive hypothesis gives ,C\|\\K p.e:\\\|\>> and ,C\|\\e:\|\>>. (3) implies ,C\|\\p.e:\\\|\>\|)>\>|\\K p.e:\\\|\>> as one of the >> disjuncts holds. The proof concludes as in the case. Theorem (Completeness) Case : premise \\>:\>. <\enumerate> 's premises are: \\>:\> and RetType,\|\>|)>|)>>. Inductive hypothesis gives ,C\|\\\>:\|\>>. Let ,\#FV,\|)>>. (1b) and (2) give ,C\\\.|\\\>:\|\>\RetType,\|)>\\\.\>\|)>\\>|\>>. Let =|)>\\>|\>|]>>. By (3), \,C\\\.RetType,\|)>\\.\>\|)>\\|)>|)>\|\\\>:\|\>> which is the goal. >> By induction on the structure of the derivation, we can show the following: <\proposition> Let > be an interpretation of predicate variables for formula , as in Definition . If a typing judgment ,\\e:\> is derivable in the type system >>, then ,\|)>,\|)>\e:\> is derivable in >>. Proof of Theorem . <\proof> Let > be a subsitution of predicate variables such that ,\\\FV|)>.|\,\\e:\|\>>. By Theorems and , there exists a derivation of |\,\\e:\|\>,\,\\e:\>. Without loss of generality, let be the rule applied at the root of the derivation, and let > be the derivation of the premise |\,\\e:\|\>,\,\\n:\>. Let =\|)>>, |\,\\e:\|\>|)>> and =\|)>>. By Proposition , there exists a derivation > of ,\\e:\>. We need to construct a derivation > of ,\\e:\> under constructor environment > in the > type system. The tag erasure of > w.r.t. > has to be computationally equivalent to the HMG-form of and > has to be satisfiable. We will transform > into a derivation in > while preserving these conditions. We transform the resulting constraint, the resulting expression and the derivation simultaneously, as follows: <\itemize> For a derivation node applying rule , we erase the |)>> condition in the premise of the node, and we erase |)>> in the corresponding |\\e e:\|\>> part of the resulting constraint, where ,\> etc. name the actual pieces of the derivation or constraint. For a derivation node , with .e|\>|)>> in conclusion, we erase derivation subtrees with or nodes at the root. Correspondingly, we replace the expression in the conclusion by .e|)>|\>unreach|)>\failure|)>>|)>>, which preserves computational equivalence; and we erase the |\\p.e:\\\|\>> conjuncts of the resulting constraint for |)>\failure|)>>, which leads to a weaker formula and thus preserves satisfiability. We replace derivation nodes by applications of the rule to the premises \|)> e:\\\> and \e:\>, and replace the corresponding subexpressions >> p=e >> e> of the resulting expression by |)> e>. We replace the |\\>> p=e >> e:\|\>> part of the resulting constraint by \.|\\e:\|\>\|\\K p.e:\\\|\>>. To see that the satisfiability of the constraint is preserved, recall that |\\>> p=e >> e:\|\>> is a disjunction where only one disjunct is consistent with |\>.\>\|\>|)>>. The tag erasure of |)> e> w.r.t. the original constructor environment > is computationally equivalent to >> p=e >> e>. We excise derivation nodes , and remove the corresponding atom from , preserving computational equivalence and satisfiability. For remaining nodes are easy to rearrange into applications of the corresponding > rules. Proof of Corollary . <\proof> The semantics of expression in >> is given by the semantics of its HMG-form in >. By well-typedness and closedness, we have ,\\e:\> is derivable for some type scheme >, and \C>. By Theorems and , there exists an interpretation of predicate variables > such that ,\\C\|\,\\e:\|\>>, thus ,\\|\,\\e:\|\>>. By Theorem , we have an > environment >, constructor environment > and an expression > such that \e:\> is derivable in > for a valid , and the tag erasure of > w.r.t. > is computationally equivalent to the HMG-form of . By Theorem 3.31, see also Theorem , > does not go wrong. Given the call-by-value semantics presented in , it is easy to see that the tag erasure of > does not go wrong. By computational equivalence, HMG-form of does not go wrong. <\proposition> . Let |\>=Dom|)>> be all variables occurring on the left-hand sides of solved form equations >, and \FV(Image|)>> be a variable occurring on the right-hand side. If \.C> (equivalently .\>) holds, then \.C\\|]>> (equivalently \.\\\|]>>), for any > such that for all \FV|)>>, \>\>. <\lemma> For any conjunction of atoms \>>, let > be with all alien subterms >> replaced with fresh variables |\>>, \\>. Let D=\|)>> be a solved form with \\>. Observe that for any >, for any \>, if \D\\\C>, then <\enumerate> \D|\>\>|]>\\\C> for s>. For >, let C=\|)>>, where > is with all alien subterms >> replaced with fresh variables |\>>. Then there exist a conjunction of equations over |\>|\>> such that D>\E\\\C>> and (for s>) \D|\>\>|]>\\\|\>> |\>\E> where > are \>. The proof uses the and (> properties) and interpolation techniques. Below follows a sketch of a proof of (2). <\proof> Observe a proof of |\>\>|]>\\\C|\>\>|]>> (assuming a complete proof system for \>). It can be transformed into a proof of \\\|\>>>\|\>>>\C>. By > properties we get >\\\E\|\>>>\|\>>>\C>> where > are equations among |\>>. By interpolation we get >\E\\\C>> and \\\|\>>>\|\>>>\E> for \E> and as required by the theorem, since |\>> are the only non-> subterms of >>. Proof of Theorem . <\proof> We use the same notation as in Table . Note, that the JCAQP with a branch with unsatisfiable conclusion does not have an answer, \ so we do not consider unsatisfiable conclusions. Observe that validity of > formula in is equivalent to its validity in >. We will therefore sometimes drop prefixes \> and > for readability. Let us check correctness, i.e. that |\>.A\Abd,|\>,,C|\>|)>> are JCAQP>> answers. <\enumerate> We need to show: \\\A\C|)>>, \\.A|\>|\>\>|]>> for some >>, \\\FV\A|)>.D\A>, for all atoms A> such that \\.c> and \|\>\\>, then for all \FV> such that \|)>\\>, there exists \FV\|\>> such that \>\>. We have: \\>\A\C>|)>>, \\.A|\>|\>|\>|\>\>|]>> for some >>, \\\FV>\A|)>.D>\A>, for all atoms >t\A> such that \|\>|\>|\>>, if \FV> such that \|)>\\>, then \>\>. We have: \\\\A|)>|\>|\>\>|\>|]>\A>\C\\A|)>|\>|\>\>|\>|]>|)>>, \\.A>>|\>|\>|\>\>>|]>> for some >>>, \\\FV\\A|)>|\>|\>\>|\>|]>\A>|)>.D\\A|)>|\>|\>\>|\>|]>\A>>, for all atoms A>> such that \\.c> and \|\>\\>, then for all \FV> such that \|)>\\>, there exists \FV\|\>> such that \>\>. We have: \\D> and \\C>; |\>|\>\>|\>|]>=D>>, |\>|\>\>|\>|]>=C>>; =>t\\>\A|)>\|x\X,s\s|}>> and =>t\\>\C>\A|)>\|x\X,s\s|}>>, =\A>, where \\>. \|\>>>|\>\\D\D>, C\C\|\>>>|\>\C>, by (13). We have: =A\usorts>A>> for some |\>> and |\>=|\>>|\>|\>\FV\A>|)>>, >|\>|\>> is a concatenation of >|\>> for usorts>. By type preservation and free generation, (5) we can have >\A\C>>, where >> differs from >> only at alien subterm positions. Pick >> which differs from >> on the least number of alien subterm positions. Consider >t\\>\C>|)>\|x\X,s\s|}>>. Note that C>\C>>. By (16) and separation of sorts, we have >\C>\A|)>\\\>\\>\C>|)>\\\>>, i.e. \S>. \A\>|\>>|\>|\>|>D>\D\D|\>|\>\>|\>|]>\A\s>A>\>|\>>|\>|\>> |>D>\A\s>C\C>|\>\|\>|]>\A|\>|\>\>|\>|]>\>|\>>|\>|\>> |>C>\s>C\C>|\>\|\>|]>\>|\>>|\>|\>|>C>. (19)-(21) and interpolation give the goal (1). From type preservation and free generation properties (as in Proposition ), by (6) we get \\.A|\>|\>\X>|)>\>;|\>\\X>|)>\>;|\>|\>\>|]>> for some >>, for all >,>>. Since > are single-sorted for s>, by (15), (23) and (10) we get the goal (2). Similarly, from (3), (7), type preservation and free generation properties, and because > are single-sorted for s>, we get the goal (3). Consider A> such that \\.c> and \|\>\\>, and a \FV> such that \|)>\\>. If \|\>>, then =\> satisfies the goal (4). Consider the cases where \|\>>. Consider \X>>. By (26) \\.c>. By (6) -- or (24) -- \\.c|\>|\>\>|]>> for some >>. By (15), is in solved form >t>. By (28)-(30), \|\>>. By (8) we have the goal (4) for case \X>>. Consider \X> for s>. Because > are single-sorted for s>, by (15) we have A>>. From (12) we have the goal (4). Now we sketch a proof of completeness, i.e. that no JCAQP answer ``falls through''. <\enumerate> We need to show that for any JCAQP .\\C|)>> with parameters |\>> answer |\>.A>, there is an |\>.A\Abd,|\>,,C|\>|)>> and >> such that A|\>\>|]>>. Let \A> where > has atoms of sort only. Let > be a formula obtained from >> by substituting all alien subterms >> of sorts other than > by fresh variables |\>>. Let A=\|)>> be solved form of > with \\>. W.l.o.g., all ,D> are satisfiable. Observe, that D\A\C> implies, by lemma , that there is a conjunction of equations over variables >|\>|\>>: \\s>A>, such that: <\enumerate> \A\>|\>|\>>|\>>\A>, >\A>\A\C>>, \D>|\>\|\>|]>\A\A|\>\>|]>\C\C>|\>\|\>|]>> for s>. (3b) and the assumption about > give that for some |\>.A|)>\Abd,|\>,>,C>|\>|)>>, >\A\A|\>\|\>|]>> for some |\>>. (3a), (3c) and lemma imply, by substituting free variables, \D>|\>\|\>|]>\A\A|\>\>|]>\C\C>|\>\|\>|]>\A|\>|\>|\>\>|\>>|]>>. To use the assumption about >, we weaken (5). With a stronger premise, we also get a stronger conclusion: \\A\A|)>|\>|\>\>|\>|]>\A\A|\>\>|]>\C\\A|)>>|\>\|\>|]>\A|\>|\>|\>\>|\>>|]>>. (6) gives by the assumption about >: \\A|)>|\>|\>\>|\>|]>\A\A|\>\>|]>\A>>|\>\>|\>|]>> for some > and >|\>>. Check using (3b) and (4) that >\A\>|\>|\>>|\>>\\|\>.A|\>\|\>|]>\\\A|)>|\>|\>\>|\>|]>>. The subtraction in \\A|)>> allows us to drop >> from the premise in (3b). Select |\>.A\\|\>>|\>.A|\>|\>\>|\>|]>\A>> for |\>>|\>\|\>|\>>|\>|\>\FV|\>\>|]>\A>|)>>. By (7) and (8), we have |\>|\>|\>>>|\>>|]>\A|\>|\>>|\>|\>\|\>>>|\>|\>|]>> for some >>, which implies (1). <\proposition> Let \\> for all sorts such that >=\>|)>>, and >\\>> for \s>. Then \D|)>\C>> if and only if \D>\C>>. <\proposition> MGU: \C\\>. <\proposition> Let be a conjunction of equations with >, let be a conjunction of equations and |\>> variables such that \|\>\FV>. \D\\|\>.A> if and only if there exists a substitution |\>\>|\>|]>> and a solved form \A> with =\|)>> such that for every >t\A>, either =S>, or >S\D>. Proof of Theorem . <\proof> First, we show \\\\|\>.A|)>>. <\enumerate> \D\D\D\c>, for each conjunct A>>. <\enumerate> Case >g>. By properties of MGU. Case D> follows from \D\D>>. Case D>. The premises are: >t\D,y>t\D,\\D\t>t>. The goal follows from \D\D\D>, by transitivity.\ By properties of >, we have D\D\D\\|\>.A> for s>, and therefore D\D\D\\|\>.A>. We have D\\|\>.D\D>, and by properties of most specific anti-unification, D\\|\>|\>.D\D>. Collecting the above points, we get D\\|\>|\>|\>.\A>. Now, we sketch a proof of: For every |\>.A> such that \\\\|\>.A|)>>, with variables renamed so that |\>#FV|)>>, \A\\|\>.A>. <\enumerate> The assumption is \\\\|\>.A|)>>. By definition, \D\D\\s>D\D\D>. Let |\>.A\\|\>|\>.\\|\>.D\A> where |\>.A\\>, >> are all alien subterms of sort in >, |\>> are fresh variables |\>#FV,|\>|)>> and also all alien subterms in >>, >=\>|)>>, and =|\>>>> for s>, >=\>. By Proposition , for each branch there is a substitution > of |\>|\>|\>>> that is an anti-unifier of |\>>, for all \|\>|\>|\>>> such that >u\A>>, where ,|\>\V> and \D\t>t>. > can be made equal to > up to a variable-variable substitution. <\itemize> I.e. a substitution |\>\|\>|]>> that can assign the same > to several >. There exists a substitution > which establishes \A>\\|\>|\>.\|\>>.>u|\>>: by variable-variable substitution, including alien subterm variables, according to \D\t>t>, and by the factoring via most specific anti-unification. Let |\>.A=LUB\|~>\D|)>|\>|)>> as in the definition of |)>>. \D\\|\>.A> by (1), \D\D\D\\|\>.A> by weakening on the left, \D\D\D\\|\>|\>.\\|\>.D\A> by (3), \D\D\D\\|\>.A> by weakening on the right, \D\D\D\D\\|\>.A> by (2) and Proposition . By (6), (7), interpolation and assumption about >, \A\\|\>.A> for every s>. More specifically, we need \A\A>\\|\>.A\\|\>|)>>|\>>. It can be shown by extending the argument for (8) using the fact that > relates |\>|)>> introduced in (5) to the remaining constraints of branch . In this section, we provide proof sketches for correctness and a limited form of completeness of the type inference implemented in , correctness with respect to the type system >> and the limited form of completeness wrt. >. <\lemma> Let ,|\>,A,|\>>.A>|\>|)>\Split,|\>,A,|\>>|\>|)>>. Then: <\enumerate> \A\>A>\A>. \A\\|\>>|\>.A\>A>>. \\.A|\>\>|]>>>. If only restricts |\>>> in ways that are expressible as \>>\|\>>|\>>.\> for some |\>>>, and \\.A|\>|\>>|\>\>|]>> for some >>, then ,|\>,A,|\>>|\>|)>\\>. preserves atomized form: if |\>.A> is in atomized form with respect to > and parameters |\>>|\>>, then |\>.A> is in atomized form with respect to > and parameters |\>>|\>>|\>>. <\proof> Recall the definition of and the notation used there. (1) and (2) follow from the observation that >\A>\A>> and >\\|\>>|\>.A>\A>>. (3) follows from \\.\>A>|)>|\>\>|]>> for some >> because >|\>>=\> and =A\\>A>>, in the last iteration. For (4) to hold the algorithm should at each recursion level be able to find >|\>> for which \\.\>A>|)>|\>\>|]>>> and >,|\>>|)>> does not return > for any >, where > and |\>>> are either the initial arguments or the recursive call arguments. The algorithm terminates because |\>> always decreases in the recursive call. >> contains restrictions on the variables |\>>>. If >,|\>>|)>> returns >, then, because >> is in atomized form, >> restricts |\>>> in a way not expressible as \>>\|\>>|\>>.\>. The final remark follows from the minimality of >|\>> w.r.t. inclusion. <\lemma> Let \\>, |\>>.F>|\>> and |\>>.F>|\>>. Let |)>|)>=\.\\C|)>=\.\\\>. Let |\>.F,S,R|)>\\,S,R|)>> for any . Let <\equation*> \.\=NF*S*R*S|)>|)> Then \F\\>> and \\.F|\>\>|]>> for some >>. <\proof> We use the notation from the definition of >, with =S,R=R,\=\>. We have <\equation*> \|\>.A\Abd,>|\>>|\>,,C|\>|)> and therefore \\\A\C|)>>. Continuing the definition of >, we have <\equation*> ,|\>,A,|\>>>.A>>|\>|)>\Split,|\>,A,>|\>>|\>|)> and |)>=\|\>,k>.Simpl|\>>>|\>.F>\A>>>|\>>|\>\|\>,k>|\>|]>|)>>, =A>. Therefore by Lemma point 1, \F\>>A>>\A>, and by Lemma point 3, the goal \\.F|\>\>|]>>>. It remains to show \F\\>>. Observe that \>>A>>\\\>U>|)>>. (1) is \A\\\>U>>. But \>A>>\A> by (2), so (1) and (4) give (3). Sketch of proof of Theorem . <\proof> Lemma gives the goal ,\\\> with \ |)>\\.\>, because *R=S*R> implies >>A>>=\>. <\axiom> (Interpolation property for >.) We assume that for conjunctions of atoms and any quantifier-free formula >, \A\\> implies that there is a conjunction of atoms with \FV\FV|)>>, \A\B> and \B\\>. <\lemma> Let |)>|\>\|\>>.F>\\|]>|\>|]>|)>=\.\> and |)>=PV|)>>. Let <\equation*> \>.\>=NF>|)>|\>\|\>>|\>>>.>\F>|)>\\>|]>|\>;|)>|\>\|\>>.F>\\|]>|\>|]>|)> for variables |\>>>|\>> and conjunctions of atoms >|\>\\> such that the JCAQP>> problem >.\>> has a solution. Assume that in the definition of > is a complete abduction algorithm returning an atomized form formula. Then there is ,|\>>.F>|\>|)>\\,|\>>.F>|\>|)>> such that <\equation*> \\\>\>>\>>\F>|)>|)>|\>>|\>\>|]> for all >, for some >>. <\proof> Let |\>.D> be a solution to the JCAQP>> problem >.\>>. We have \D\>\>>\\>. By the completeness assumption about , we have \D\>\>>\A|\>|\>>|\>\>|]>> for some >>. Since > does not participate in restricting |\>>|\>> and >>> is limited to \>>|\>>|\>>>> variables, by atomized form of |\>.A> and interpolation, we get the expressiveness constraint needed for Lemma point 4, therefore ,|\>,A,|\>>|\>|)>\\>. Thus by Lemma point 2, \D\>\>>\|\>>|\>>>\\|\>>|\>.A\>A>> where by definition of >, >=F>\F>>. Since the atomized form is preserved by (Lemma point 5), we have the goal. Sketch of proof of Theorem . <\proof> The thesis \\>F>\>F>|)>|\>,k>|\>\>|]>> is true for . Assume it holds for arbitrary . We need to show \\>F>\\>|]>\>F>\\>|]>|)>|\>,k+1>|\>\>|]>> for some ,|\>,k+1>.F>|\>|)>> and a substitution of variables |\>,k+1>|\>>. By the assumption that |\>=PV|)>=PV|)>>, definition of > gives >=F>\A>>. We will apply Lemma with >=F>> and >=F>>. By the inductive assumption, JCAQP>> answer |\>.F> to |)>|\>\|\>>.F>\\|]>|\>|]>|)>> is also an answer to >.\>>. By Lemma , we get the goal. We inject the existential type and value constructors during parsing for user-provided existential types, and during constraint generation for inferred existential types, into the list of toplevel items. It facilitates exporting inference results as OCaml source code. Toplevel definitions are intended as boundaries for constraint solving. This way the programmer can decompose functions that could be too complex for the solver. A toplevel only binds a single identifier, while binds variables in a pattern. To preserve the flexibility of expression-level pattern matching, for -- unless it just binds a value as discussed above -- we pack the constraints |\\p\\|\>> which the pattern makes available, into existential types. Each pattern variable is a separate entry to the global environment, therefore the connection between them is lost. The > syntax has two uses: binding values of existential types means ``eliminating the quantification'' -- the programmer has control over the scope of the existential constraint. The second use is if the value is not of existential type, the constraint is replaced by one that would be generated for a pattern matching branch. This recovers the common use of the ... syntax, with exception of polymorphic cases, where needs to be used. \ We optimize the disjunctive constraint coming from bindings as follows. Rather than inspecting in > directly, let |\\K x\\|\>=\|\>\|}>>. |\\K p.e:\\\|\>> is equivalent to, or at least implied by: <\equation*> |\\K p\\|\>\\|\>.D\|\\p.e:\\\|\> Let us set =|)>>, =|\\K p\\|\>>, =\>\> and =\>\\D>. Then, <\equation*> \\.|\\e:\|\>\|\\p.e:\\\|\>\|)>\>|\\K p.e:\\\|\>|)> is equivalent to: <\equation*> \\.|\\e:\|\>\\\\>\\|\>\.\|\\p.e:\\\|\>|)>|)> We use the same variable > across disjuncts of the same disjunction, so that |\\p.e:\\\|\>> can be derived and simplified only once. The second argument of the predicate variable ,\|)>\> provides an ``escape route'' for free variables, i.e. precondition variables used in postcondition. In the implementation, we have user-defined existential types with explicit constraints in addition to inferred existential types. We expand the inferred existential types after they are solved into the fuller format. In the inferred form, the result type has a single parameter >, without loss of generality because the actual parameters are passed as a tuple type. In the full format we recover after inference, we extract the parameters >|\>|)>>, the non-local variables of the existential type, and the partially abstract type >\>, and store them separately, i.e. |\>|)>=\|\>\|\>.\>. The variables |\>> are instantiated whenever the constructor is used. For a toplevel , we form existential types after solving the generated constraint, to have less intermediate variables in them. Both during parsing and during inference, we inject new structure items to the program, which capture the existential types. During printing existential types in concrete syntax i:|\>|]>.t> for an occurrence >|)>|)>>, the variables |\>> coming from >|\>|)>\\> are substituted-out by |\>\>|]>>. For simplicity, only toplevel definitions accept type and invariant annotations from the user. The constraints are modified according to the |\,\\ce:\|\>.\|\>> rule. Where > uses a fresh variable >, a toplevel incorporates the type from the annotation. The annotation is considered partial, becomes part of the constraint generated for the recursive function but more constraints will be added if needed. The polymorphism of |\>> variables from the annotation is preserved since they are universally quantified in the generated constraint. The constraints solver returns three components: the , which implies the constraint when the predicate variables are instantiated, and the solutions to unary and binary predicate variables. The residue and the predicate variable solutions are separated into part, which is a substitution, and remaining constraints (which are currently limited to linear inequalities). To get a predicate variable solution we look for the predicate variable identifier association and apply it to one or two type variable identifiers, which will instantiate the parameters of the predicate variable. We considered several ways to deal with multiple solutions: <\enumerate> report a failure to the user; ask the user for decision; silently pick one solution, if the wrong one is picked the subsequent program might fail; perform backtracking search for the first solution that satisfies the subsequent program. We use approach 3 as it is simplest to implement. Traditional type inference workflow rules out approach 2, approach 4 is computationally too expensive. We might use approach 1 in a future version of the system. Upon ``multiple solutions'' failure -- or currently, when a wrong type or invariant is picked -- the user can add clauses (e.g. stating that a program branch is impossible), and clauses. The clauses are boolean expressions with operational semantics of run-time tests: the test clauses are executed right after the definition is executed, and run-time error is reported when a clause returns . The constraints from test clauses are included in the constraint for the toplevel definition, thus propagate more efficiently than backtracking would. The clauses are: which translates as equality of types of and , which translates as , and = e2>, which translates as inequality \n> assuming that has type and has type . We treat a chain of single branch functions with only in the body of the last function specially. We put all information about the type of the functions in the premise of the generated constraint. Therefore the user can use them to exclude unintended types. See the example . We reduce the constraint to alternation-minimizing prenex-normal form, as in the formalization. We return a variable comparison function. The branches we return from normalization have unified conclusions, since we need to unify for solving disjunctions anyway. Releasing constraints \ from under disjunctions is done iteratively, somewhat similar to how disjunction would be treated in constraint solvers. Releasing the sub-constraints is essential for eliminating cases of further disjunction constraints. When at the end more than one disjunct remains, we assume it is the traditional rule and select its disjunct. When one > expression is a branch of another > expression, the corresponding branch does not introduce a disjunction constraint -- the case is settled syntactically to be the same existential type. The unsolved constraints are particularly weak with regard to variables constrained by predicate variables. We need to propagate which existential type to select for result type of recursive functions, if any. Normalization starts by flattening constraints into implications with conjunctions of atoms as premises and conclusions, and disjunctions with disjuncts and additional information. The additional information kept with a disjunct is the conjunction of atoms that hold together with the disjunction. We try to eliminate disjuncts by using unification to check for contradiction. If only one disjunct is left, or we decide to pick anyway (when no progress can be made otherwise), we return the disjunct. Otherwise we return the filtered disjunction. To help eliminate unintended disjuncts, we collect information about existential return types of recursive definitions by: <\enumerate> solving the conclusion of a branch together with additional conclusions, to know the return types of variables, registering existential return types for all variables in the substitution, registering existential return types for all first arguments and their substitution instances, traversing the premise and conclusion to find new variables that are types of recursive definitions, registering as ``type of recursive definition'' the return types for all variables in the substitution registered as types of recursive definitions, traversing all variables known to be types of recursive definitions, and registering existential type with recursive definition (i.e. unary predicate variable) if it has been learned, traversing all variables known to be types of recursive definitions again, and registering existential type of the recursive definition (if any) with the variable. During normalization, we remove from a nested premise the atoms it is conjoined with (as in ``modus ponens''). After normalization, we simplify the constraints by removing redundant atoms. We remove atoms that bind variables not occurring anywhere else in the constraint, and in case of atoms not in premises, not universally quantified. The simplification step is not currently proven correct and might need refining. We merge implications with the same premise, unless one of them is non-recursive and the other is recursive. We call an implication branch recursive when an unary predicate variable > (not a >) appears in the conclusion a binary predicate variable > appears in the premise. Our formal specification of abduction provides a scheme for combining sorts that substitutes number sort subterms from type sort terms with variables, so that a single-sort term abduction algorithm can be called. Since we implement term abduction over the multisorted datatype , we keep these in terms passed to term abduction. Here we expand on the overview from Section . The JCAQPAS problem is more complex than simply substituting alien subterms with variables and performing joint constraint abduction on resulting implications. The ability to ``outsource'' constraints to the alien sorts enables more general answers to the target sort, in our case the term algebra >. Term abduction will offer answers that cannot be extended to multisort answers. One might mitigate the problem by preserving the joint abduction for terms algorithm, and after a solution |\>.A> is found, ``'' the alien subterms (including variables) in as follows. We replace every alien subterm > in (including variables, even parameters) with a fresh variable >, which results in > (in particular |\>\|\>|]>=A>). Subsets \A=A\>n|\>> such that |\>|\>.A,,A|\>> is a JCAQPAS answer will be recovered automatically by a residuum-finding process after abduction for terms ends. This process is needed regardless of the ``dissociation'' issue, to uncover the full content of numeric sort constraints. To face efficiency of numerical abduction with many variables, we modify the approach. On the first iteration of the main algorithm, we remove (purge) alien subterms both from the branches and from the answer, but we do not perform other-sort abduction at all. On the next iteration, we do not purge alien subterms, neither from the branches nor from the answer, as we expect the dissociation in the partial solutions (to predicate variables) from the first step to be sufficient. Other-sort abduction algorithms now have less work, because only a fraction of alien subterm variables > remain in the partial solutions (see main algorithm in section ). They also have more information to work with, present in the instatiation of partial solutions. However, this optimization violates completeness guarantees of the combination of sorts algorithm. To faciliate finding term abduction solutions that hold under the quantifiers, we substitute-out other sort variables, by variables more to the left in the quantifier, using equations from the premise. The dissociation interacts with the discard list mechanism. Since dissociation introduces fresh variables, no answers with alien subterms would be syntactically identical. When checking whether a partial answer should be discarded, in case alien subterm dissociation is , we ignore alien sort subterms in the comparison. Here we expand on the overview from Section . We further lose generality by using a heuristic search scheme instead of testing all combinations of simple abduction answers. In particular, our search scheme returns from joint abduction for types with a single answer, which eliminates deeper interaction between the sort of types and other sorts. Some amount of interaction is provided by the validation procedure, which checks for consistency of the partial answer, the premise and the conclusion of each branch, including consistency for other sorts. We accumulate simple abduction answers into the partial abduction answer, we set aside branches that do not have any answer satisfiable with the partial answer so far. After all branches have been tried and the partial answer is not an empty conjunction (i.e. not >), we retry the set-aside branches. If during the retry, any of the set-aside branches fails, we add the partial answer to discarded answers -- which are avoided during simple abduction -- and restart. Restart puts the set-aside branches to be tried first. If, when left with set-aside branches only, the partial answer is an empty conjunction, i.e. all the answer-contributing branches have been set aside, we fail -- return > from the joint abduction. This does not peform complete backtracking (no completeness guarantee), but is therefore quicker to report unsolvable cases and does sufficient backtracking. After an answer working for all branches has been found, we perform additional check, which encapsulates negative constraints introduced by the construct. If the check fails, we add the answer to discarded answers and repeat the search. If a partial answer becomes as strong as one of the discarded answers inside SCA, simple constraint abduction skips to find a different answer. The discarded answers are initialized with a discard list passed from the main algorithm. To check validity of answers, we use a modified variant of unification under quantifiers: unification with parameters, where the parameters do not interact with the quantifiers and thus can be freely used and eliminated. Note that to compute conjunction of the candidate answer with a premise, unification does not check for validity under quantifiers. Because it would be difficult to track other sort constraints while updating the partial answer, we discard numeric sort constraints in simple abduction algorithm, and recover them after the final answer for terms (i.e. for the type sort) is found. Searching for an abduction answer can fail in only one way: we have set aside all the branches that could contribute to the answer. It is difficult to pin-point the culprit. We remember which branch caused the restart when the number of set-aside branches was the smallest. The conclusion of that branch can be used to construct the error report. Here we expand on the overview from Section . Our initial implementation of simple constraint abduction for terms follows p. 13. The mentioned algorithm only gives which is loss of generality w.r.t. our requirements. To solve C> the algorithm starts with C|)>> and iteratively replaces subterms by fresh variables \|\>> for a final solution |\>.A>. As our primary approach to mitigate some of the limitations of fully maximal answers, we start from C|)>|)>>, where |\>.A> is the solution to previous problems solved by the joint abduction algorithm, and |)>> is the corresponding substitution. Moreover, motivated by examples from Chuan-kai Lin , we intruduce variable-variable equations >\>, for \\|\>>, not implied by C|)>>, as additional candidate answer atoms. During abduction ,|\>,,C|\>|)>>, we ensure that the (partial as well as final) answer |\>.A> satisfies \.A|\>|\>\>|]>> for some >>. We achieve this by normalizing the answer using parameterized unification under quantifiers |\>|\>>.A|)>>. |\>> are the parameters of the invariants. In fact, when performing unification, we check more than |\>|\>>.A|)>> requires. We also ensure that the use of parameters will not cause problems in the phase of the main algorithm. To this effect, we forbid substitution of a variable > from |\>> with a term containing a universally quantified variable that is not in |\>> and to the right of > in >. Also, we forbid substitution of a variable > from |\>>> with a term containing a variable \|\>>> for \\>. In implementing p. 13, we follow a top-down approach where bigger subterms are abstracted first -- replaced by a fresh variable, \ together with an arbitrary selection of other occurrences of the subterm. If dropping the candidate atom maintains \A\D\C>, we proceed to neighboring subterm or next equation. Otherwise, we try all of: replacing the subterm by the fresh variable; proceeding to subterms of the subterm; preserving the subterm; replacing the subterm by variables corresponding to earlier occurrences of the subterm. This results in a single, branching pass over all subterms considered. Finally, we clean-up the solution by eliminating fresh variables when possible (i.e. substituting-out equations >\> for variable and fresh variable >). Although there could be an infinite number of abduction answers, there is always a finite number of answers, or more generally, a finite number of equivalence classes of formulas strictly stronger than a given conjunction of equations in the domain >. We use a search scheme that tests as soon as possible. The simple abduction algorithm takes a partial solution -- a conjunction of candidate solutions for some other branches -- and checks if the solution being generated is satisfiable together with the candidate partial solution. The algorithm also takes several indicators to let it select the expected answer: <\itemize> a number that determines how many correct solutions to skip; a validation procedure that checks whether the partial answer meets a condition, in joint abduction the condition is consistency with premise and conclusion of each branch; the parameters and candidates for parameters of the invariants, |\>>, updated as we add new atoms to the partial answer; existential variables that are not to the left of parameters and are connected to parameters become parameters; we process atoms containing parameters first; the quantifier > (source ) so that the partial answer |\>.A> (source ) can be checked for validity with parameters: \.A|\>\>|]>> for some >>; a discard list of partial answers to avoid (a tabu list) -- implements backtracking, with answers from abductions raising ``fallback'' going there. Since an atom can be mistakenly discarded when some variable could be considered an invariant parameter but is not at the time, we process atoms incident with candidates for invariant parameters first. A variable becomes a candidate for a parameter if there is a parameter that depends on it. That is, we process atoms >t> such that |\>> first, and if equation >t> is added to the partial solution, we add to |\>> existential variables in . Note that >t> can stand for either t>, or x> for . For a universally quantified variable |\>>, t> will not be part of the answer as it does not hold under the quantifier. To simplify the search in presence of a quantifier prefix, we preprocess the initial candidate by eliminating universally quantified variables: <\eqnarray*> |||\>\|\>|]>FV|)>\|\>\\,\|\>\\\\D\>,>>|>||>\|\>|]>>\|\>,\|\>\\\\D\C\>,>>|>,|\>,D,C|)>>||c=x>t\C,x=Sc=Sc=S*S|}>>>>> Note that above is a substitution of subterms rather than of variables. To move further beyond fully maximal answers, we incorporate candidates >\> for which the following conditions hold: \\|\>>, \t\\C|)>|)>>, \t\\C|)>|)>> and >t> is satisfiable. We also need to include the unifier of >t> among the candidates, since otherwise the equation >\> would not suffice to imply that of the atoms >t>, >t> which belongs to the conclusion . The C|)>|)>> and the \\;\>t|)>|\>> are kept apart, the guess candidates are guessed before the full candidates. By default, we additionally limit consideration to atoms >t>, >t> where ,t> are not themselves variables. To recapitulate, the implementation is: <\itemize> If there are no more candidates to add to the partial solution: check for repeated answers, skipping, and discarded answers. If there are no more guessed candidates, pick the next full candidate atom \|\>\\> if any, reordering the candidates until one is found. Otherwise, pick the first guess candidate atom without reordering. The are 6 mutually exclusive choices through which the algorithm loops. <\enumerate> Try to drop the atom (if the partial answer plus remaining candidates can still be completed to a correct answer). Replace the current subterm of the atom with a fresh parameter, adding the subterm to replacements; if at the root of the atom, check connected and validate before proceeding to remaining candidates. Step into subterms of the current subterm, if any, and if at the sort of types. Keep the current part of the atom unchanged; if at the root of the atom, check connected and validate before proceeding to remaining candidates. Replace the current subterm with a parameter introduced for an earlier occurrence; branch over all matching parameters; if at the root of the atom, check connected and validate before proceeding to remaining candidates. Keep a variant of the original atom, but with constants substituted-out by variable-constant equations from the premise. Redundant, not available when the option is on. Each iteration is a backtracking point, the choices are tried in turn, depending on options selected. Default ordering of choices is 1, 6, 2, 4, 3, 5 -- pushing 4 up minimizes the amount of branching in 5. <\itemize> There is an option , which reorders the choices to: 1, 6, 4, 2, 3, 5; however the option is not exposed in the interface because the cost of this reordering is prohibitive. An option reorders the choices to: 6, 1, 2, 4, 3, 5; it does not increase computational cost but sometimes leads to answers that are not most general. If choice 6 would lead to more negative constraints contradicted than choice 1, we pick choice 6 first for a particular candidate atom. An option reorders choice 6 prior to choice 1, but only for guess candidates. Form initial candidates >,|\>,\A|)>,\\D\C|)>|)>>. Form the substitution of subterms for choice-6 counterparts of initial candidate atoms. For >\,\,\>\\\A|)>>, form the substitution of subterms \\,\,\\\,\\\> (excluding \\>) where > is the most upstream existential variable (or parameter) and > is a constant. Note that analogous transformation for a universally quantified variable as right-hand-sides is performed by >>. <\itemize> Since for efficiency reasons we do not always remove alien subterms, we need to mitigate the problem of alien subterm variables causing violation of the quantifier prefix. To this effect, we include the premise equations from other sorts in the process generating the initial candidates and choice 6 candidates, but not as candidates. Not to lose generality of answer, we only keep a renaming substitution, in particular we try to eliminate universal variables. Sort the initial candidates by decreasing size, because shorter answer atoms are more valuable and dropping a candidate from participating in an answer is the first choice. <\itemize> There is an argument in favor of sorting by increasing size: so that the replacements of step 2 are formed at a root position before they are used in step 5 -- instead of forming a replacement at a subterm, and using it in step 5 at a root. If ordering in increasing size turns out to be necessary, a workaround should be introduced to favor answers that, if possible, do not have parameters |\>> as left-hand-sides. The above ordering of choices ensures that more general answers are tried first. Moreover: <\itemize> choice 1 could be dropped as it is equivalent to choice 2 applied on the root term; choices 4 and 5 could be reordered but having choice 4 as soon as possible is important for efficiency. We perform a two-layer iterative deepening (when without the option): in the first run we only try choices 1 and 6. It is an imperfect optimization since the running time gets longer whenever choices 2-5 are needed. We implement an optional heuristic in forming the candidates proposed by choice 6. It may lead to better invariants when multiple maximally general types are possible, but also it may lead to getting the most general type without the need for backtracking across iterations of the main algorithm, which unfortunately often takes very long. We look at the types of substitutions for the variables that are invariant parameters, in the partial answer, and try to form the initial candidates for choice 6 so that the return type variables cover the most of argument types variables, for each term substituted for an invariant parameter. We select from the candidates equations between any variable, or only non-argument-type variable, and a |)>\\FV|)>> variable -- we turn the equation so that the latter is the RHS. We locate the equations among the candidates that have an invariant parameter variable or a |)>\\FV|)>> variable as LHS. We apply the substitution to the RHS of these equations; if the LHS is an invariant parameter, we use the substitution based on equations where one side is a non-argument-type variable. We preserve the order of equations in the candidate list. Here we expand on the overview from Section . For checking validity or satisfiability, we use . To avoid complexities we only handle the rational number domain. To extend the algorithm to integers, procedure as presented in needs to be adapted. The major operations are: <\itemize> of a variable takes an equation and selects a variable that is not upstream, i.e. to the left in > regarding alternations, of any other variable of the equation, and substitutes-out this variable from the rest of the constraint. The solved form contains an equation for this variable. of a variable takes a variable that is not upstream of any other variable in the unsolved part of the constraint, and reduces all inequalities containing to the form |\>a> or |\>x>, depending on whether the coefficient of is positive or negative. For each such pair of inequalities: if , we add >a> to implicit equalities; otherwise, we add the inequality |\>a> to the unsolved part of the constraint. We use elimination to solve all equations before we proceed to inequalities. The starting point of our algorithm is section . We add detection of implicit equalities, and more online treatment of equations, introducing known inequalities on eliminated variables to the projection process. When implicit equalities have been found, we iterate the process to normalize them as well. Our abduction algorithm follows a familiar incrementally-generate-and-test scheme as in term abduction. There are two new ideas, which can also be applied to abduction in other domains. We build a lazy list of possible transformations with linear combinations involving equations implied by C>. We pair each inequality in with all inequalities implied by which share a variable with and try out the abduction answers to c> as contributions to the partial abduction answer to C>. To simplify the search in presence of a quantifier prefix, we preprocess the initial candidate by eliminating universally quantified variables: <\eqnarray*> |||\>\|\>|]>\|\>\\\\D\>,>>|>,|\>,D,C|)>>||c\C,\\\.c|\>\>|]>>c=cc=S|}>>>>> Before accepting a new atom into the partial answer, we check that it would not violate the quantifier conditions from the phase of the main algorithm, and that the partial answer is satisfiable with all implication branches of the joint abduction problem. As part of the quantifier conditions, we ensure that the escaping parameters are upward in the constraint before prenexization, i.e. are parameters of the type of a parent definition (containing a given definition in its body) rather than a parallel definition. The check of satisfiability we call . For domains other than the term domain, validation also involves instantiating use-sites of recursive definitions with parts of the partial answer, split in a simplified way. Abduction algorithm: <\enumerate> Let =|~>|)>>, resp. >=|~>>|)>> where >, resp. >> are the equations, resp. inequalities in and |~>> is the substitution according to equations in >. Let =|~>A|)>> and > be the equations in >, i.e. substituted equations and implicit equalities. Let >> be a solved form of inequalities. <\enumerate> Let =Rev>,|\>,D,C|)>> and >=Rev>,|\>,D,C>|)>>. Prepare the initial transformations from atoms D>: <\enumerate> Add combinations *a+b> for n,s=-1,1> to the stack of transformations to be tried for atoms . The final transformations have the form: b+\D>k>a>. Modify > to promote answers with variables rather than constants, as in term abduction: For >\,\,\>\\C>, form the substitution of subterms \\,\,\\\,\\\> (excluding \\>) where > is the most upstream existential variable (or parameter) and > is a constant. Start from > and \C\C>>. Handle atoms in =a C>, equations first. Let \D\C\Acc>. If is a tautology (>0> or 0> for 0>) or C>, repeat with \C>. Corresponds to choice 1 of term abduction. If C>, for a candidate > generated for , starting with , which passes validation against other branches in a joint problem: Acc\|}>>, or fail if all > fail. <\enumerate> If is an inequality, let > be an abduction answer to Rev>,|\>,D,|~>|)>>, where belongs to the solved form inequalities implied by >. Otherwise, let =|~>>. Sort the candidates > in order of decreasing value, described below. Let > be > with some >-derived transformation applied. <\itemize> We increase the value of > for each variable that is bound by > on the side that it is unbound in . We decrease the value of > for: <\itemize> its size, proportionally to the sum of nominators and denominators, containing a constant term, containing parameters from multiple invariants, introducing an implicit equality, binding a variable by a constant on the side where it is already bounded by , binding a variable by a constant on the right (i.e. upper bound), optionally, being less general than some other candidate, modulo , we include the value of inequalities implied by the candidate together with the partial answer (but not the partial answer alone) and not holding when parameters are universally quantified (see ). The score determines the order in which atoms are tried. Currently, we do not perform transformations when > is an inequality, for simplicity and speed at cost of missing some answers. However, we eliminate the universal variables, i.e. we use >> above. If it proves necessary, we will also try the transformations for the inequalities. For example, by trying all candidates > before proceeding to the next transformation. If \|}>|)>> (resp. \|}>|)>>) does not pass validation for all >, backtrack. If \|}>|)>> (resp. \|}>|)>>) passes validation, repeat from step 5 with \C,Acc\Acc\|}>> (resp. Acc\|}>>). The answers are =A\Acc>. We precompute the tranformation variants to try out. The parameter is set by option num_abduction_rotations> and defaults to a small value (currently 3). To check whether C>, we check for each C>: <\itemize> if >y>, that =A>, where |)>> is the substitution corresponding to equations and implicit equalities in ; if |\>y>, that y|\>x> is not satisfiable. We use the library for exact precision rationals. To find the abduction answers to c>, pick a common variable \FV\FV> or the constant =1>. We have four possibilities: <\enumerate> \\d>> and \\c>>: the abduction answers are and >\c>>, \\d>> and c>\\>: the abduction answer is only , d>\\> and \\c>>: the abduction answer is only , d>\\> and c>\\>: the abduction answers are and >\d>>. Thanks to cases (1) and (4) above, the abduction algorithm can find some answers which are not fully maximal. The joint constraint abduction algorithm can help in some of the remaining cases where fully maximal abduction is insufficient for some implications, by solving simpler implications first. We provide an optional optimization: we do not pass, in the first call to numerical abduction (the second iteration of the main algorithm), branches that contain unary predicate variables in the conclusion, i.e. we only use the ``non-recursive'' branches. Other optimizations that we use are: iterative deepening on the constant used to generate > factors. We also constrain the algorithm by filtering out transformations that contain ``too many'' variables, which can lead to missing answers if the setting -- ``too many'' -- is too low. Similarly to term abduction, we count the number of steps of the loop and fail if more than the option steps have been taken. Here we expand on the exposition from Section . answers are the maximally specific conjunctions of atoms that are implied by each of a given set of conjunction of atoms. In case of term equations the constraint generalization algorithm is based on the algorithm. In case of linear arithmetic inequalities, constraint generalization is exactly finding the convex hull of a set of possibly unbounded polyhedra. We employ our unification algorithm to separate sorts. Since as a result we do not introduce variables for , we include the variables introduced by anti-unification in constraints sent to constraint generalization for their respective sorts. The adjusted algorithm looks as follows: <\enumerate> Let D\\|)>> where > is of sort , be the result of our sort-separating unification. For the sort >: <\enumerate> Let ,|\>\i\t.x>t\D>|}>>. Let |\>,u,|\>\=|\>\>|]>,\|)>=t|}>> be the most specific anti-unifiers of |\>> for each . Let =\|\>>>> and =D>\D>. Let =>yx>t\D,y>t\D,D\t>t|}>>. Let >=\x>u\\D|)>> (where conjunctions are treated as sets of conjuncts and equations are ordered so that only one of >b,b>a> appears anywhere), and |\>>=|\>|\>>. Let D\D> for > of sort . For sorts s>, let |\>.A=LUB\D|\>|)>>. The answer is |\>|\>|\>|\>.\A>. We simplify the result by substituting-out redundant answer variables. We follow the anti-unification algorithm provided in , fig. 2. provides a polynomial-time algorithm to find the half-space represented convex hull of closed polytopes. It can be generalized to unbounded polytopes -- conjunctions of linear inequalities. Our implementation is inspired by this algorithm but very much simpler, at cost of losing the optimality requirement. First we find among the given inequalities those which are also the faces of resulting convex hull. The negation of such inequality is not satisfiable in conjunction with any of the polytopes -- any of the given sets of inequalities. Next we iterate over touching the selected faces: pairs of the selected face and another face from the same polytope. We rotate one face towards the other: we compute a convex combination of the two faces of a ridge. We add to the result those half-spaces whose complements lie outside of the convex hull (i.e. negation of the inequality is unsatisfiable in conjunction with every polytope). For a given ridge, we add at most one face, the one which is farthest away from the already selected face, i.e. the coefficient of the selected face in the convex combination is smallest. We check a small number of rotations, where the algorithm from would solve a linear programming problem to find the rotation which exactly touches another one of the polytopes. When all variables of an equation >b> appear in all branches >, we can turn the equation >b> into pair of inequalities b\b\a>. We eliminate all equations and implicit equalities which contain a variable not shared by all >, by substituting out such variables. We pass the resulting inequalities to the convex hull algorithm. Separately, we compute the equations common to all branches, because the convex hull algorithm is not guaranteed to recover them. Although finding recursive function invariants -- predicate variables solved by abduction -- could theoretically fail to converge for both the type sort and the numerical sort constraints, neither problem was observed. Finding existential type constraints can only fail to converge for numerical sort, because solutions are expected to decrease in strength. But such diverging numerical constraints are commonplace. The main algorithm starts by performing constraint generalization only on implication branches corresponding to non-recursive cases, i.e. without binary predicate variables in premise (or unary predicate variables in conclusion). This generates a stronger constraint than the correct one. Subsequent iterations include all branches in constraint generalization, weakening the constraints, and so still weaker constraints are fed to constraint generalization in each following step. To ensure convergence of the numerical part, starting from some step of the main loop, we compare consecutive solutions and extrapolate the trend. Currently we simply intersect the sets of atoms, but first we expand equations into pairs of inequalities. We ``lift'' variables escaping the scope of a postcondition by renaming them to fresh variables, which are added to the answer variables of generalization. We apply this renaming ater anti-unification, prior to performing generalization in other domains. We pass to other domains as parameters to preserve only non-escaping variables. The non-escaping variables are these which have in their scope a variable >, passed as argument to the generalization algorithm. Constraint generalization limited to non-recursive branches, the initial iteration of postcondition inference, will often generate constraints that contradict other branches. For another iteration to go through, the partial solutions need to be consistent. Therefore we filter the constraints using the same validation mechanism as in abduction. We add atoms to a constraint greedily, but to favor relevant atoms, we do the filtering while computing the connected component of constraint generalization result. See the details of the main algorithm in section . While reading section , you will notice that postconditions are not subjected to stratification. This is because the type system does not support nested existential types. In the simplification step at the end of constraint generalization, we try to preserve alien variables that are parameters rather than substituting them by constants. A parameter can only equal a constant if not all branches have been considered for constraint generalization. The parameter is both as informative as the constant, and less likely to contradict other branches. Here we expand on the overview from Section . here are the variables shared by all disjuncts, i.e. FV|)>>, remaining variables are . Recall that for numerical constraint generalization, we either substitute-out a non-global variable in a branch if it appears in an equation, or we drop the inequalities it appers in if it is not part of any equation. Non-global variables can also pose problems for the term sort, by forcing constraint generalization answers to be too general. When inferring the type for a function, which has a branch that does not use one of arguments of the function, the existential type inferred would hide the corresponding information in the result, even if the remaining branches assume the argument has a single concrete type. We would like the corresponding non-global variable to resolve to the concrete type suggested by other branches of the resulting constraint. We extend the notion of constraint generalization: substitution and solved form |\>.A> is an answer to problem |\>> given a quantifier prefix > when: <\enumerate> i|)>\U|)>\\|\>\\FV.A>; If \Dom>, then \|)>\\> -- variables substituted by are existentially quantified; i|)>\\|)>\|)>\\Dom|)>.D>. Our generalized anti-unification algorithm is in Table .<\float|float|t> <\big-table> <\eqnarray*> ;t|)>>||,t,U,G>>|>|)>;\;f>|)>|)>>|||\>,f>|)>,U,G>>||\>,>,U,G>||>;\;>|)>>>|;\;t|)>>||,\,U,G>>|>||;\;t|]>\\|)>\G>>|;\;\;f>|)>;\>|)>>|||\>|\>,g,U,G>>||\>,g,U,G>||,G>>\f|\>|)>|]>|)>>>|>||\f|\>|)>|]>\\>f|\>|)>>>|>||\|)>\\\\\|\>|\>\\>>|;\;\;\;\>|)>>|||\>,g,U,G>>||\>,g,U,G>||,G>>\\|]>|)>>>|>||\\|]>\\>\>>|>||\\\,\\>\>>|;\;t|)>>||,\,U,;\;t|]>\\|)>G>>|>||\#FV;\;t,U,G|)>>>||)>>||,\,U,G>>|;\|)>>||,\,U,G>>|,>;\;t,>|)>>|||\>|\>,g>,U,G>>||\>,g,U,G>||;\;t|)>>>||\>,>,U,G>||,G>>;\;>|)>>>>> The notational shorthand ;\;\;f>|)>;\> represents the case where all terms are either existential variables or start with a function symbol . Similarly, ;\;\;\;\> represents the case when there is a variable > such that all terms are either > or are existential variables to the right of > in the quantifier. The sort-integrating algorithm essentially does not change: <\enumerate> Let D\\|)>> where > is of sort , be the result of our sort-separating unification. For the sort >: <\enumerate> Let ,|\>\i\t.x>t\D>|}>>. Let |\>,g,u,|\>\=|\>\>|]>,\|)>=j>u|)>|)>|}>> be the most specific anti-unifiers of j>u|)>|)>|\>> for each , where u> is the resulting >. Let =\|\>>>> and =D>\D>. Let =>yx>t\D,y>t\D,D\t>t|}>>. Let >=\x>g\\D|)>> (where conjunctions are treated as sets of conjuncts and equations are ordered so that only one of >b,b>a> appears anywhere), and |\>>=|\>|\>>. Let D\D> for > of sort . For sorts s>, let |\>.A=LUB\D|\>|)>>. The answer is substitution u> and solved form |\>|\>|\>|\>.\A>. The task of constraint generalization is to find postconditions. Usually, it is beneficial to make the postcondition, i.e. the existential type that is the return type of a function, more specific, at the expense of making the overal type of the function less general. To this effect, constraint generalization, just as abduction takes invariant parameters |\>>. We replace conditions \\\> above by \|\>\\|)>\\>. Recall that the right-hand-side (RHS) variable > can in general be universally quantified: \\\>. We exclude universal non-parameter RHS when a parameter is present: if for any >, \|\>>, then for all > including RHS, \|\>\\\\\>. Note that having weaker postconditions also results in correct types, just not the intended ones. In rare cases a weaker postcondition but a more general invariant can be beneficial. To this effect, the option more_existential> turns off generating the substitution entries when the RHS is a variable, i.e. the case ;\;\;\;\>|)>> is skipped. Due to greater flexibility of the numerical domain, abductive extension of numerical constraint generalization does not seem necessary and is turned off by default. It could take a similar form, we experiment with the following heuristic. If atoms specific to a disjunct (i.e. not shared by all disjuncts) do not contain a variable, do not include the disjunct when considering inclusion of inequalities containing the variable in the constraint generalization answer. Here we expand on the overview from Section . We call a an implication \> in the normalized constraint .\\C|)>>, and we call the . Such constraints are generated for pattern matching branches whose right-hand-side is the expression . A generic approach to account for negative constraints is as follows. We check whether the solution found by multisort abduction contradicts the negated constraints. If some negated constraint is satisfiable, we discard the answer and ``fall back'' to try finding another answer. Unfortunately, this approach is insufficient when the answer sought for is not among the maximally general answers to the remaining, of the constraint. Therefore, we introduce . For the numerical sort, our implementation of negation elimination can produce too strong constraints when the numerical domain is intended to contain non-integer rational numbers, and can be turned off by the option. It can also produce too weak constraints, because it produces at most one atom for a given negated constraint. If the abduction answer for terms does already contradict a negated constraint , we are done. Otherwise, let \\\c>. For numerical sort atoms >, either drop them from consideration or convert their negation c> into > or >\d>> as follows. The conversion assumes that the numerical domain is integers. We convert an inequality 0>, e.g. x-y-2\0>, to 0>, e.g. 0>, where is the common denominator so that has only integer numbers. Note that 0|)>\w\0\-w\0\-k*w\0\-k*w+1\0>. Similarly, we convert an equation >0> to inequalities 0\k*w+1\0>. Note that 0|)>\w\0\k*w\0\k*w+1\0>. In both cases the implications > would be equivalences if the numerical domain was integers rather than rational numbers. At present, we ignore atoms. The disjunct > is a conjunction of inequalities if > is a atom. Assuming that each negative constraint points to a single atomic fact, we try to find one disjunct >, resp. >> or >>, corresponding to c>, discarding those disjuncts that contradict any implication branch. Specifically, let .\\C|)>> be the constraint we solve, and let |\>.A> be a term abduction answer for .\\\>\C|)>>. We search for such that for all with \\> and > satisfiable, \A\D\C> is satisfiable. We provide a function D,|\>|)>=d>>, where >> is the biggest, syntactically, such atom, and =A\D\C>. Unfortunately, for the sort of terms we do not have well-defined representation of dis-equalities not using negations. The generic approach of relying on backtracking to find another abduction answer is more useful for terms than for the numeric sort. It falls short, however, when negation was intended to prevent the answer from being too general. Ideally, we would introduce disequation atoms |\>\> and follow the scheme we use for the numerical sort. For now, we only cover a very specific use of negation, to discriminate among type-level ``enumeration''. We limit negation elimination to considering atoms of the form >\>, and contradict them by introducing atoms >\>, for types \\> without parameters which we call . The variables > are limited to the answer variables generated in the previous iteration of the main algorithm. The nullary datatype constructor > is picked so that the atom is valid, using the same validation procedure as the one passed to the abduction algorithm. The heuristic defines phantom enumerations as nullary phantom types that do not share datype parameter position (in GADT constructor definitions) with non-enumeration types. When the equations derived for different negated constraints involve a common variable as the left-hand-side, we select a common right-hand-side. In the end, we only introduce the negation elimination result to the answer when a single disjunct remains. Since the (or taboo) list used by backtracking is based on complete answers, it is preferable to perform negation elimination prior to abduction. Otherwise, the search might fall into a loop where abduction keeps returning the same answer, since it is more general than the discarded answer incorporating negation elimination result. and : and Relations in > We extend the numerical domain with relations and defined below. Operations and can then be defined using it. Let be any linear combinations. Note that the relations are introduced to smuggle in a limited form of disjunction into the solved forms. <\eqnarray*> >||0\w\0\>0\w>0|)>>>|>min>||>>|>max>||>>|>||0\w\0>>|max>||>>|\k>||>>>> In particular, \max>0> and \min\0>. We call an or atom when there is a variable that appears in and with the same sign. We do not prohibit undirected or atoms, but we do not introduce them, to avoid bloat. For simplicity, we do not support and as subterms in concrete syntax. Instead, we parse atoms of the form >>, resp. >> into the corresponding atoms, where is any numerical term. Similarly for . We also print directed and atoms using the syntax with and expressions. Not to pollute the syntax with a new keyword, we use concrete syntax >> for parsing arbitrary, and printing non-directed, atoms, and >> for respectively. If need arises, in a future version, we can extend to a larger arity . In the function that produces solved forms of numerical constraints, we treat clauses in an efficient but incomplete manner, doing a single step of constraint solving. We include the terms in processed inequalities. After equations have been solved, we apply the substitution to the and disjunctions. When one of the resp. disjunct terms becomes contradictory or the disjunct terms become equal, we include the other in implicit equalities, resp. in inequalities to solve. When one of the or terms becomes tautological, we drop the disjunction. We iterate calls to the solver function to propagate implicit equalities. We do not perform case splitting on and disjunctions, therefore some contradictions may be undetected. However, abduction and constraint generalization currently perform upfront case splitting on and disjunctions, sometimes leading to splits that a smarter solver would avoid. We eliminate and in premises by expanding the definition and converting the branch into two branches, e.g. >0\w>0|)>\C> into v>0\C|)>\w>0\C|)>>. Recall that an atom also implies inequalities \w\0> assumed to be in above. This is one form of : we consider cases >0> and >0>, resp. 0> and 0>, separately. We do not eliminate and in conclusions. Rather, we consider whether to keep or drop it in the answer, like with other candidate atoms. The transformations apply to an atom by applying to both its arguments. Generating a new atom for inclusion in an answer means finding a pair of equations such that the following conditions hold. Each equation, together with remaining atoms of an answer but without the remaining equation selected, is a correct answer to a simple abduction problem. The equations selected share a variable and are oriented so that the variable appears with the same sign in them. The resulting atom passes the validation test for joint constraint abduction. We may implement generating new atoms for abduction answers in a future version, when need arises. Currently, we only generate new and atoms for postconditions, i.e. during constraint generalization. We eliminate and atoms prior to finding the extended convex hull of |\>> by expanding the definition and converting the disjunction D> to disjunctive normal form. This is another form of case splitting. In addition to finding the extended convex hull, we need to discover relations that are implied by D>. We select these faces of the convex hull which also appear as an equation in some disjuncts. Out of these faces, we find all minimal covers of size 2, i.e. pairs of faces such that in each disjunct, either one or the other linear combination appears as an equation. We only keep pairs of faces that share a same-sign variable. For the purposes of detecting relations, we need to perform transitive closure of the extended convex hull equations and inequalities, because the redundant inequalities might be required to find a cover. Finding atoms is similar. We find all minimal covers of size 2, i.e. pairs of inequalities such that one or the other appears in each disjunct. We only keep pairs of inequalities that share a same-sign variable. We provide a function for the numerical domain to remove atoms of the form >min>, >min>, >max> or >min> for a constant , similarly for atoms, while in initial iterations where constraint generalization is only performed for non-recursive branches. We need to further extend the notion of (abductive) constraint generalization, to achieve the results required for postcondition inference. For constraint branches \C|\>>, we need not only the disjuncts \C|\>>, but also the premises |\>>. We keep and atoms ,subopti> such that either both w> and v> are all , or neither is. An atom is satisfiable with implication \C> here, when either D> is not satisfiable, or D\C> is satisfiable. The underlying idea is that since and atoms express a disjunction, resp. 0\w\0\>0\w>0|)>> and 0\w\0>, they are meaningful when both cases of the disjunction can obtain under some circumstances. When only one of the atoms, say w>, is satisfiable with all implication branches, we make an abductive guess that w>. Here we discuss the implementation in of ideas in the overview from Section and in the formal discussion from Section . As we decided to provide the first solution to abduction problems, we accordingly simplify the task of solving for predicate variables. Instead of a tree of solutions being refined, we have a single sequence which we unfold until reaching fixpoint or contradiction. Another choice point besides abduction in the original algorithm is the selection of invariants that leaves a consistent subset of atoms as residuum. Here we also select the first solution found. We introduce a form of backtracking, described in section . The core of our inference algorithm consists of distributing atoms of an abduction answer among the predicate variables. The negative occurrences of predicate variables, when instantiated with the updated solution, enrich the premises so that the next round of abduction leads to a smaller answer (in number of atoms). Let us discuss the algorithm for ,|\>,A,|\>>|\>,>|\>|)>>. Note that due to existential types predicates, we actually compute ,|\>,A,|\>>>|\>,>>|\>|)>>, i.e. we index by >> (which can be multiple for a single >) rather than >. We retain the notation indexing by > as it better conveys the intent. We do not pass quantifiers around to reflect the source code: the helper function of function corresponds to |\>,A,>>|\>|)>>. <\eqnarray*> \\>|>|\>\\\>\\\\>\\\\|\>>|\>\\\|\>>|\>|)>>>|\>>||>\\A\\|\>>|\>\\|)>\\\\\\|}>>>|>||\>>>|>>||A\\\FV.\|)>\\\\\>\>\\\PrimCV\\\|\>>|\>\\\PrimCV|}>>>|>>|||\>>|\>,A>|)>>>|>>||>\\\>A>>>|>||\\.\>A>|)>|\>\>|]>>>>|>||>>|>|\>\>||>>\A>|)>\\\\.>A>\A|)>|\>\>|]>>:>>|>||>,|\>>|)>\\>>|>||>>||\>>,A>,A>>||>,|\>>|)>>>|>>||>\A>>>||\>>>|||\>\FV>|)>>>||\>>>|||\>>\\>\>|\>>|)>|\>>>>|>||>A>>>|>||\|~>\>A>|)>>>|>||>|\>>\\\\>A>\\>>|,A,|\>>.A>|\>>|>||\>>|\>\|\>>\|\>>|)>|\>|]>,|\>\\>|\>>,A\>A>,|\>>\|\>>|\>,>|\>|)>>>|>||,A\>\A,|\>>|\>>.A>|\>>>|>||\|\>\\>|\>>|)>,A\>\A,|\>>.A>|\>>>>> where |\>>|)>> is computed as follows: for every A>, and for every \FV> such that \>\> for \|\>>>, if > is universally quantified in > and \|\>>|\>>, then return >; otherwise, introduce a fresh variable >, replace c\\|]>>, add >\> to >> and > to |\>>>, after replacing all such > add the resulting to >>. > stands for of an atom . These are defined as the substituted variables in solved forms for term constraints, and in the case of a numerical atom, the shared variable of a directed opti or subopti atom, i.e. the variable in max|)>>, |)>\v>, |)>>, |)>>. Description of the algorithm in more detail: <\enumerate> \\>|>|\>\\\>\\\\>\\\\|\>>|\>\\\|\>>|\>|)>>>>>>> The variables |\>>|\>> are the invariant parameters of the solution from the previous round. We need to keep them apart from other variables even when they're not separated by quantifier alternation. >||\>>>>>>> where\>>||>\\A\\|\>>|\>\\|)>\\\\\\|}>>>>>>> Discard the ``scaffolding'' information, in particular the > equations introduced by in an earlier iteration. >>||A\\\FV\\|\>>.\|)>\\\\\>\>|}>>>>>>> Gather atoms pertaining to predicate >, which should not remain in the residuum. >>|||\>>|\>,A>|)>>>>>>> An atomized form of >> wrt. |\>>|\>>: a conjunction of atoms equivalent to >> containing some of the implications of >>, see the formal exposition of InvarGenT. Actually, rather than computing the atomized form upfront, we generate its contribution to >> while performing Fourier-Motzkin elimination to check \\.>A>\A|)>>. >>||>\\\>A>>>>>>> We prune atoms coming from atomization that are already present in the invariants. Actually, in the implementation we prune by redundancy with the invariants assigned so far. \\\.\>A>|)>|\>\>|]>>\>>>>>>: Failed solution attempt. A common example is when the use site of recursive definition, resp. the existential type introduction site, is not in scope of a defining site of recursive definition, resp. an existential type elimination site, and has too strong requirements. FIXME: >|\>\\>>\A>|)>\\\\.>A>\A|)>|\>\>|]>>:> Select invariants such that the residuum \>A>> is consistent. The final residuum > represents the global constraints, the solution for global type variables. The solutions >> represent the invariants, the solution for invariant type parameters. >||>,|\>>|)>\\>>>>>\> In the implementation, we address stratification issues already during abduction. |\>>,A>,A>=Strat>,|\>>|)>> is computed as follows: for every A>>, and for every \FV> such that \>\> for \|\>>>, if > is universally quantified in >, then return >; otherwise, introduce a fresh variable >, replace c\\|]>>, add >\> to >> and > to |\>>>, after replacing all such > add the resulting to >>. <\itemize> We will add |\>>> to |\>>>. >>||>\A>>>>>>> is the updated solution formula for >, where >> is the solution from previous round. |\>>>|||\>\FV>|)>>>>>>> are the additional solution parameters coming from variables generated by abduction. |\>>>|||\>>\\>\>|\>>|)>|\>>>>>>>> The final solution parameters also include the variables generated by . >||>A>>>>>>> and >||\|~>\>A>|)>>>>>>> is the resulting global constraint, where |~>> is the substitution corresponding to >. >||>|\>>\\\\>A>\\>>>>>> -- If new parameters or new atoms have been introduced, we need to redistribute the remaining atoms to make .A> valid again. ,A,|\>>.A>|\>>|>||\>>|\>\|\>>\|\>>|)>|\>|]>,|\>\\>|\>>,A\>A,|\>>\|\>>|\>,>|\>|)>>>>>>> Recursive call includes |\>>> in |\>>> so that, among other things, > are redistributed into >>. >||,A,|\>>|\>>.A>|\>>>>>>> We do not add |\>> in front of > because it already includes these variables. |\>>|\>>|\>> lists all variables introduced by . >||\|\>\\>|\>>|)>,A,|\>>.A>|\>>>>>>> Note that |\>\\>|\>>> does not contain the current |\>>>, because |\>> does not contain it initially and the recursive call maintains that: |\>\|\>\\>|\>>,|\>>\|\>>|\>>>. Finally we define |\>,A|)>\Split|\>,A,|\>|)>>. The complete algorithm for solving predicate variables is presented in the next section. The general scheme is that we perform constraint generalization on branches with positive occurrences of existential type predicate variables on each round. Since the branches are substituted with the solution from previous round, constraint generalization will automatically preserve monotonicity. We retain existential types predicate variables in the later abduction step. What differentiates existential type predicate variables from recursive definition predicate variables is that the former are not local to context, while the latter are treated as local to context. It means that free variables need to be bound in the former while they are retained in the latter. However, it is just a technical difference because In the algorithm we operate on all predicate variables, and perform additional operations on existential type predicate variables; there are no operations pertaining only to recursive definition predicate variables. The equation numbers > below are matched by comment numbers in the source code. Let K>> be the invariant which will constrain the existential type >, or >. When K>=\>, then we define |\>K>,k>=\>. Step of the loop of the final algorithm: <\eqnarray*> ||||\>,k>.F>|\>>||>>|||>>|||S.>>|>\C>\RS|)>>||\,\>|)>\C>,>>|||>|\>=D\C\S|)>\D\D>|}>>>|>|||)>\>>|>,\|\>>.G>,|\>>||,>\\D>\C>|\>\|\>>|)>>>||\>>>||\FV>|)>\\\\|\>>\|)>\\\\\|\>>|\>\\|\>>|}>|\>>>||\>>.G>|)>>||FV|\>>,G>|)>\\\\.\>|\>>\G>>>||\>>.F>|)>,\>|||)>,\|\>>.G>|)>|)>>>||)>>|||\>>.F>>>|,\|)>|)>=P|)>|)>>||>|\>>>>|>>||>|\>|)>\\|\>>|)>|\>>,|\>|)>|]>|]>>>|>|||\>,k>\FV>|)>\>\>\|}>.F>|\>>>|.\\C|)>\\\|)>>||PS\>U>|)>>>||\>.A>||,|\>=>|\>>|\>,,C|\>|)>>>|||\NegElimSimpl|)>\\|\>>|\>.D|)>,A,,C|\>|)>>>|||>>|,A,|\>>>.A>>|\>|)>>||,|\>,A,>|\>>|\>|)>>>||\>>>|||~>|\>>|)>|)>|\>>>||)>>|||\>,k>|\>>>|\>|\>>\\FV|\>>|)>.\>|\>>\|~>>\\\>\|)>\>A>>>|\>>>|\>\|\>,k>|\>|]>>>|>||A>>>|\>>>|\>\|\>,k>|\>|]>FV\FV|)>|)>|}>>>||\>.A>||,>|\>>|\>\\>|\>>|\>,|)>,A|\>|)>>>|,\,|\>>>.A>>|\>|)>>||,|\>|\>,\A,>|\>>|\>\\>|\>>|\>|)>>>||)>>|||\>,k>.Simpl|\>>>|\>.F>\A>>>|\>>|\>\|\>,k>|\>|]>\A>>|)>>>|>||\|)>S|)>\S|)>,>>|||\|)>R|)>=R|)>,>>|||\>|)>A>>=\,>>|||1>>|>||,S,R>>|>||k+1>>>> Note that returns |\>>>.A>>|\>> rather than |\>>.A>|\>>. This is because in case of existential type predicate variables >, there can be multiple negative position occurrences >,\|)>> with different >> when the corresponding value is used in multiple >> \ >>> expressions. The variant of the algorithm to achieve completeness would compute all answers for variants of and algorithms that return multiple answers. Unary predicate variables >|)>> can also have multiple negative occurrences in the normalized form, but always with the same argument >>. The substitution >|\>>>|\>\|\>,k>|\>|]>> replaces the instance parameters introduced in >,\|)>> by the formal parameters used in |)>>. Even for a fixed , the same branch >\C>> can contribute to multiple disjuncts, with different =\>. Substitution > substitutes only negative occurrences of >, i.e. it affects only the premises. Substitution > substitutes only positive occurrences of >, i.e. it affects only the conclusions. > ensures that the parameter instances of the postcondition are connected with the argument variables. As a matter of implementation, the substitution |\>>,|\>|)>> is actually derived from the way the variables are freshened in step above. Its effect is currently implemented as a substitution over the intermediate formula >|\>|)>\\|\>>|)>|]>>. We start with \|\>> and \|\>>. > grow in strength by definition. The constraint generalization parts >> of > and > are computed from non-recusrive branches only. Starting from >, > are expected to decrease in strength, but monotonicity is not guaranteed because of contributions from abduction: mostly in form of >>>, but also from stronger premises due to >. We remove non-term-sort atoms containing containing outer-scope parameters from >, to enable considering a different solution when new facts about outer-scope parameters propagate. ,G|)>> is the connected component of hypergraph containing node >, where nodes are variables > and hyperedges are atoms G>. ,|\>,G|)>|)>> additionally removes atoms #\|\>>. In initial iterations, when the branches >\C>> are selected from non-recursive branches only, we include a connected atom only if it is satisfiable in all branches. ,R|)>> is a convergence improving heuristic, with ,R|)>=\|)>> for early iterations and ``roughly'' ,R|)>=R\\|)>> later. The substitution , also computed by the function , is a renaming that replaces the variables introduced by constraint generalization in the current iteration, by the corresponding variables introduced by constraint generalization in the previous iteration. The use sites of definitions with postconditions can introduce requirements >>> on postconditions. The inferred postconditions can only meet those requirements which are guaranteed by all defining cases. We use abduction again to strengthen the preconditions, so that the postconditions meet the requirements. Abduction is applied directly to the constraint branches preprocessed by constraint generalization, so that the required postconditions will follow in the next iteration. The condition \>|)>A>>=\> is required for correctness of returned solution. Fixpoint of postconditions |)>> is not a sufficient stopping condition, because it does not imply >>=\>, the same >>\\> may be introduced in consecutive iterations. This is not the case for invariants, where |)>> and |)>> differ by the portion >>> of abduction answer. We introduced the construct into the programming language to indicate that a branch of code should not be reached. Type inference generates for it the logical connective > (falsehood). We partition the implication branches ,C> into ,C\\C|}>> which are fed to the algorithm and |}>=\\C|}>>. After the main algorithm ends we check that for each >, \ |)>> fails. Optionally, but by default, we perform the check in each iteration, starting from the third iteration, i.e. 1>. Turning this option gives a way to express negative constraints for the term domain. The option should be turned when a single iteration (plus fallback backtracking described below) is insufficient to solve for the invariants. Moreover, for domains with negation elimination, i.e. the numerical domain, we incorporate negative constraints as described in section . The corresponding computation is \NegElimSimpl|)>\\|\>>|\>.D|)>,,C|\>|)>> in the specification of the main algorithm. The simplification reduces the number of atoms in the formula and keeps those that are most relevant to finding invariants and postconditions. For convenience, negation elimination is called from the function that computes the abduction answer. We implement backtracking using a tabu-search-like discard list. When abduction raises an exception: for example contradiction arises in the branches |)>> passed to it, or it cannot find an answer and raises with information on potential problem, we fall-back to step . Similarly, with checking for negative constraints , when the check of negative branches \\>>, \ \\FV|)>|)>.S|)>> fails. In step , we maintain a discard list of different answers found not to work in this step and previous steps: initially empty, after fall-back we add there the latest partial solution. We redo step starting from |)>>. Infinite loop is avoided because answers already attempted are discarded. When step cannot find a new partial solution, we fall back to step , etc. We store discard lists for distinct sorts separately and we only add to the discard list of the sort that caused fallback. Unfortunately this means a slight loss of completeness, as an error in another sort might be due to bad choice in the sort of types. The loss is ``slight'' because of the dissociation step described previously. Moreover, the sort information from checking negative branches is likewise only approximate. Changes in the algorithm between iterations were mentioned above but not clearly exposed. We divide iterations into multiple stages, demarcated by parameters > we now describe. <\enumerate> > is when inferring any postconditions starts; we use the initial iteration to infer the shape of types using abduction.\ > is when inferring numerical postconditions starts. > is when using all branches of the constraint in inference starts; before >, we only use the branches of the constraint that do not contain requirements derived from recursive calls. If we use all branches too early, we suffer from missing information. > is when second-phase abduction, to enrich preconditions based on postconditions, starts. > is when any forms of guessing in constraint generation should end; we have not yet implemented any such guessing mechanisms. > is when convergence of postconditions is enforced; from this step onward, a solution to postconditions in an iteration is truncated to contain only atoms matching atoms from the previous iteration. > is the last iteration; if the fixpoint is not reached, we signal an error . Default settings are ;j;j;j;j;j;j|]>=> where the initial iteration has index 0. In a single iteration, constraint generalization precedes abduction. When existential types are used, the expected number of iterations is (six iterations), because the last iteration needs to verify that the last-but-one iteration has found the correct solution. The minimal number of iterations is (three iterations), so that all branches are considered. We represent |\>> as a tuple type rather than as a function type. We modify the quantifier > imperatively, because it mostly grows monotonically, and when variables are dropped they do not conflict with fresh variables generated later. The code that selects >|\>> by >>\A>|)> and \\\.A\\>A>> is an incremental validity checker. It starts with \>A>> and tries to add as many atoms \>A>> as possible to what in effect becomes >. We count the number of iterations of the main loop, a fallback decreases the iteration number to the previous value. The main loop decides whether multisort abduction should dissociate alien subterms -- in the first iteration of the loop -- or should perform abductions for other sorts -- in subsequent iteration. See discussion in subsection . In the first two iterations, we remove branches that contain unary predicate variables in the conclusion (or binary predicate variables in the premise, keeping only non-recursive branches), as discussed at the end of subsection and beginning of subsection . As discussed in subsection , starting from iteration >, we enforce convergence on solutions for binary predicate variables. Computing abduction is the ``axis'' of the main loop. If anything fails, the previous abduction answer is the culprit. We add the previous answer to the discard list and retry, without incrementing the iteration number. If abduction and splitting succeeds, we reset the discard list and increment the iteration number. We use recursion for backtracking, instead of making tail-recursive. We have a single basis from which to generate all generated output files: , -- . It contains a superset of information in : type scheme annotations on introduced names, and source code annotated with type schemes at recursive definition nodes. We use syntax instead of syntax because the former supports inference for GADTs in OCaml. A benefit of the nicer syntax is that nested type schemes can have free variables, which will be correctly captured by the outer type scheme. For completeness we sometimes need to annotate all nodes with types. To avoid clutter, we start by only annotating nodes, and in case fails on generated code, we re-annotate by putting type schemes on nodes and types on nodes. If need arises, node annotations can also be introduced in this fallback -- we provide an option to annotate the definitions on nodes. Type annotations are optional because they introduce a slight burden on the solver -- the corresponding variables cannot be removed by the initial simplification of the constraints. node annotations are more burdensome than node annotations. In the signature declarations for existential types, we replace existential identifiers with regular indentifiers of constructors, to get informative output for printing the various result files. We print constraint formulas and alien subterms in the original InvarGenT syntax, commented out. The types , , and should be considered built-in. , and follow the general scheme of exporting a datatype constructor with the same name, only lower-case. However, numerals , , ... are always type-checked as , ... A parameter decides the type alias definition added in the generated code: adds in front of an file, by default . Numerals are exported as integers passed to a function. The variant exports numerals by passing to a function. Special treatment for amounts to exporting and as and , unlike other constants. In addition, pattern matching >>>>>, i.e. the corresponding beta-redex, is exported as the >>> expression. In declarations which have concrete syntax starting with the word , we provide names assumed to have given type scheme. The syntax has two variants, differing in the way the declaration is exported. It can be either an declaration in OCaml, which is the binding mechanism of the . But in the InvarGenT form , the declaration provides an OCaml definition, which is exported as the toplevel definition of OCaml. It has the benefit that the OCaml compiler will verify this definition, since InvarGenT calls to verify the exported code. Subsection titles start with ``Function'' for examples from Tables and , and ``Program'' for examples from Table . : Function > Example from , described on page 50. Source file : <\code> datatype R : type datacons RBool : R Bool external let fortytwo : Int = "42" \; let rx = function RBool -\> fortytwo Value items from : <\code> val rx : >a. R a > Int These are the longer examples from within the scope of algorithm >. > Example from , described on pages 193-194. Source file : <\code> datatype Z datatype S : type \; datatype RoB : type * type datatype Black datatype Red datacons Leaf : RoB (Black, Z) datacons RNode : >a. RoB (Black, a) * Int * RoB (Black, a) > RoB (Red, a) datacons BNode : \ \ >a, b, c. RoB (a, c) * Int * RoB (b, c) > RoB (Black, S c) \; datatype Dir datacons LeftD : Dir datacons RightD : Dir \; let rotate = fun dir1 p_e sib dir2 g_e uncle -\> function \| RNode (x, e, y) -\> \ \ (match dir1, dir2 with \ \ \| RightD, RightD -\> BNode (RNode (x, e, y), p_e, RNode (sib, g_e, uncle)) \ \ \| RightD, LeftD -\> BNode (RNode (uncle, g_e, x), e, RNode (y, p_e, sib)) \ \ \| LeftD, RightD -\> BNode (RNode (sib, p_e, x), e, RNode (y, g_e, uncle)) \ \ \| LeftD, LeftD -\> BNode (RNode (uncle, g_e, sib), p_e, RNode (x, e, y))) \| BNode (_, _, _) -\> assert false Value items from : <\code> val rotate : \ \ \ >a. \ \ \ Dir > Int > RoB (Black, a) > Dir > Int > RoB (Black, a) > \ \ \ \ \ RoB (Red, a) > RoB (Black, S a) : -way > Example from , provided on page 206. The definition of is >-expanded here to fit the call-by-value semantics of . Source file : <\code> datatype List : type datacons N : >a. List a datacons C : >a. a * List a > List a \; datatype Zip2 : type * type datacons Zero2 : >a. Zip2 (a, List a) datacons Succ2 : \ \ >a, b, c. Zip2 (a, b) > Zip2 ((c > a), (List c > b)) \; let zip2 = \ \ let rec zipZ = function \ \ \ \ \| Zero2 -\> N \ \ \ \ \| Succ2 n -\> fun _ -\> zipZ n in \ \ let rec zipS = fun f r -\> function \ \ \ \ \| Zero2 -\> C (f, r) \ \ \ \ \| Succ2 n -\> function \ \ \ \ \ \ \| N -\> zipZ n \ \ \ \ \ \ \| C (z, zs) -\> zipS (f z) (r zs) n in \ \ let rec z2 = fun n f -\> zipS f (z2 n f) n in \ \ z2 Value items from : <\code> val zip2 : >a, b. Zip2 (b, a) > b > a > Example from , described on pages 198-199. Source file : <\code> datatype Z datatype S : type datatype AVL : type datacons Tip : AVL Z datacons LNode : >a. AVL a * Int * AVL (S a) > AVL (S (S a)) datacons SNode : >a. AVL a * Int * AVL a > AVL (S a) datacons MNode : >a. AVL (S a) * Int * AVL a > AVL (S (S a)) \; datatype Choice : type * type datacons L : >a, b. a > Choice (a, b) datacons R : >a, b. b > Choice (a, b) \; let rotl = fun u v -\> function \ \ \| Tip -\> assert false \ \ \| SNode (a, x, b) -\> R (MNode (LNode (u, v, a), x, b)) \ \ \| LNode (a, x, b) -\> L (SNode (SNode (u, v, a), x, b)) \ \ \| MNode (k, y, c) -\> \ \ \ \ (match k with \ \ \ \ \ \ \| SNode (a, x, b) -\> L (SNode (SNode (u, v, a), x, SNode (b, y, c))) \ \ \ \ \ \ \| LNode (a, x, b) -\> L (SNode (MNode (u, v, a), x, SNode (b, y, c))) \ \ \ \ \ \ \| MNode (a, x, b) -\> L (SNode (SNode (u, v, a), x, LNode (b, y, c)))) Value items from : <\code> val rotl : \ \ \ >a. \ \ \ AVL a > Int > AVL (S (S a)) > \ \ \ \ \ Choice (AVL (S (S a)), AVL (S (S (S a)))) > Example from , provided on page 209. Source file : <\code> datatype Z datatype S : type datatype AVL : type datacons Tip : AVL Z datacons LNode : >a. AVL a * Int * AVL (S a) > AVL (S (S a)) datacons SNode : >a. AVL a * Int * AVL a > AVL (S a) datacons MNode : >a. AVL (S a) * Int * AVL a > AVL (S (S a)) \; datatype Choice : type * type datacons L : >a, b. a > Choice (a, b) datacons R : >a, b. b > Choice (a, b) \; datatype LinOrder datacons LT : LinOrder datacons EQ : LinOrder datacons GT : LinOrder external let compare : >a. a > a > LinOrder = \ \ "fun x y -\> let c=Pervasives.compare x y in \ \ \ \ \ \ \ \ \ \ \ \ \ \ if c\0 then LT else if c=0 then EQ else GT" \; external rotl : \ \ >a. AVL a > Int > AVL (S (S a)) > \ \ \ \ Choice (AVL (S (S a)), AVL (S (S (S a)))) \; external rotr : \ \ >a. AVL (S (S a)) > Int > AVL a > \ \ \ \ Choice (AVL (S (S a)), AVL (S (S (S a)))) \; let rec ins = fun i -\> function \ \ \| Tip -\> R (SNode (Tip, i, Tip)) \ \ \| SNode (a, x, b) as t -\> \ \ \ \ (match compare i x with \ \ \ \ \ \ \| EQ -\> L t \ \ \ \ \ \ \| LT -\> \ \ \ \ \ \ \ \ (match ins i a with \ \ \ \ \ \ \ \ \ \ \| L a -\> L (SNode (a, x, b)) \ \ \ \ \ \ \ \ \ \ \| R a -\> R (MNode (a, x, b))) \ \ \ \ \ \ \| GT -\> \ \ \ \ \ \ \ \ (match ins i b with \ \ \ \ \ \ \ \ \ \ \| L b -\> L (SNode (a, x, b)) \ \ \ \ \ \ \ \ \ \ \| R b -\> R (LNode (a, x, b)))) \ \ \| LNode (a, x, b) as t -\> \ \ \ \ (match compare i x with \ \ \ \ \ \ \| EQ -\> L t \ \ \ \ \ \ \| LT -\> \ \ \ \ \ \ \ \ (match ins i a with \ \ \ \ \ \ \ \ \ \ \| L a -\> L (LNode (a, x, b)) \ \ \ \ \ \ \ \ \ \ \| R a -\> L (SNode (a, x, b))) \ \ \ \ \ \ \| GT -\> \ \ \ \ \ \ \ \ (match ins i b with \ \ \ \ \ \ \ \ \ \ \| L b -\> L (LNode (a, x, b)) \ \ \ \ \ \ \ \ \ \ \| R b -\> rotl a x b)) \ \ \| MNode (a, x, b) as t -\> \ \ \ \ (match compare i x with \ \ \ \ \ \ \| EQ -\> L t \ \ \ \ \ \ \| LT -\> \ \ \ \ \ \ \ \ (match ins i a with \ \ \ \ \ \ \ \ \ \ \| L a -\> L (MNode (a, x, b)) \ \ \ \ \ \ \ \ \ \ \| R a -\> rotr a x b) \ \ \ \ \ \ \| GT -\> \ \ \ \ \ \ \ \ (match ins i b with \ \ \ \ \ \ \ \ \ \ \| L b -\> L (MNode (a, x, b)) \ \ \ \ \ \ \ \ \ \ \| R b -\> L (SNode (a, x, b)))) Value items from : <\code> val ins : >a. Int > AVL a > Choice (AVL a, AVL (S a)) > Example from , provided on page 207. Source file : <\code> datatype List : type datacons N : >a. List a datacons C : >a. a * List a > List a \; datatype Nd datatype Fk : type * type \; datatype Tree : type * type datacons End : >a. a > Tree (Nd, a) datacons Fork : >a, b, c. Tree (a, c) * Tree (b, c) > Tree (Fk (a, b), c) \; datatype Path : type datacons Here : Path Nd datacons ForkL : >a, b. Path a > Path (Fk (a, b)) datacons ForkR : >a, b. Path b > Path (Fk (a, b)) \; external append : >a. List a > List a > List a external map : >a, b. (a > b) > List a > List b \; let rec find f = function \ \ \| End m -\> if f m then C (Here, N) else N \ \ \| Fork (x, y) -\> append (map (fun y -\> ForkL y) (find f x)) \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ (map (fun y -\> ForkR y) (find f y)) \; let rec extract = fun p t -\> \ \ match p with \ \ \ \ \| Here -\> (match t with End m -\> m \| Fork (_, _) -\> assert false) \ \ \ \ \| ForkL p1 -\> (match t with Fork (x, y) -\> extract p1 x) \ \ \ \ \| ForkR p1 -\> (match t with Fork (x, y) -\> extract p1 y) Value items from : <\code> val find : >a, b. (a > Bool) > Tree (b, a) > List (Path b) \; val extract : >a, b. Path b > Tree (b, a) > a > Example from , provided on page 208. Source file : <\code> datatype State : type * type datacons Bind : \ \ >a, b, s. State (s, a) * (a > State (s, b)) > State (s, b) datacons Return : >a, s. a > State (s, a) datacons Get : >s. State (s, s) datacons Put : >s. s > State (s, ()) \; let rec run_state = fun s -\> function \ \ \| Return a -\> (s, a) \ \ \| Get -\> (s, s) \ \ \| Put u -\> (u, ()) \ \ \| Bind (m, k) -\> \ \ \ \ let s1, a1 = run_state s m in \ \ \ \ run_state s1 (k a1) Value items from : <\code> val run_state : >a, b. a > State (a, b) > (a, b) These are the examples from falling outside the scope of algorithm >. > Example from , described on page 86. Source file : <\code> datatype Split : type * type datacons Whole : Split (Int, Int) datacons Parts : >a, b. Split ((Int, a), (b, Bool)) external let seven : Int = "7" external let three : Int = "3" \; let joint = function \ \ \| Whole -\ seven \ \ \| Parts -\ three, True Value items from : <\code> val joint : >a. Split (a, a) > a > Example from , described on page 88. Source file : <\code> (** Normally we would use [num], but this is a stress test for [type]. *) datatype Z datatype S : type datatype Balance : type * type * type datacons Less : >a. Balance (a, S a, S a) datacons Same : >a. Balance (a, a, a) datacons More : >a. Balance (S a, a, S a) datatype AVL : type datacons Leaf : AVL Z datacons Node : \ \ >a, b, c. Balance (a, b, c) * AVL a * Int * AVL b > AVL (S c) \; datatype Choice : type * type datacons Left : >a, b. a > Choice (a, b) datacons Right : >a, b. b > Choice (a, b) \; let rotr = fun z d -\ function \ \ \| Leaf -\ assert false \ \ \| Node (Less, a, x, Leaf) -\ assert false \ \ \| Node (Same, a, x, (Node (_,_,_,_) as b)) -\ \ \ \ \ Right (Node (Less, a, x, Node (More, b, z, d))) \ \ \| Node (More, a, x, (Node (_,_,_,_) as b)) -\ \ \ \ \ Left (Node (Same, a, x, Node (Same, b, z, d))) \ \ \| Node (Less, a, x, Node (Same, b, y, c)) -\ \ \ \ \ Left (Node (Same, Node (Same, a, x, b), y, Node (Same, c, z, d))) \ \ \| Node (Less, a, x, Node (Less, b, y, c)) -\ \ \ \ \ Left (Node (Same, Node (More, a, x, b), y, Node (Same, c, z, d))) \ \ \| Node (Less, a, x, Node (More, b, y, c)) -\ \ \ \ \ Left (Node (Same, Node (Same, a, x, b), y, Node (Less, c, z, d))) Value items from : <\code> val rotr : \ \ \ >a. \ \ \ Int > AVL a > AVL (S (S a)) > \ \ \ \ \ Choice (AVL (S (S a)), AVL (S (S (S a)))) > Example from , described on pages 212-213. Source file : <\code> (** Normally we would use [num], but this is a stress test for [type]. *) datatype Z datatype S : type (** This datatype definition is modified to make type inference for \ \ \ \ rotr, rotl, ins functions pointwise. *) datatype AVL : type datacons Tip : AVL Z datacons LNode : >a. AVL a * Int * AVL (S a) > AVL (S (S a)) datacons SNode : >a. AVL a * Int * AVL a > AVL (S a) datacons MNode : >a. AVL (S a) * Int * AVL a > AVL (S (S a)) \; datatype Choice : type * type datacons L : >a, b. a > Choice (a, b) datacons R : >a, b. b > Choice (a, b) \; datatype Zero : type datacons IsZ : Zero Z datacons NotZ : >a. Zero (S a) \; external rotl : \ \ >a. AVL a > Int > AVL (S (S a)) > Choice (AVL (S (S a)), \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ AVL (S (S (S a)))) \; external rotr : \ \ >a. AVL (S (S a)) > Int > AVL a > Choice (AVL (S (S a)), \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ AVL (S (S (S a)))) \; let empty = function \ \ \| Tip -\> IsZ \ \ \| LNode (_, _, _) -\> NotZ \ \ \| SNode (_, _, _) -\> NotZ \ \ \| MNode (_, _, _) -\> NotZ \; let rec delmin = function \ \ \| LNode (a, x, b) -\> \ \ \ \ (match empty a with \ \ \ \ \ \ \| IsZ -\> x, L b \ \ \ \ \ \ \| NotZ -\> \ \ \ \ \ \ \ \ (match delmin a with \ \ \ \ \ \ \ \ \ \ y, k -\> \ \ \ \ \ \ \ \ \ \ (match k with \ \ \ \ \ \ \ \ \ \ \ \ \| L a -\> y, rotl a x b \ \ \ \ \ \ \ \ \ \ \ \ \| R a -\> y, R (LNode (a, x, b))))) \ \ \| SNode (a, x, b) -\> \ \ \ \ (match empty a with \ \ \ \ \ \ \| IsZ -\> x, L b \ \ \ \ \ \ \| NotZ -\> \ \ \ \ \ \ \ \ (match delmin a with \ \ \ \ \ \ \ \ \ \ y, k -\> \ \ \ \ \ \ \ \ \ \ (match k with \ \ \ \ \ \ \ \ \ \ \ \ \| L a -\> y, R (LNode (a, x, b)) \ \ \ \ \ \ \ \ \ \ \ \ \| R a -\> y, R (SNode (a, x, b))))) \ \ \| MNode (a, x, b) -\> \ \ \ \ (match delmin a with \ \ \ \ \ \ y, k -\> \ \ \ \ \ \ (match k with \ \ \ \ \ \ \ \ \| L a -\> y, L (SNode (a, x, b)) \ \ \ \ \ \ \ \ \| R a -\> y, R (MNode (a, x, b)))) Value items from : <\code> val empty : >a. AVL a > Zero a \; val delmin : >a. AVL (S a) > (Int, Choice (AVL a, AVL (S a))) > Example from , described on pages 213-215. The only difference is that the original has fd2> as the fourth line of instead of our expanded (match fd2 with \| FDI -\> fd2 \| FDC _ -\> fd2 \| FDG _ -\> fd2)>. Source file : <\code> datatype FunDesc : type * type datacons FDI : >a. FunDesc (a, a) datacons FDC : >a, b. b > FunDesc (a, b) datacons FDG : >a, b. (a > b) > FunDesc (a, b) \; external fd_fun : >a, b. FunDesc (a, b) > a > b \; let fd_comp = fun fd1 fd2 -\> \ \ let o = fun f g x -\> f (g x) in \ \ match fd1 with \ \ \ \ \| FDI -\> (match fd2 with \| FDI -\> fd2 \| FDC _ -\> fd2 \| FDG _ -\> fd2) \ \ \ \ \| FDC b -\>\ \ \ \ \ \ \ (match fd2 with \ \ \ \ \ \ \ \ \| FDI -\> fd1 \ \ \ \ \ \ \ \ \| FDC c -\> FDC (fd_fun fd2 b) \ \ \ \ \ \ \ \ \| FDG g -\> FDC (fd_fun fd2 b)) \ \ \ \ \| FDG f -\> \ \ \ \ \ \ (match fd2 with \ \ \ \ \ \ \ \ \| FDI -\> fd1 \ \ \ \ \ \ \ \ \| FDC c -\> FDC c \ \ \ \ \ \ \ \ \| FDG g -\> FDG (o (fd_fun fd2) f)) Compare also the example : <\code> datatype FunDesc : type * type datacons FDI : >a. FunDesc (a, a) datacons FDC : >a, b. b > FunDesc (a, b) datacons FDG : >a, b. (a > b) > FunDesc (a, b) \; external fd_fun : >a, b. FunDesc (a, b) > a > b \; let o = fun f g x -\> f (g x) \; let fd_comp = \ \ function \ \ \ \ \| FDI -\> (function FDI -\> FDI \| FDC c -\> FDC c \| FDG g -\> FDG g) \ \ \ \ \| FDC b as fd1 -\> \ \ \ \ \ \ (function \ \ \ \ \ \ \ \ \| FDI -\> fd1 \ \ \ \ \ \ \ \ \| FDC c as fd2 -\> FDC (fd_fun fd2 b) \ \ \ \ \ \ \ \ \| FDG g as fd2 -\> FDC (fd_fun fd2 b)) \ \ \ \ \| FDG f as fd1 -\> \ \ \ \ \ \ (function \ \ \ \ \ \ \ \ \| FDI -\> fd1 \ \ \ \ \ \ \ \ \| FDC c -\> FDC c \ \ \ \ \ \ \ \ \| FDG g as fd2 -\> FDG (o (fd_fun fd2) f)) Value items from : <\code> val o : >a, b, c. (b > a) > (c > b) > c > a \; val fd_comp : \ \ \ >a, b, c. FunDesc (b, c) > FunDesc (c, a) > FunDesc (b, a) : -way > Example from , described on pages 216-217. The local definition of is a here because it needs to be polymorphic. Source file : <\code> datatype List : type datacons N : >a. List a datacons C : >a. a * List a > List a \; datatype Zip1 : type * type datacons Zero1 : >a. Zip1 (List a, List a) datacons Succ1 : \ \ >a, b, c. Zip1 (List a, b) > Zip1 (List (c > a), (List c > b)) \; external zip_with : >a, b, c. (a > b > c) > List a > List b > List c \; external repeat : >a. a > List a \; let zip1 = \ \ let rec apply = fun f x -\> f x in \ \ let rec z1 = fun fs -\> function \ \ \ \ \| Zero1 -\> fs \ \ \ \ \| Succ1 n2 -\> fun xs -\> z1 (zip_with apply fs xs) n2 in \ \ fun n f -\> z1 (repeat f) n Value items from : <\code> val zip1 : >a, b. Zip1 (List b, a) > b > a > Example from , described on pages 217-219. Source file , requires option for inference: <\code> datatype Z datatype S : type \; datatype Nat : type datacons Zn : Nat Z datacons Sn : >a. Nat a > Nat (S a) \; datatype NatLeq : type * type datacons LeZ : >a. NatLeq (Z, a) datacons LeS : >a, b. NatLeq (a, b) \ > NatLeq (S a, S b) \; let rec leq = function \ \ \| Zn -\> LeZ \ \ \| Sn n -\> LeS (leq n) Value items from : <\code> val leq : >a. Nat a > NatLeq (a, a) > Example from , described on pages 219-220. Source file : <\code> datatype State : type * type datacons Bind : \ \ >a, b, s. State (s, a) * (a > State (s, b)) > State (s, b) datacons Return : >a, s. a > State (s, a) datacons Get : >s. State (s, s) datacons Put : >s. s > State (s, ()) \; let rec run_state = fun s -\> function \ \ \| Return a -\> (s, a) \ \ \| Get -\> (s, s) \ \ \| Put u -\> (u, ()) \ \ \| Bind (m, k) -\> \ \ \ \ match m with \ \ \ \ \ \ \| Return a -\> run_state s (k a) \ \ \ \ \ \ \| Get -\> run_state s (k s) \ \ \ \ \ \ \| Put u -\> run_state u (k ()) \ \ \ \ \ \ \| Bind (n, j) -\> run_state s (Bind (n, fun x -\> Bind (j x, k))) Value items from : <\code> val run_state : >a, b. a > State (a, b) > (a, b) > Source file : <\code> datatype Term : type \; external let plus : Int > Int > Int = "(+)" external let is_zero : Int > Bool = "(=) 0" \; datacons Lit : Int > Term Int datacons Plus : Term Int * Term Int > Term Int datacons IsZero : Term Int > Term Bool datacons If : >a. Term Bool * Term a * Term a > Term a datacons Pair : >a, b. Term a * Term b > Term (a, b) datacons Fst : >a, b. Term (a, b) > Term a datacons Snd : >a, b. Term (a, b) > Term b \; let rec eval = function \ \ \| Lit i -\ i \ \ \| IsZero x -\ is_zero (eval x) \ \ \| Plus (x, y) -\ plus (eval x) (eval y) \ \ \| If (b, t, e) -\ (match eval b with True -\ eval t \| False -\ eval e) \ \ \| Pair (x, y) -\ eval x, eval y \ \ \| Fst p -\ (match eval p with x, y -\ x) \ \ \| Snd p -\ (match eval p with x, y -\ y) Value items from : <\code> val eval : >a. Term a > a Exported OCaml source file : <\code> type num = int type _ term = \ \ \| Lit : int -\> int term \ \ \| Plus : int term * int term -\> int term \ \ \| IsZero : int term -\> bool term \ \ \| If : (*>'a.*)bool term * 'a term * 'a term -\ 'a term \ \ \| Pair : (*>'a, 'b.*)'a term * 'b term -\ (('a * 'b)) term \ \ \| Fst : (*>'a, 'b.*)(('a * 'b)) term -\ 'a term \ \ \| Snd : (*>'a, 'b.*)(('a * 'b)) term -\ 'b term let plus : (int -\> int -\> int) = (+) let is_zero : (int -\> bool) = (=) 0 let rec eval : type a . (a term -\> a) = \ \ ((function Lit i -\> i \| IsZero x -\> is_zero (eval x) \ \ \ \ \| Plus (x, y) -\> plus (eval x) (eval y) \ \ \ \ \| If (b, t, e) -\> (if eval b then eval t else eval e) \ \ \ \ \| Pair (x, y) -\> (eval x, eval y) \ \ \ \ \| Fst p -\> let ((x, y): (a * _)) = eval p in x \ \ \ \ \| Snd p -\> let ((x, y): (_ * a)) = eval p in y): a term -\> a) > Source file : <\code> datatype Ty : type datatype List : type datacons Zero : Int datacons Nil : >a. List a datacons TInt : Ty Int datacons TPair : >a, b. Ty a * Ty b > Ty (a, b) datacons TList : >a. Ty a > Ty (List a) external let eq_int : Int > Int > Bool = "(=)" external let b_and : Bool > Bool > Bool = "(&&)" external let b_not : Bool > Bool = "not" external forall2 : >a, b. (a > b > Bool) > List a > List b > Bool \; let rec equal = function \ \ \| TInt, TInt -\ fun x y -\ eq_int x y \ \ \| TPair (t1, t2), TPair (u1, u2) -\ \ \ \ \ \ (fun (x1, x2) (y1, y2) -\ \ \ \ \ \ \ \ \ b_and (equal (t1, u1) x1 y1) \ \ \ \ \ \ \ \ \ \ \ \ \ \ (equal (t2, u2) x2 y2)) \ \ \| TList t, TList u -\ forall2 (equal (t, u)) \ \ \| _ -\ fun _ _ -\ False \ \ \| TInt, TList l -\ (function Nil -\ assert false) \ \ \| TList l, TInt -\ (fun _ -\ function Nil -\ assert false) Source file : <\code> datatype Ty : type datatype List : type datacons Nil : >a. List a datacons TInt : Ty Int datacons TPair : >a, b. Ty a * Ty b > Ty (a, b) datacons TList : >a. Ty a > Ty (List a) external let zero : Int = "0" external let eq_int : Int > Int > Bool = "(=)" external let b_and : Bool > Bool > Bool = "(&&)" external let b_not : Bool > Bool = "not" external forall2 : >a, b. (a > b > Bool) > List a > List b > Bool \; let rec equal = function \ \ \| TInt, TInt -\ fun x y -\ eq_int x y \ \ \| TPair (t1, t2), TPair (u1, u2) -\ \ \ \ \ \ (fun (x1, x2) (y1, y2) -\ \ \ \ \ \ \ \ \ b_and (equal (t1, u1) x1 y1) \ \ \ \ \ \ \ \ \ \ \ \ \ \ (equal (t2, u2) x2 y2)) \ \ \| TList t, TList u -\ forall2 (equal (t, u)) \ \ \| _ -\ fun _ _ -\ False test b_not (equal (TInt, TList TInt) zero Nil) Value items from : <\code> val equal : >a, b. (Ty a, Ty b) > a > b > Bool > Source file : <\code> datatype List : type * num datacons LNil : >a. List(a, 0) datacons LCons : >n, a [0>n]. a * List(a, n) > List(a, n+1) \; let head = function \ \ \| LCons (x, _) -\> x \ \ \| LNil -\> assert false Value items from : <\code> val head : >n, a[1 > n]. List (a, n) > a > This example is not featured in the directory. The natural solution would be to propagate one of the arguments when the other list is empty: (fun l -\ l) \|>> This currently leads to the problem of insufficient information about . We can expand all cases of both arguments: <\code> datatype Elem datatype List : num datacons LNil : List 0 datacons LCons : >n [0>n]. Elem * List n > List (n+1) \; let rec append = \ \ function LNil -\ (function LNil -\ LNil \| LCons (_,_) as l -\ l) \ \ \ \ \| LCons (x, xs) -\ \ \ \ \ \ \ (function LNil -\ LCons (x, append xs LNil) \ \ \ \ \ \ \ \ \| LCons (_,_) as l -\ LCons (x, append xs l)) Inferred type: <\code> val append : >n, k. List (a, k) > List (a, n) > List (n + k) We can also use assertions: <\code> let rec append = \ \ function \ \ \ \ \| LNil -\> \ \ \ \ \ \ (function l when (length l + 1) \= 0 -\> assert false \| l -\> l) \ \ \ \ \| LCons (x, xs) -\> \ \ \ \ \ \ (function l when (length l + 1) \= 0 -\> assert false \ \ \ \ \ \ \| l -\> LCons (x, append xs l)) Inferred type: <\code> val append : >n, k[0>n > 0>n + k]. List(a, k) > List(a, n) > List(n + k) > Source file : <\code> datatype List : type * num datacons LNil : >a. List(a, 0) datacons LCons : >n, a [0>n]. a * List(a, n) > List(a, n+1) \; let rec flatten_pairs = \ \ function LNil -\ LNil \ \ \ \ \| LCons ((x, y), l) -\ \ \ \ \ \ \ LCons (x, LCons (y, flatten_pairs l)) Value items from : <\code> val flatten_pairs : >n, a. List ((a, a), n) > List (a, 2 n) > Source file : <\code> datatype List : type * num datacons LNil : >a. List(a, 0) datacons LCons : >n, a [0>n]. a * List(a, n) > List(a, n+1) \; let rec filter = fun f -\ \ \ efunction LNil -\ LNil \ \ \ \ \| LCons (x, xs) -\ \ \ \ \ \ \ ematch f x with \ \ \ \ \ \ \ \ \| True -\ \ \ \ \ \ \ \ \ \ \ let ys = filter f xs in \ \ \ \ \ \ \ \ \ \ LCons (x, ys) \ \ \ \ \ \ \ \ \| False -\ \ \ \ \ \ \ \ \ \ \ filter f xs Value items from : <\code> val filter : \ \ \ >n, a. \ \ \ (a > Bool) > List (a, n) > >k[0 > k > k > n].List (a, k) > Source file : <\code> datatype List : type * num datacons LNil : >a. List(a, 0) datacons LCons : >n, a [0>n]. a * List(a, n) > List(a, n+1) \; let rec zip = \ \ efunction \ \ \ \ \| LNil, LNil -\ LNil \ \ \ \ \| LNil, LCons (_, _) -\ LNil \ \ \ \ \| LCons (_, _), LNil -\ LNil \ \ \ \ \| LCons (x, xs), LCons (y, ys) -\ \ \ \ \ \ \ let zs = zip (xs, ys) in \ \ \ \ \ \ LCons ((x, y), zs) The inferred type is: <\code> val >n, k, a, b. (List (a, n), List (b, k)) > \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ >i[i=min (k, n)].List ((a, b), i) > Source file : <\code> datatype Binary : num datatype Carry : num \; datacons Zero : Binary 0 datacons PZero : >n [0>n]. Binary n > Binary(2 n) datacons POne : >n [0>n]. Binary n > Binary(2 n + 1) \; datacons CZero : Carry 0 datacons COne : Carry 1 \; let rec plus = \ \ function CZero -\ \ \ \ \ (function \ \ \ \ \ \ \| Zero -\ \ \ \ \ \ \ \ \ (function Zero -\ Zero \ \ \ \ \ \ \ \ \ \ \| PZero _ as b -\ b \ \ \ \ \ \ \ \ \ \ \| POne _ as b -\ b) \ \ \ \ \ \ \| PZero a1 as a -\ \ \ \ \ \ \ \ \ (function Zero -\ a \ \ \ \ \ \ \ \ \ \ \| PZero b1 -\ PZero (plus CZero a1 b1) \ \ \ \ \ \ \ \ \ \ \| POne b1 -\ POne (plus CZero a1 b1)) \ \ \ \ \ \ \| POne a1 as a -\ \ \ \ \ \ \ \ \ (function Zero -\ a \ \ \ \ \ \ \ \ \ \ \| PZero b1 -\ POne (plus CZero a1 b1) \ \ \ \ \ \ \ \ \ \ \| POne b1 -\ PZero (plus COne a1 b1))) \ \ \ \ \| COne -\ \ \ \ \ (function Zero -\ \ \ \ \ \ \ \ \ (function Zero -\ POne(Zero) \ \ \ \ \ \ \ \ \ \ \| PZero b1 -\ POne b1 \ \ \ \ \ \ \ \ \ \ \| POne b1 -\ PZero (plus COne Zero b1)) \ \ \ \ \ \ \| PZero a1 -\ \ \ \ \ \ \ \ \ (function Zero -\ POne a1 \ \ \ \ \ \ \ \ \ \ \| PZero b1 -\ POne (plus CZero a1 b1) \ \ \ \ \ \ \ \ \ \ \| POne b1 -\ PZero (plus COne a1 b1)) \ \ \ \ \ \ \| POne a1 -\ \ \ \ \ \ \ \ \ (function Zero -\ PZero (plus COne a1 Zero) \ \ \ \ \ \ \ \ \ \ \| PZero b1 -\ PZero (plus COne a1 b1) \ \ \ \ \ \ \ \ \ \ \| POne b1 -\ POne (plus COne a1 b1))) Value items from : <\code> val plus : \ \ \ >i, k, n. Carry i > Binary k > Binary n > Binary (n + k + i) > This example is not featured in the directory. <\code> datatype Binary : num \; datacons Zero : Binary 0 datacons PZero : >n [0>n]. Binary n > Binary(2 n) datacons POne : >n [0>n]. Binary n > Binary(2 n + 1) \; let rec increment = \ \ function Zero -\ POne Zero \ \ \ \ \| PZero a1 -\ POne a1 \ \ \ \ \| POne a1 -\ PZero (increment a1) Inferred type: <\code> val increment : >n. Binary n > Binary (n + 1) > For brevity, the function is named rather than in the code example. Source file : <\code> datatype Binary : num datacons Zero : Binary 0 datacons PZero : >n [0>n]. Binary n > Binary(2 n) datacons POne : >n [0>n]. Binary n > Binary(2 n + 1) \; let rec ub = efunction \ \ \| Zero -\ \ \ \ \ \ \ (efunction Zero -\ Zero \ \ \ \ \ \ \ \ \| PZero b1 as b -\ b \ \ \ \ \ \ \ \ \| POne b1 as b -\ b) \ \ \| PZero a1 as a -\ \ \ \ \ \ \ (efunction Zero -\ a \ \ \ \ \ \ \ \ \| PZero b1 -\ \ \ \ \ \ \ \ \ \ \ let r = ub a1 b1 in \ \ \ \ \ \ \ \ \ \ PZero r \ \ \ \ \ \ \ \ \| POne b1 -\ \ \ \ \ \ \ \ \ \ \ let r = ub a1 b1 in \ \ \ \ \ \ \ \ \ \ POne r) \ \ \| POne a1 as a -\ \ \ \ \ \ \ (efunction Zero -\ a \ \ \ \ \ \ \ \ \| PZero b1 -\ \ \ \ \ \ \ \ \ \ \ let r = ub a1 b1 in \ \ \ \ \ \ \ \ \ \ POne r \ \ \ \ \ \ \ \ \| POne b1 -\ \ \ \ \ \ \ \ \ \ \ let r = ub a1 b1 in \ \ \ \ \ \ \ \ \ \ POne r) Value items from\ <\code> val plus : \ \ \ >i, k, n. Carry i > Binary k > Binary n > Binary (n + k + i) Source file : <\code> (** We follow the AVL tree algorithm from OCaml Standard Library, where\ \ \ \ \ the branches of a node are allowed to differ in height by at most 2. *) \; datatype Avl : type * num datacons Empty : >a. Avl (a, 0) datacons Node : \ \ >a,k,m,n [k=max(m,n) > 0>m > 0>n > n>m+2 > m>n+2]. \ \ \ \ \ Avl (a, m) * a * Avl (a, n) * Num (k+1) > Avl (a, k+1) \; datatype LinOrder datacons LT : LinOrder datacons EQ : LinOrder datacons GT : LinOrder external let compare : >a. a > a > LinOrder = \ \ "fun x y -\> let c=Pervasives.compare x y in \ \ \ \ \ \ \ \ \ \ \ \ \ \ if c\0 then LT else if c=0 then EQ else GT" \; let height = function \ \ \| Empty -\> 0 \ \ \| Node (_, _, _, k) -\> k \; let create = fun l x r -\> \ \ eif height l \= height r then Node (l, x, r, height r + 1) \ \ else Node (l, x, r, height l + 1) \; let singleton x = Node (Empty, x, Empty, 1) \; let rotr = fun l x r -\> \ \ \ \ ematch l with \ \ \ \ \| Empty -\> assert false \ \ \ \ \| Node (ll, lx, lr, _) -\> \ \ \ \ \ \ eif height lr \= height ll then \ \ \ \ \ \ \ \ let r' = create lr x r in \ \ \ \ \ \ \ \ create ll lx r' \ \ \ \ \ \ else \ \ \ \ \ \ \ \ ematch lr with \ \ \ \ \ \ \ \ \| Empty -\> assert false \ \ \ \ \ \ \ \ \| Node (lrl, lrx, lrr, _) -\> \ \ \ \ \ \ \ \ \ \ let l' = create ll lx lrl in \ \ \ \ \ \ \ \ \ \ let r' = create lrr x r in \ \ \ \ \ \ \ \ \ \ create l' lrx r' \; let rotl = fun l x r -\> \ \ \ \ ematch r with \ \ \ \ \| Empty -\> assert false \ \ \ \ \| Node (rl, rx, rr, _) -\> \ \ \ \ \ \ eif height rl \= height rr then \ \ \ \ \ \ \ \ let l' = create l x rl in \ \ \ \ \ \ \ \ create l' rx rr \ \ \ \ \ \ else \ \ \ \ \ \ \ \ ematch rl with \ \ \ \ \ \ \ \ \| Empty -\> assert false \ \ \ \ \ \ \ \ \| Node (rll, rlx, rlr, _) -\> \ \ \ \ \ \ \ \ \ \ let l' = create l x rll in \ \ \ \ \ \ \ \ \ \ let r' = create rlr rx rr in \ \ \ \ \ \ \ \ \ \ create l' rlx r' \; let rec add x = efunction \ \ \| Empty -\> Node (Empty, x, Empty, 1) \ \ \| Node (l, y, r, h) -\> \ \ \ \ ematch compare x y, height l, height r with \ \ \ \ \| EQ, _, _ -\> Node (l, x, r, h) \ \ \ \ \| LT, hl, hr -\> \ \ \ \ \ \ let l' = add x l in \ \ \ \ \ \ eif height l' \= hr+2 then create l' y r else rotr l' y r \ \ \ \ \| GT, hl, hr -\> \ \ \ \ \ \ let r' = add x r in \ \ \ \ \ \ eif height r' \= hl+2 then create l y r' else rotl l y r' \; let rec mem x = function \ \ \| Empty -\> False \ \ \| Node (l, y, r, _) -\> \ \ \ \ match compare x y with \ \ \ \ \| LT -\> mem x l \ \ \ \ \| EQ -\> True \ \ \ \ \| GT -\> mem x r \; let rec min_binding = function \ \ \| Empty -\> assert false \ \ \| Node (Empty, x, r, _) -\> x \ \ \| Node ((Node (_,_,_,_) as l), x, r, _) -\> min_binding l \; let rec remove_min_binding = efunction \ \ \| Empty -\> assert false \ \ \| Node (Empty, x, r, _) -\> r \ \ \| Node ((Node (_,_,_,_) as l), x, r, _) -\> \ \ \ \ let l' = remove_min_binding l in \ \ \ \ eif height r \= height l' + 2 then create l' x r \ \ \ \ else rotl l' x r \; let merge = efunction \ \ \| Empty, Empty -\> Empty \ \ \| Empty, (Node (_,_,_,_) as t) -\> t \ \ \| (Node (_,_,_,_) as t), Empty -\> t \ \ \| (Node (_,_,_,_) as t1), (Node (_,_,_,_) as t2) -\> \ \ \ \ let x = min_binding t2 in \ \ \ \ let t2' = remove_min_binding t2 in \ \ \ \ eif height t1 \= height t2' + 2 then create t1 x t2' \ \ \ \ else rotr t1 x t2' \; let rec remove = fun x -\> efunction \ \ \| Empty -\> Empty \ \ \| Node (l, y, r, h) -\> \ \ \ \ ematch compare x y with \ \ \ \ \| EQ -\> merge (l, r) \ \ \ \ \| LT -\> \ \ \ \ \ \ let l' = remove x l in \ \ \ \ \ \ eif height r \= height l' + 2 then create l' y r \ \ \ \ \ \ else rotl l' y r \ \ \ \ \| GT -\> \ \ \ \ \ \ let r' = remove x r in \ \ \ \ \ \ eif height l \= height r' + 2 then create l y r' \ \ \ \ \ \ else rotr l y r' Value items from : <\code> val height : >n, a. Avl (a, n) > Num n \; val create : \ \ \ >k, n, a[0 > n > 0 > k > n > k + 2 > k > n + 2]. \ \ \ Avl (a, k) > a > Avl (a, n) > >i[i=max (k + 1, n + 1)].Avl (a, i) \; val singleton : >a. a > Avl (a, 1) \; val rotr : \ \ \ >k, n, a[0 > n > n + 2 > k > k > n + 3]. \ \ \ Avl (a, k) > a > Avl (a, n) > >n[k > n > \ \ \ \ \ n > k + 1].Avl (a, n) \; val rotl : \ \ \ >k, n, a[0 > k > n > k + 3 > k + 2 > n]. \ \ \ Avl (a, k) > a > Avl (a, n) > >k[k > n + 1 > \ \ \ \ \ n > k].Avl (a, k) \; val add : \ \ \ >n, a. \ \ \ a > Avl (a, n) > >k[1 > k > n > k > k > n + 1].Avl (a, k) \; val mem : >n, a. a > Avl (a, n) > Bool \; val min_binding : >n, a[1 > n]. Avl (a, n) > a \; val remove_min_binding : \ \ \ >n, a[1 > n]. \ \ \ Avl (a, n) > >k[n > k + 1 > k > n > k + 2 > 2 n].Avl (a, k) \; val merge : \ \ \ >k, n, a[n > k + 2 > k > n + 2]. \ \ \ (Avl (a, n), Avl (a, k)) > >i[n > i > k > i > i > n + k > \ \ \ \ \ i>max (k + 1, n + 1)].Avl (a, i) \; val remove : \ \ \ >n, a. \ \ \ a > Avl (a, n) > >k[n > k + 1 > 0 > k > k > n].Avl (a, k) For clarity, we present the array and matrix operations prelude separately here. Arrays are polymorphic, matrices only store floating point numbers. <\code> datatype Array : type * num external let array_make : \ \ >n, a [0>n]. Num n > a > Array (a, n) = "fun a b -\ Array.make a b" external let array_get : \ \ >n, k, a [0>k > k+1>n]. Array (a, n) > Num k > a = "fun a b -\ Array.get a b" external let array_set : \ \ >n, k, a [0>k > k+1>n]. Array (a, n) > Num k > a > () = \ \ "fun a b c -\> Array.set a b c" external let array_length : \ \ >n, a. Array (a, n) > Num n = "fun a -\ Array.length a" \; external type Matrix : num * num = \ \ "(int, Bigarray.int_elt, Bigarray.c_layout) Bigarray.Array2.t" external let matrix_make : \ \ >n, k [0>n > 0>k]. Num n > Num k > Matrix (n, k) = \ \ "fun a b -\> Bigarray.Array2.create Bigarray.int Bigarray.c_layout a b" external let matrix_get : \ \ >n, k, i, j [0>i > i+1>n > 0>j > j+1>k]. \ \ \ Matrix (n, k) > Num i > Num j > Int = "Bigarray.Array2.get" external let matrix_set : \ \ >n, k, i, j [0>i > i+1>n > 0>j > j+1>k]. \ \ \ Matrix (n, k) > Num i > Num j > Int > () = "Bigarray.Array2.set" external let matrix_dim1 : \ \ >n, k [0>n > 0>k]. Matrix (n, k) > Num n = "Bigarray.Array2.dim1" external let matrix_dim2 : \ \ >n, k [0>n > 0>k]. Matrix (n, k) > Num k = "Bigarray.Array2.dim2" > Source file : <\code> external let add : Int > Int > Int = "fun n k -\ n + k" external let prod : Int > Int > Int = "fun n k -\ n * k" external let int0 : Int = "0" \; let dotprod v1 v2 = \ \ let rec loop n sum i = \ \ \ \ if n \= i then sum else \ \ \ \ \ \ \ \ loop n (add (prod (array_get v1 i) (array_get v2 i)) sum) \ \ \ \ \ \ \ \ \ \ (i + 1) in \ \ loop (array_length v1) int0 0 Value items from : <\code> val dotprod : >k, n[k > n]. Array (Int, k) > Array (Int, n) > Int > Source file : <\code> let rec bcopy_aux src des = function \ \ \| i, m when m \= i -\> () \ \ \| i, m when i+1 \= m -\> \ \ \ \ \ \ let n = array_get src i in \ \ \ \ \ \ array_set des i n; \ \ \ \ \ \ let j = i + 1 in \ \ \ \ \ \ bcopy_aux src des (j, m) \; let bcopy src des = \ \ let sz = array_length src in \ \ bcopy_aux src des (0, sz) Value items from : <\code> val bcopy_aux : \ \ \ >i, j, k, n, a[0 > n > k > i > k > j]. \ \ \ Array (a, j) > Array (a, i) > (Num n, Num k) > () \; val bcopy : >k, n, a[k > n]. Array (a, k) > Array (a, n) > () > Source file : <\code> datatype LinOrder datacons LE : LinOrder datacons GT : LinOrder datacons EQ : LinOrder \; external let compare : >a. a > a > LinOrder = \ \ "fun a b -\> let c = Pervasives.compare a b in \ \ \ \ \ \ \ \ \ \ \ \ \ \ if c \ 0 then LE else if c \> 0 then GT else EQ" external let equal : >a. a > a > Bool = "fun a b -\ a = b" \; external let div2 : >n. Num (2 n) > Num n = "fun x -\ x / 2" \; datatype Answer : type datacons NotFound : >a. Answer a datacons Found : >a. a > Answer a \; let bsearch key vec = \ \ let rec look lo hi = \ \ \ \ if lo \= hi then \ \ \ \ \ \ \ \ let m = div2 (hi + lo) in \ \ \ \ \ \ \ \ let x = array_get vec m in \ \ \ \ \ \ \ \ match compare key x with \ \ \ \ \ \ \ \ \ \ \| LE -\> look lo (m + (-1)) \ \ \ \ \ \ \ \ \ \ \| GT -\> look (m + 1) hi \ \ \ \ \ \ \ \ \ \ \| EQ -\> if equal key x then Found x else NotFound \ \ \ \ else NotFound in \ \ look 0 (array_length vec + (-1)) Value items from : <\code> val bsearch : >n, a[0 > n]. a > Array (a, n) > Answer a > Source file : <\code> datatype LinOrder datacons LE : LinOrder datacons GT : LinOrder datacons EQ : LinOrder \; external let compare : >a. a > a > LinOrder = \ \ "fun a b -\> let c = Pervasives.compare a b in \ \ \ \ \ \ \ \ \ \ \ \ \ \ if c \ 0 then LE else if c \> 0 then GT else EQ" external let equal : >a. a > a > Bool = "fun a b -\ a = b" \; external let div2 : >n. Num (2 n) > Num n = "fun x -\ x / 2" \; let bsearch key = efunction vec -\> \ \ let rec look key vec lo hi = \ \ \ \ assert num -1 \= hi; \ \ \ \ eif lo \= hi then \ \ \ \ \ \ \ \ let m = div2 (hi + lo) in \ \ \ \ \ \ \ \ let x = array_get vec m in \ \ \ \ \ \ \ \ ematch compare key x with \ \ \ \ \ \ \ \ \ \ \| LE -\> look key vec lo (m + (-1)) \ \ \ \ \ \ \ \ \ \ \| GT -\> look key vec (m + 1) hi \ \ \ \ \ \ \ \ \ \ \| EQ -\> eif equal key x then m else -1 \ \ \ \ else -1 in \ \ look key vec 0 (array_length vec + (-1)) Value items from : <\code> val bsearch : \ \ \ >n, a[0 > n]. \ \ \ a > Array (a, n) > >k[0 > k + 1 > k + 1 > n].Num k Exported OCaml source : <\code> type num = int (** type _ array = built-in *) let array_make : (*0 > n*) ((* n *) num -\ 'a -\ ('a (* n *)) array) = \ \ fun a b -\> Array.make a b let array_get : \ \ (*0 > k > k + 1 > n*) (('a (* n *)) array -\ (* k *) num -\ 'a) = \ \ fun a b -\> Array.get a b let array_set : \ \ (*0 > k > k + 1 > n*) \ \ (('a (* n *)) array -\> (* k *) num -\> 'a -\> unit) = \ \ fun a b c -\> Array.set a b c let array_length : (*0 > n*) (('a (* n *)) array -\ (* n *) num) = \ \ fun a -\> Array.length a type linOrder = \ \ \| LE : linOrder \ \ \| GT : linOrder \ \ \| EQ : linOrder let compare : ('a -\> 'a -\> linOrder) = \ \ fun a b -\> let c = Pervasives.compare a b in \ \ \ \ \ \ \ \ \ \ \ \ \ \ if c \< 0 then LE else if c \> 0 then GT else EQ let equal : ('a -\> 'a -\> bool) = fun a b -\> a = b let div2 : ((* 2 n *) num -\> (* n *) num) = fun x -\> x / 2 type ex4 = \ \ \| Ex4 : (*>'k, 'n[0 > k + 1 > k + 1 > n].*)(* k *) num -\ \ \ \ \ (* n *) ex4 type ex3 = \ \ \| Ex3 : (*>'k, 'n[0 > k + 1 > k > n].*)(* k *) num -\ (* n *) ex3 let bsearch \ \ : type (*n*) a (*0 > n*). (a -\ (a (* n *)) array -\ (* n *) ex4) = \ \ (fun key vec -\> \ \ \ \ let Ex3 xcase = \ \ \ \ let rec look : \ \ \ \ type (*i*) (*j*) (*k*) b (*0 > k + 1 > 0 > i > \ \ \ \ k + 1 > j*). (b -\ (b (* j *)) array -\ (* i *) num -\ (* k *) num -\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ (* k *) ex3) \ \ \ \ = \ \ \ \ (fun key vec lo hi -\> \ \ \ \ \ \ (if lo \= hi then \ \ \ \ \ \ let m = div2 (hi + lo) in \ \ \ \ \ \ let x = array_get vec m in \ \ \ \ \ \ (((match (compare key x: linOrder) with \ \ \ \ \ \ LE -\> let Ex3 xcase = look key vec lo (m + -1) in Ex3 xcase \ \ \ \ \ \ \ \ \| GT -\> let Ex3 xcase = look key vec (m + 1) hi in Ex3 xcase \ \ \ \ \ \ \ \ \| EQ -\> \ \ \ \ \ \ \ \ \ \ \ \ (if equal key x then let xcase = m in Ex3 xcase else \ \ \ \ \ \ \ \ \ \ \ \ let xcase = -1 in Ex3 xcase))) : \ \ \ \ \ \ (* k *) ex3) else let xcase = -1 in Ex3 xcase)) in \ \ \ \ look key vec 0 (array_length vec + -1) in Ex4 xcase) > Source file : <\code> external let n2i : >n. Num n > Int = "fun i -\ i" external let equal : >a. a > a > Bool = "fun x y -\ x = y" external let leq : >a. a > a > Bool = "fun x y -\ x \= y" \; external let print : String > () = "print_string" external let string_make : Int > String > String = \ \ "fun n s -\> String.make n s.[0]" external let abs : Int > Int = "fun i -\ if i \ 0 then ~-i else i" external let minus : Int > Int > Int = "(-)" external let plus : Int > Int > Int = "(+)" \; let queens size = \ \ let board = array_make size (n2i 0) in \ \ let print_row pos = \ \ \ \ print (string_make (minus pos (n2i 1)) "."); print "Q"; \ \ \ \ print (string_make (minus (n2i size) pos) ".") in \ \ let print_queens () = \ \ \ \ let rec aux row = \ \ \ \ \ \ if size \= row then () \ \ \ \ \ \ else (print_row (array_get board row); aux (row + 1)) in \ \ \ \ aux 0 in \ \ let rec solved j = \ \ \ \ let q2j = array_get board j in \ \ \ \ let rec aux i = \ \ \ \ \ \ if i + 1 \= j then \ \ \ \ \ \ \ \ let q2i = array_get board i in \ \ \ \ \ \ \ \ let qdiff = abs (minus q2j q2i) in \ \ \ \ \ \ \ \ if equal q2i q2j then False \ \ \ \ \ \ \ \ else if equal qdiff (n2i (j - i)) then False \ \ \ \ \ \ \ \ else aux (i + 1) \ \ \ \ \ \ else True in \ \ \ \ aux 0 in \ \ let rec loop row = \ \ \ \ let next = plus (array_get board row) (n2i 1) in \ \ \ \ if leq (n2i (size + 1)) next then ( \ \ \ \ \ \ array_set board row (n2i 0); \ \ \ \ \ \ if row \= 0 then () else loop (row - 1)) \ \ \ \ else ( \ \ \ \ \ \ array_set board row next; \ \ \ \ \ \ if solved row then \ \ \ \ \ \ \ \ if size \= row + 1 then (print_queens (); loop row) \ \ \ \ \ \ \ \ else loop (row + 1) \ \ \ \ \ \ else loop row) in \ \ loop 0 Value items from : <\code> val queens : >n[1 > n]. Num n > () > Source file : <\code> let swap_interval arr start middle n = \ \ let rec item i = array_get arr i in \ \ let rec swap i j = \ \ \ \ let tmpj = item j in \ \ \ \ let tmpi = item i in \ \ \ \ array_set arr i tmpj; array_set arr j tmpi in \ \ let rec vecswap i j n = \ \ \ \ if n \= 0 then () else ( \ \ \ \ \ \ swap i j; vecswap (i + 1) (j + 1) (n - 1)) in \ \ vecswap start middle n Value items from : <\code> val swap_interval : \ \ \ >i, j, k, n, a[1 > j > 0 > n > 0 > k > i + k > j > \ \ \ i + n > j]. Array (a, j) > Num n > Num k > Num i > () > Source file : <\code> datatype LinOrder datacons LE : LinOrder datacons GT : LinOrder datacons EQ : LinOrder \; external let compare : >a. a > a > LinOrder = \ \ "fun a b -\> let c = Pervasives.compare a b in \ \ \ \ \ \ \ \ \ \ \ \ \ \ if c \ 0 then LE else if c \> 0 then GT else EQ" external let equal : >a. a > a > Bool = "fun a b -\ a = b" \; let rec insertSort arr start n = \ \ let rec item i = array_get arr i in \ \ let rec swap i j = \ \ \ \ let tmpj = item j in \ \ \ \ let tmpi = item i in \ \ \ \ array_set arr i tmpj; array_set arr j tmpi in \ \ let rec outer i = \ \ \ \ if start + n \= i then () \ \ \ \ else \ \ \ \ \ \ let rec inner j = \ \ \ \ \ \ \ \ if j \= start then outer (i + 1) \ \ \ \ \ \ \ \ else if equal (compare (item j) (item (j - 1))) LE \ \ \ \ \ \ \ \ then (swap j (j - 1); inner (j - 1)) \ \ \ \ \ \ \ \ else outer (i + 1) in \ \ \ \ \ \ inner i in \ \ outer (start + 1) Value items from : <\code> val insertSort : \ \ \ >i, k, n, a[0 > k > 1 > i > k + n > i]. \ \ \ Array (a, i) > Num k > Num n > () > Source file : <\code> external let n2i : >n. Num n > Int = "fun i -\ i" external let equal : >a. a > a > Bool = "fun x y -\ x = y" external let leq : >a. a > a > Bool = "fun x y -\ x \= y" \; external let print : String > () = "print_string" external let string_make : Int > String > String = \ \ "fun n s -\> String.make n s.[0]" external let string_of_int : Int > String = "string_of_int" \; external let abs : Int > Int = "fun i -\ if i \ 0 then ~-i else i" external let minus : Int > Int > Int = "(-)" external let plus : Int > Int > Int = "(+)" external let int0 : Int = "0" \; let play sz = \ \ let leftPost = array_make sz int0 in \ \ let middlePost = array_make sz int0 in \ \ let rightPost = array_make sz int0 in \; \ \ let initialize post = \ \ \ \ let rec init_rec i = \ \ \ \ \ \ if i + 1 \= sz - 1 then ( \ \ \ \ \ \ \ \ array_set post i (n2i (i+1)); \ \ \ \ \ \ \ \ init_rec (i+1)) \ \ \ \ \ \ else () in \ \ \ \ init_rec 0 in \; \ \ let showpiece n = \ \ \ \ let rec r_rec i = \ \ \ \ \ \ if leq (plus i (n2i 2)) n then ( \ \ \ \ \ \ \ \ print " "; r_rec (plus i (n2i 1))) \ \ \ \ \ \ else () in \ \ \ \ let rec r2_rec j = \ \ \ \ \ \ if leq (plus j (n2i 1)) (n2i sz) \ \ \ \ \ \ then (print "#"; r2_rec (plus j (n2i 1))) \ \ \ \ \ \ else () in \ \ \ \ r_rec (n2i 1); \ \ \ \ r2_rec (plus n (n2i 1)) in \; \ \ let showposts () = \ \ \ \ let rec show_rec i = \ \ \ \ \ \ if i + 1 \= sz - 1 then ( \ \ \ \ \ \ \ \ showpiece (array_get leftPost i); print " "; \ \ \ \ \ \ \ \ showpiece (array_get middlePost i); print " "; \ \ \ \ \ \ \ \ showpiece (array_get rightPost i); print "\\n"; \ \ \ \ \ \ \ \ show_rec (i+1)) \ \ \ \ \ \ else () in \ \ \ \ show_rec 0; print "\\n" in \; \ \ initialize leftPost; \ \ let rec move n source s post p post' p' = \ \ \ \ if n \= 1 then ( \ \ \ \ \ \ array_set post (p - 1) (array_get source s); \ \ \ \ \ \ array_set source s int0; showposts ()) \ \ \ \ else ( \ \ \ \ \ \ move (n - 1) source s post' p' post p; \ \ \ \ \ \ array_set post (p - 1) (array_get source (s + n - 1)); \ \ \ \ \ \ array_set source (s + n - 1) int0; \ \ \ \ \ \ showposts (); \ \ \ \ \ \ move (n - 1) post' ((p' - n) + 1) post (p - 1) source (s + n)) in \; \ \ showposts (); \ \ move sz leftPost 0 rightPost sz middlePost sz Value items from : <\code> val play : >n[1 > n]. Num n > () > Source file : <\code> external let n2i : >n. Num n > Int = "fun i -\ i" external let equal : >a. a > a > Bool = "fun x y -\ x = y" external let leq : >a. a > a > Bool = "fun x y -\ x \= y" \; external let abs : Int > Int = "fun i -\ if i \ 0 then ~-i else i" external let minus : Int > Int > Int = "(-)" external let plus : Int > Int > Int = "(+)" external let mult : Int > Int > Int = "( * )" external let int0 : Int = "0" \; let fillar arr2 fill = \ \ let d1 = matrix_dim1 arr2 in \ \ let d2 = matrix_dim2 arr2 in \ \ let rec loop i = \ \ \ \ if i + 1 \= d1\ \ \ \ \ then \ \ \ \ \ \ let rec loopi j = \ \ \ \ \ \ \ \ if j + 1 \= d2 then ( \ \ \ \ \ \ \ \ \ \ matrix_set arr2 i j (fill ()); \ \ \ \ \ \ \ \ \ \ loopi (j + 1)) \ \ \ \ \ \ \ \ else () in \ \ \ \ \ \ loopi 0 \ \ \ \ else loop (i + 1) in \ \ loop 0 \; let matmul a b = \ \ let p = matrix_dim1 a in \ \ let q = matrix_dim2 a in \ \ let r = matrix_dim2 b in \; \ \ let cdata = matrix_make p r in \ \ let callback0 () = int0 in \ \ fillar cdata callback0; \; \ \ let rec loop1 i = \ \ \ \ if i + 1 \= p then ( \ \ \ \ \ \ let rec loop2 j = \ \ \ \ \ \ \ \ if j + 1 \= r then ( \ \ \ \ \ \ \ \ \ \ let rec loop3 k sum = \ \ \ \ \ \ \ \ \ \ \ \ if k + 1 \= q then ( \ \ \ \ \ \ \ \ \ \ \ \ \ \ let sum_p = \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ plus sum (mult (matrix_get a i k) (matrix_get b k j)) in \ \ \ \ \ \ \ \ \ \ \ \ \ \ loop3 (k + 1) sum_p) \ \ \ \ \ \ \ \ \ \ \ \ else sum in \ \ \ \ \ \ \ \ \ \ let l3 = loop3 0 int0 in \ \ \ \ \ \ \ \ \ \ matrix_set cdata i j l3; \ \ \ \ \ \ \ \ \ \ loop2 (j + 1)) \ \ \ \ \ \ \ \ else () in \ \ \ \ \ \ loop2 0; \ \ \ \ \ \ loop1 (i + 1)) \ \ \ \ else () in \ \ loop1 0; \ \ cdata Value items from : <\code> val fillar : \ \ \ >k, n[0 > n > 0 > k]. Matrix (n, k) > (() > Int) > () \; val matmul : \ \ \ >i, j, k, n[0 > n > 0 > k > 0 > j > j > i]. \ \ \ Matrix (n, j) > Matrix (i, k) > Matrix (n, k) > Source file : <\code> external let div2 : >n. Num (2 n) > Num n = "fun x -\ x / 2" \; external let n2i : >n. Num n > Int = "fun i -\ i" external let equal : >a. a > a > Bool = "fun x y -\ x = y" external let leq : >a. a > a > Bool = "fun x y -\ x \= y" external let less : >a. a > a > Bool = "fun x y -\ x \ y" \; external let print : String > () = "print_string" external let string_make : Int > String > String = \ \ "fun n s -\> String.make n s.[0]" external let string_of_int : Int > String = "string_of_int" \; external let abs : Int > Int = "fun i -\ if i \ 0 then ~-i else i" external let minus : Int > Int > Int = "(-)" external let plus : Int > Int > Int = "(+)" external let int0 : Int = "0" \; let rec heapify size data i = \ \ let left = 2 * i + 1 in \ \ let right = 2 * i + 2 in \ \ let largest1 = \ \ \ \ eif left + 1 \= size then \ \ \ \ \ \ eif less (array_get data i) (array_get data left) \ \ \ \ \ \ then left else i \ \ \ \ else i in \ \ let largest2 = \ \ \ \ eif right + 1 \= size then \ \ \ \ \ \ eif less (array_get data largest1) (array_get data right) then right \ \ \ \ \ \ else largest1 \ \ \ \ else largest1 in \ \ if i + 1 \= largest2 then \ \ \ \ let temp = array_get data i in \ \ \ \ let temp2 = array_get data largest2 in \ \ \ \ array_set data i temp2; \ \ \ \ array_set data largest2 temp; \ \ \ \ heapify size data largest2 \ \ else () (* We do not get the constraint [i + 1 \<= size], because if [i] is larger, \ \ \ the last [else] branch is entered. *) \; let buildheap size data = \ \ let rec loop i = \ \ \ \ if 0 \= i then ( \ \ \ \ \ \ heapify size data i; \ \ \ \ \ \ loop (i - 1)) \ \ \ \ else () in \ \ loop (div2 size - 1) \; let heapsort maxx size data = \ \ buildheap size data; \ \ let rec loop i = \ \ \ \ if 1 \= i then \ \ \ \ \ \ let temp = array_get data i in \ \ \ \ \ \ array_set data i (array_get data 0); \ \ \ \ \ \ array_set data 0 temp; \ \ \ \ \ \ heapify i data 0; \ \ \ \ \ \ loop (i - 1) \ \ \ \ else () in \ \ loop (maxx - 1) \; let print_array data i j = \ \ let rec loop k = \ \ \ \ if k + 1 \= j then ( \ \ \ \ \ \ print (array_get data k); \ \ \ \ \ \ loop (k + 1)) \ \ \ \ else () in \ \ loop i Value items from : <\code> val heapify : \ \ \ >i, k, n, a[0 > n > i > k]. \ \ \ Num i > Array (a, k) > Num n > () \; val buildheap : >k, n, a[k > n]. Num k > Array (a, n) > () \; val heapsort : \ \ \ >i, k, n, a[k > n > i > k]. \ \ \ Num i > Num k > Array (a, n) > () \; val print_array : \ \ \ >i, k, n[k > i > 0 > n]. \ \ \ Array (String, i) > Num n > Num k > () > Source file : <\code> external let n2f : >n. Num n > Float = "float_of_int" external let equal : >a. a > a > Bool = "fun x y -\ x = y" external let leq : >a. a > a > Bool = "fun x y -\ x \= y" external let less : >a. a > a > Bool = "fun x y -\ x \ y" \; external let minus : Float > Float > Float = "(-.)" external let plus : Float > Float > Float = "(+.)" external let mult : Float > Float > Float = "( *. )" external let div : Float > Float > Float = "( /. )" external let fl0 : Float = "0.0" \; (* step 1 *) \; let rec is_neg_aux a j = \ \ if j + 2 \= matrix_dim2 a then \ \ \ \ if less (matrix_get a 0 j) fl0 then True \ \ \ \ else is_neg_aux a (j+1) \ \ else False \; let is_neg a = is_neg_aux a 1 \; (* step 2 *) \; let rec unb1 a i j = \ \ let rec unb2 a i j = \ \ \ \ if i + 1 \= matrix_dim1 a then \ \ \ \ \ \ if less (matrix_get a i j) fl0 \ \ \ \ \ \ then unb2 a (i+1) j \ \ \ \ \ \ else unb1 a 0 (j+1) \ \ \ \ else True in \; \ \ if j + 2 \= matrix_dim2 a then \ \ \ \ if less (matrix_get a 0 j) fl0 \ \ \ \ then unb2 a (i+1) j \ \ \ \ else unb1 a 0 (j+1) \ \ else False \; (* step 6 *) \; let rec norm_aux a i c j = \ \ if j + 1 \= matrix_dim2 a then ( \ \ \ \ matrix_set a i j (div (matrix_get a i j) c); \ \ \ \ norm_aux a i c (j+1)) \ \ else () \; let rec norm a i j = \ \ let c = matrix_get a i j in \ \ norm_aux a i c 1 \; let rec row_op_aux1 a i i' c j = \ \ if j + 1 \= matrix_dim2 a then \ \ \ \ matrix_set a i' j \ \ \ \ \ \ (minus (matrix_get a i' j) \ \ \ \ \ \ \ \ (mult (matrix_get a i j) c)); \ \ \ \ row_op_aux1 a i i' c (j+1) \ \ else () \; let rec row_op_aux2 a i i' j = \ \ row_op_aux1 a i i' (matrix_get a i' j) 1 \; let rec row_op_aux3 a i j i' = \ \ if i' + 1 \= matrix_dim1 a then \ \ \ \ if i' \= i && i \= i' then ( \ \ \ \ \ \ row_op_aux2 a i i' j; \ \ \ \ \ \ row_op_aux3 a i j (i'+1)) \ \ \ \ else row_op_aux3 a i j (i'+1) \ \ else () \; let rec row_op a i j = \ \ norm a i j; \ \ row_op_aux3 a i j 0 \; let rec simplex a = \; \ \ (* step 3 *) \; \ \ let rec enter_var j c j' = \ \ \ \ eif j' + 2 \= matrix_dim2 a then \ \ \ \ \ \ let c' = matrix_get a 0 j' in \ \ \ \ \ \ eif less c' c then enter_var j' c' (j'+1) \ \ \ \ \ \ else enter_var j c (j'+1) \ \ \ \ else j in \; \ \ (* step 4 *) \; \ \ let rec depart_var j i r i' = \ \ \ \ eif i' + 1 \= matrix_dim1 a then \ \ \ \ \ \ let c' = matrix_get a i' j in \ \ \ \ \ \ eif less fl0 c' then \ \ \ \ \ \ \ \ let r' = div (matrix_get a i' (matrix_dim2 a + (-1))) c' in \ \ \ \ \ \ \ \ eif less r' r then depart_var j i' r' (i'+1) \ \ \ \ \ \ \ \ else depart_var j i r (i'+1) \ \ \ \ \ \ else depart_var j i r (i'+1) \ \ \ \ else i in \; \ \ (* step 5 *) \; \ \ let rec init_ratio j i = \ \ \ \ eif i + 1 \= matrix_dim1 a then \ \ \ \ \ \ let c = matrix_get a i j in \ \ \ \ \ \ eif less fl0 c then i, div (matrix_get a i (matrix_dim2 a + (-1))) c \ \ \ \ \ \ else init_ratio j (i+1) \ \ \ \ else runtime_failure "init_ratio: no variable found" in \; \ \ (* step 7 *) \; \ \ if is_neg a then \ \ \ \ if unb1 a 0 1 then () (* assert false *) \ \ \ \ else \ \ \ \ \ \ let j = enter_var 1 (matrix_get a 0 1) 2 in \ \ \ \ \ \ let i, r = init_ratio j 1 in \ \ \ \ \ \ let i = depart_var j i r (i+1) in \ \ \ \ \ \ row_op a i j; \ \ \ \ \ \ simplex a \ \ else () The file has the above steps in order as part of a single toplevel definition. Value items from : <\code> val is_neg_aux : \ \ \ >i, k, n[0 > n > 1 > k > 0 > i]. \ \ \ Matrix (k, i) > Num n > Bool \; val is_neg : >k, n[1 > n > 0 > k]. Matrix (n, k) > Bool \; val unb1 : \ \ \ >i, j, k, n[0 > n > 0 > k + 1 > 1 > i > 0 > j]. \ \ \ Matrix (i, j) > Num k > Num n > Bool \; val norm_aux : \ \ \ >i, j, k, n[0 > n > 0 > k > k + 1 > i > 0 > j]. \ \ \ Matrix (i, j) > Num k > Float > Num n > () \; val norm : \ \ \ >i, j, k, n[0 > n > 0 > k > k + 1 > i > n + 1 > j]. \ \ \ Matrix (i, j) > Num k > Num n > () \; val row_op_aux1 : \ \ \ >i, j, k, m, n[0 > n > 0 > k > 0 > i > i + 1 > j > \ \ \ k + 1 > j > 0 > m]. \ \ \ Matrix (j, m) > Num i > Num k > Float > Num n > () \; val row_op_aux2 : \ \ \ >i, j, k, m, n[0 > n > 0 > k > 0 > i > i + 1 > j > \ \ \ k + 1 > j > n + 1 > m]. \ \ \ Matrix (j, m) > Num i > Num k > Num n > () \; val row_op_aux3 : \ \ \ >i, j, k, m, n[0 > k > 0 > i > 0 > j > k + 1 > m]. \ \ \ Matrix (j, m) > Num i > Num k > Num n > () \; val row_op : \ \ \ >i, j, k, n[0 > n > 0 > k > k + 1 > i > n + 1 > j]. \ \ \ Matrix (i, j) > Num k > Num n > () \; val simplex : >k, n[1 > n > 2 > k]. Matrix (n, k) > () Exported OCaml source : <\code> type num = int type matrix = \ \ (float, Bigarray.float64_elt, Bigarray.c_layout) Bigarray.Array2.t let matrix_make : \ \ (*0 > n > 0 > k*) ((* n *) num -\ (* k *) num -\ (* n, k *) matrix) = \ \ fun a b -\> Bigarray.Array2.create Bigarray.float64 Bigarray.c_layout a b let matrix_get : \ \ (*0 > i > i + 1 > n > 0 > j > j + 1 > k*) \ \ ((* n, k *) matrix -\> (* i *) num -\> (* j *) num -\> float) = \ \ Bigarray.Array2.get let matrix_set : \ \ (*0 > i > i + 1 > n > 0 > j > j + 1 > k*) \ \ ((* n, k *) matrix -\> (* i *) num -\> (* j *) num -\> float -\> unit) = \ \ Bigarray.Array2.set let matrix_dim1 : \ \ (*0 > n > 0 > k*) ((* n, k *) matrix -\ (* n *) num) = \ \ Bigarray.Array2.dim1 let matrix_dim2 : \ \ (*0 > n > 0 > k*) ((* n, k *) matrix -\ (* k *) num) = \ \ Bigarray.Array2.dim2 let n2f : ((* n *) num -\> float) = float_of_int let equal : ('a -\> 'a -\> bool) = fun x y -\> x = y let leq : ('a -\> 'a -\> bool) = fun x y -\> x \<= y let less : ('a -\> 'a -\> bool) = fun x y -\> x \< y let minus : (float -\> float -\> float) = (-.) let plus : (float -\> float -\> float) = (+.) let mult : (float -\> float -\> float) = ( *. ) let div : (float -\> float -\> float) = ( /. ) let fl0 : float = 0.0 let rec is_neg_aux : \ \ (*type i k n [0 > n > 1 > k > \ \ \ \ 0 > i].*) ((* k, i *) matrix -\ (* n *) num -\ bool) = \ \ (fun a j -\> \ \ \ \ (if j + 2 \= matrix_dim2 a then \ \ \ \ (if less (matrix_get a 0 j) fl0 then true else is_neg_aux a (j + 1)) else \ \ \ \ false)) let is_neg \ \ : (*type k n [1 > n > 0 > k].*) ((* n, k *) matrix -\ bool) = \ \ (fun a -\> is_neg_aux a 1) let rec unb1 : \ \ (*type i j k n [0 > n > 0 > k + 1 > 1 > i > \ \ \ \ 0 > j].*) ((* i, j *) matrix -\ (* k *) num -\ (* n *) num -\ bool) = \ \ (fun a i j -\> \ \ \ \ let rec unb2 : \ \ \ \ (*type k1 l m n1 [0 > m > 0 > l > 0 > n1 > \ \ \ \ \ \ m + 1 > k1].*) ((* n1, k1 *) matrix -\ (* l *) num -\ (* m *) num -\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ bool) \ \ \ \ = \ \ \ \ (fun a i j -\> \ \ \ \ \ \ (if i + 1 \= matrix_dim1 a then \ \ \ \ \ \ (if less (matrix_get a i j) fl0 then unb2 a (i + 1) j else \ \ \ \ \ \ unb1 a 0 (j + 1)) else true)) in \ \ \ \ (if j + 2 \= matrix_dim2 a then \ \ \ \ (if less (matrix_get a 0 j) fl0 then unb2 a (i + 1) j else \ \ \ \ unb1 a 0 (j + 1)) else false)) let rec norm_aux : \ \ (*type i j k n [0 > n > 0 > k > k + 1 > i > \ \ \ \ 0 > j].*) ((* i, j *) matrix -\ (* k *) num -\ float -\ (* n *) num -\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ unit) = \ \ (fun a i c j -\> \ \ \ \ (if j + 1 \= matrix_dim2 a then \ \ \ \ (matrix_set a i j (div (matrix_get a i j) c) ; norm_aux a i c (j + 1)) \ \ \ \ else ())) let rec norm : \ \ (*type i j k n [0 > n > 0 > k > k + 1 > i > \ \ \ \ n + 1 > j].*) ((* i, j *) matrix -\ (* k *) num -\ (* n *) num -\ unit) = \ \ (fun a i j -\> let c = matrix_get a i j in norm_aux a i c 1) let rec row_op_aux1 : \ \ (*type i j k m n [0 > n > 0 > k > 0 > i > i + 1 > j > \ \ \ \ k + 1 > j > \ \ \ \ 0 > m].*) ((* j, m *) matrix -\ (* i *) num -\ (* k *) num -\ float -\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ (* n *) num -\> unit) = \ \ (fun a i i' c j -\> \ \ \ \ (if j + 1 \= matrix_dim2 a then \ \ \ \ (matrix_set a i' j \ \ \ \ \ \ \ (minus (matrix_get a i' j) (mult (matrix_get a i j) c)) \ \ \ \ ; row_op_aux1 a i i' c (j + 1)) else ())) let rec row_op_aux2 : \ \ (*type i j k m n [0 > n > 0 > k > 0 > i > i + 1 > j > \ \ \ \ k + 1 > j > \ \ \ \ n + 1 > m].*) ((* j, m *) matrix -\ (* i *) num -\ (* k *) num -\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ (* n *) num -\> unit) = \ \ (fun a i i' j -\> row_op_aux1 a i i' (matrix_get a i' j) 1) let rec row_op_aux3 : \ \ (*type i j k m n [0 > k > 0 > i > 0 > j > \ \ \ \ k + 1 > m].*) ((* j, m *) matrix -\ (* i *) num -\ (* k *) num -\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ (* n *) num -\> unit) = \ \ (fun a i j i' -\> \ \ \ \ (if i' + 1 \= matrix_dim1 a then \ \ \ \ (if i \= i'&& i' \= i then \ \ \ \ (row_op_aux2 a i i' j ; row_op_aux3 a i j (i' + 1)) else \ \ \ \ row_op_aux3 a i j (i' + 1)) else ())) let rec row_op : \ \ (*type i j k n [0 > n > 0 > k > k + 1 > i > \ \ \ \ n + 1 > j].*) ((* i, j *) matrix -\ (* k *) num -\ (* n *) num -\ unit) = \ \ (fun a i j -\> (norm a i j ; row_op_aux3 a i j 0)) type ex7 = \ \ \| Ex7 : (*>'i, 'k, 'n[k > i > i + 1 > n].*)((* i *) num * float) -\ \ \ \ \ (* n, k *) ex7 type ex5 = \ \ \| Ex5 : (*>'i, 'k, 'n[0 > k > k>max (i, n + -1)].*)(* k *) num -\ \ \ \ \ (* n, i *) ex5 type ex2 = \ \ \| Ex2 : (*>'i, 'k, 'n[0 > k > k>max (i, n + -1)].*)(* k *) num -\ \ \ \ \ (* n, i *) ex2 let rec simplex : \ \ (*type k n [1 > n > 2 > k].*) ((* n, k *) matrix -\ unit) = \ \ (fun a -\> \ \ \ \ let rec enter_var : \ \ \ \ (*type i j [0 > j > \ \ \ \ \ \ 0 > i].*) ((* i *) num -\ float -\ (* j *) num -\ (* k, i *) ex2) \ \ \ \ = \ \ \ \ (fun j c j' -\> \ \ \ \ \ \ (if j' + 2 \= matrix_dim2 a then \ \ \ \ \ \ let c' = matrix_get a 0 j' in \ \ \ \ \ \ (if less c' c then \ \ \ \ \ \ let Ex2 xcase = enter_var j' c' (j' + 1) in Ex2 xcase else \ \ \ \ \ \ let Ex2 xcase = enter_var j c (j' + 1) in Ex2 xcase) else \ \ \ \ \ \ let xcase = j in Ex2 xcase)) in \ \ \ \ let rec depart_var : \ \ \ \ (*type l m n1 [0 > l > 0 > n1 > n1 + 1 > k > \ \ \ \ \ \ 0 > m].*) ((* n1 *) num -\ (* m *) num -\ float -\ (* l *) num -\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ (* n, m *) ex5) \ \ \ \ = \ \ \ \ (fun j i r i' -\> \ \ \ \ \ \ (if i' + 1 \= matrix_dim1 a then \ \ \ \ \ \ let c' = matrix_get a i' j in \ \ \ \ \ \ (if less fl0 c' then \ \ \ \ \ \ let r' = div (matrix_get a i' (matrix_dim2 a + -1)) c' in \ \ \ \ \ \ (if less r' r then \ \ \ \ \ \ let Ex5 xcase = depart_var j i' r' (i' + 1) in Ex5 xcase else \ \ \ \ \ \ let Ex5 xcase = depart_var j i r (i' + 1) in Ex5 xcase) else \ \ \ \ \ \ let Ex5 xcase = depart_var j i r (i' + 1) in Ex5 xcase) else \ \ \ \ \ \ let xcase = i in Ex5 xcase)) in \ \ \ \ let rec init_ratio : \ \ \ \ (*type i1 k1 [0 > k1 > 0 > i1 > \ \ \ \ \ \ i1 + 1 > k].*) ((* i1 *) num -\ (* k1 *) num -\ (* n, k1 *) ex7) \ \ \ \ = \ \ \ \ (fun j i -\> \ \ \ \ \ \ (if i + 1 \= matrix_dim1 a then \ \ \ \ \ \ \ \ let c = matrix_get a i j in \ \ \ \ \ \ \ \ (if less fl0 c then \ \ \ \ \ \ \ \ let xcase = (i, div (matrix_get a i (matrix_dim2 a + -1)) c) in \ \ \ \ \ \ \ \ Ex7 xcase else let Ex7 xcase = init_ratio j (i + 1) in Ex7 xcase) \ \ \ \ \ \ else \ \ \ \ \ \ \ \ (failwith "init_ratio: no variable found"))) in \ \ \ \ (if is_neg a then \ \ \ \ (if unb1 a 0 1 then () else \ \ \ \ \ \ let Ex2 j = enter_var 1 (matrix_get a 0 1) 2 in \ \ \ \ \ \ let Ex7 (i, r) = init_ratio j 1 in \ \ \ \ \ \ let Ex5 i = depart_var j i r (i + 1) in (row_op a i j ; simplex a)) \ \ \ \ else \ \ \ \ \ \ ())) > Source file : <\code> external let n2f : >n. Num n > Float = "float_of_int" external let equal : >a. a > a > Bool = "fun x y -\ x = y" external let leq : >a. a > a > Bool = "fun x y -\ x \= y" external let less : >a. a > a > Bool = "fun x y -\ x \ y" \; external let minus : Float > Float > Float = "(-.)" external let plus : Float > Float > Float = "(+.)" external let mult : Float > Float > Float = "( *. )" external let div : Float > Float > Float = "( /. )" external let fabs : Float > Float = "abs_float" external let fl0 : Float = "0.0" external let fl1 : Float = "1.0" \; let getRow data i = \ \ let stride = matrix_dim2 data in \ \ let rowData = array_make stride fl0 in \ \ let rec extract j = \ \ \ \ if j + 1 \= stride then ( \ \ \ \ \ \ array_set rowData j (matrix_get data i j); \ \ \ \ \ \ (* lukstafi: the call below missing in the original source? *) \ \ \ \ \ \ extract (j + 1)) \ \ \ \ else () in \ \ extract 0; \ \ rowData \; let putRow data i row = \ \ let stride = array_length row in \ \ let rec put j = \ \ \ \ if j + 1 \= stride then ( \ \ \ \ \ \ matrix_set data i j (array_get row j); \ \ \ \ \ \ (* lukstafi: the call below missing in the original source? *) \ \ \ \ \ \ put (j + 1)) \ \ \ \ else () in \ \ put 0 \; let rowSwap data i j = \ \ let temp = getRow data i in \ \ putRow data i (getRow data j); \ \ putRow data j temp \; let norm r n i = \ \ let x = array_get r i in \ \ array_set r i fl1; \ \ let rec loop k = \ \ \ \ if k + 1 \= n then ( \ \ \ \ \ \ array_set r k (div (array_get r k) x); \ \ \ \ \ \ loop (k+1)) \ \ \ \ else () in \ \ loop (i+1) \; let rowElim r s n i = \ \ let x = array_get s i in \ \ array_set s i fl0; \ \ let rec loop k = \ \ \ \ if k + 1 \= n then ( \ \ \ \ \ \ array_set s k (minus (array_get s k) (mult x (array_get r k))); \ \ \ \ \ \ loop (k+1)) \ \ \ \ else () in \ \ loop (i+1) \; let gauss data = \ \ let n = matrix_dim1 data in \ \ let m = matrix_dim2 data in \; \ \ let rec rowMax i j x mx = \ \ \ \ eif j + 1 \= n then \ \ \ \ \ \ let y = fabs (matrix_get data j i) in \ \ \ \ \ \ eif (less x y) then rowMax i (j+1) y j \ \ \ \ \ \ else rowMax i (j+1) x mx \ \ \ \ else mx in \; \ \ let rec loop1 i = \ \ \ \ if i + 1 \= n then \ \ \ \ \ \ let x = fabs (matrix_get data i i) in \ \ \ \ \ \ let mx = rowMax i (i+1) x i in \ \ \ \ \ \ norm (getRow data mx) m i; \ \ \ \ \ \ rowSwap data i mx; \ \ \ \ \ \ let rec loop2 j = \ \ \ \ \ \ \ \ if j + 1 \= n then ( \ \ \ \ \ \ \ \ \ \ rowElim (getRow data i) (getRow data j) m i; \ \ \ \ \ \ \ \ \ \ loop2 (j+1)) \ \ \ \ \ \ \ \ else () in \ \ \ \ \ \ loop2 (i+1); \ \ \ \ \ \ loop1 (i+1) \ \ \ \ else () in \ \ loop1 0 Value items from : <\code> val getRow : \ \ \ >i, k, n[0 > n > 0 > k > k + 1 > i]. \ \ \ Matrix (i, n) > Num k > Array (Float, n) \; val putRow : \ \ \ >i, j, k, n[0 > n > 0 > k > k + 1 > i > n > j]. \ \ \ Matrix (i, j) > Num k > Array (Float, n) > () \; val rowSwap : \ \ \ >i, j, k, n[0 > n > 0 > k > k + 1 > i > n + 1 > i > \ \ \ 0 > j]. Matrix (i, j) > Num k > Num n > () \; val norm : \ \ \ >i, k, n[0 > n > n + 1 > i > k > i]. \ \ \ Array (Float, i) > Num k > Num n > () \; val rowElim : \ \ \ >i, j, k, n[0 > n > n + 1 > i > k > i > k > j]. \ \ \ Array (Float, j) > Array (Float, i) > Num k > Num n > () \; val gauss : >k, n[0 > n > 1 > k > n > k]. Matrix (n, k) > () The last toplevel definition from , requires : <\code> let gauss data = \ \ let n = matrix_dim1 data in \; \ \ let rec rowMax i j x mx = \ \ \ \ eif j + 1 \<= n then \ \ \ \ \ \ let y = fabs (matrix_get data j i) in \ \ \ \ \ \ eif (less x y) then rowMax i (j+1) y j \ \ \ \ \ \ else rowMax i (j+1) x mx \ \ \ \ else mx in \; \ \ let rec loop1 i = \ \ \ \ if i + 1 \<= n then \ \ \ \ \ \ let x = fabs (matrix_get data i i) in \ \ \ \ \ \ let mx = rowMax i (i+1) x i in \ \ \ \ \ \ norm (getRow data mx) (n+1) i; \ \ \ \ \ \ rowSwap data i mx; \ \ \ \ \ \ let rec loop2 j = \ \ \ \ \ \ \ \ if j + 1 \<= n then ( \ \ \ \ \ \ \ \ \ \ rowElim (getRow data i) (getRow data j) (n+1) i; \ \ \ \ \ \ \ \ \ \ loop2 (j+1)) \ \ \ \ \ \ \ \ else () in \ \ \ \ \ \ loop2 (i+1); \ \ \ \ \ \ loop1 (i+1) \ \ \ \ else () in \ \ loop1 0 The inferred types do not differ from the case. The last toplevel definition from : <\code> let gauss data = \ \ let n = matrix_dim1 data in \; \ \ let rec rowMax = efunction i -\> \ \ \ \ let x = fabs (matrix_get data i i) in \ \ \ \ let rec loop j x mx = \ \ \ \ \ \ assert num mx + 1 \<= n; \ \ \ \ \ \ eif j + 1 \<= n then \ \ \ \ \ \ \ \ let y = fabs (matrix_get data j i) in \ \ \ \ \ \ \ \ eif (less x y) then loop (j+1) y j \ \ \ \ \ \ \ \ else loop (j+1) x mx \ \ \ \ \ \ else mx in \ \ \ \ loop (i+1) x i in \; \ \ let rec loop1 i = \ \ \ \ if i + 1 \<= n then \ \ \ \ \ \ let mx = rowMax i in \ \ \ \ \ \ norm (getRow data mx) (n+1) i; \ \ \ \ \ \ rowSwap data i mx; \ \ \ \ \ \ let rec loop2 j = \ \ \ \ \ \ \ \ if j + 1 \<= n then ( \ \ \ \ \ \ \ \ \ \ rowElim (getRow data i) (getRow data j) (n+1) i; \ \ \ \ \ \ \ \ \ \ loop2 (j+1)) \ \ \ \ \ \ \ \ else () in \ \ \ \ \ \ loop2 (i+1); \ \ \ \ \ \ loop1 (i+1) \ \ \ \ else () in \ \ loop1 0 The inferred types do not differ from the case. > Source file : <\code> external let n2i : >n. Num n > Int = "fun i -\ i" external let div2 : >n. Num (2 n) > Num n = "fun i -\ i / 2" external let div4 : >n. Num (4 n) > Num n = "fun i -\ i / 4" external let n2f : >n. Num n > Float = "float_of_int" external let equal : >a. a > a > Bool = "fun x y -\ x = y" external let leq : >a. a > a > Bool = "fun x y -\ x \= y" external let less : >a. a > a > Bool = "fun x y -\ x \ y" external let ignore : >a. a > () = "ignore" \; external let abs : Float > Float = "abs_float" external let cos : Float > Float = "cos" external let sin : Float > Float = "sin" external let neg : Float > Float = "(~-.)" external let minus : Float > Float > Float = "(-.)" external let plus : Float > Float > Float = "(+.)" external let mult : Float > Float > Float = "( *. )" external let div : Float > Float > Float = "( /. )" external let fl0 : Float = "0.0" external let fl05 : Float = "0.5" external let fl1 : Float = "1.0" external let fl2 : Float = "2.0" external let fl3 : Float = "3.0" external let fl4 : Float = "4.0" external let pi : Float = "4.0 *. atan 1.0" external let two_pi : Float = "8.0 *. atan 1.0" \; datatype Bounded : num * num datacons Index : >i, k, n[n > i > i > k].Num i \ Bounded (n, k) \; let ffor s d body = \ \ let rec loop i = \ \ \ \ if i \<= d then (body (Index i); loop (i + 1)) else () in \ \ loop s \; external let ref : >a. a > Ref a = "fun a -\ ref a" external let asgn : >a. Ref a > a > () = "fun a b -\ a := b" external let deref : >a. Ref a > a = "(!)" \; let fft px py = (* n must be a power of 2! *) \ \ let n = array_length px + (-1) in \ \ let rec loop n2 n4 = \ \ \ \ if n2 \<= 2 then () else (* the case n2 = 2 is treated below *) \ \ \ \ let e = div two_pi (n2f n2) in \ \ \ \ let e3 = mult fl3 e in \ \ \ \ let a = ref fl0 in \ \ \ \ let a3 = ref fl0 in \ \ \ \ let rec forbod j' = \ \ \ \ match j' with Index j -\> \ \ \ \ (*for j = 1 to n4 do*) \ \ \ \ \ \ let cc1 = cos (deref a) in \ \ \ \ \ \ let ss1 = sin (deref a) in \ \ \ \ \ \ let cc3 = cos (deref a3) in \ \ \ \ \ \ let ss3 = sin (deref a3) in \ \ \ \ \ \ asgn a (plus (deref a) e); \ \ \ \ \ \ asgn a3 (plus (deref a3) e3); \ \ \ \ \ \ let rec loop1 i0 i1 i2 i3 id = \ \ \ \ \ \ \ \ if n + 1 \<= i3 then () else (* out_of_bounds *) \ \ \ \ \ \ \ \ let g_px_i0 = array_get px i0 in \ \ \ \ \ \ \ \ let g_px_i2 = array_get px i2 in \ \ \ \ \ \ \ \ let r1 = minus g_px_i0 g_px_i2 in \ \ \ \ \ \ \ \ let r1' = plus g_px_i0 g_px_i2 in \ \ \ \ \ \ \ \ array_set px i0 r1'; \ \ \ \ \ \ \ \ let g_px_i1 = array_get px i1 in \ \ \ \ \ \ \ \ let g_px_i3 = array_get px i3 in \ \ \ \ \ \ \ \ let r2 = minus g_px_i1 g_px_i3 in \ \ \ \ \ \ \ \ let r2' = plus g_px_i1 g_px_i3 in \ \ \ \ \ \ \ \ array_set px i1 r2'; \ \ \ \ \ \ \ \ let g_py_i0 = array_get py i0 in \ \ \ \ \ \ \ \ let g_py_i2 = array_get py i2 in \ \ \ \ \ \ \ \ let s1 = minus g_py_i0 g_py_i2 in \ \ \ \ \ \ \ \ let s1' = plus g_py_i0 g_py_i2 in \ \ \ \ \ \ \ \ array_set py i0 s1'; \ \ \ \ \ \ \ \ let g_py_i1 = array_get py i1 in \ \ \ \ \ \ \ \ let g_py_i3 = array_get py i3 in \ \ \ \ \ \ \ \ let s2 = minus g_py_i1 g_py_i3 in \ \ \ \ \ \ \ \ let s2' = plus g_py_i1 g_py_i3 in \ \ \ \ \ \ \ \ array_set py i1 s2'; \ \ \ \ \ \ \ \ let s3 = minus r1 s2 in\ \ \ \ \ \ \ \ \ let r1 = plus r1 s2 in \ \ \ \ \ \ \ \ let s2 = minus r2 s1 in \ \ \ \ \ \ \ \ let r2 = plus r2 s1 in \ \ \ \ \ \ \ \ array_set px i2 (minus (mult r1 cc1) (mult s2 ss1)); \ \ \ \ \ \ \ \ array_set py i2 (minus (mult (neg s2) cc1) (mult r1 ss1)); \ \ \ \ \ \ \ \ array_set px i3 (plus (mult s3 cc3) (mult r2 ss3)); \ \ \ \ \ \ \ \ array_set py i3 (minus (mult r2 cc3) (mult s3 ss3)); \ \ \ \ \ \ \ \ loop1 (i0 + id) (i1 + id) (i2 + id) (i3 + id) id in \ \ \ \ \ \ let rec loop2 is id = \ \ \ \ \ \ \ \ if n \<= is then () \ \ \ \ \ \ \ \ else ( \ \ \ \ \ \ \ \ \ \ let i1 = is + n4 in \ \ \ \ \ \ \ \ \ \ let i2 = i1 + n4 in \ \ \ \ \ \ \ \ \ \ let i3 = i2 + n4 in \ \ \ \ \ \ \ \ \ \ loop1 is i1 i2 i3 id; \ \ \ \ \ \ \ \ \ \ loop2 (2 * id + j - n2) (4 * id)) in \ \ \ \ \ \ loop2 j (2 * n2) in \ \ \ \ ffor 1 n4 forbod;\ \ \ \ \ loop (div2 n2) (div2 n4) in \ \ loop n (div4 n); \; \ \ let rec loop1 i0 i1 id = \ \ \ \ if n + 1 \<= i1 then () else \ \ \ \ let r1 = array_get px i0 in \ \ \ \ array_set px i0 (plus r1 (array_get px i1)); \ \ \ \ array_set px i1 (minus r1 (array_get px i1)); \ \ \ \ let r1 = array_get py i0 in \ \ \ \ array_set py i0 (plus r1 (array_get py i1)); \ \ \ \ array_set py i1 (minus r1 (array_get py i1)); \ \ \ \ loop1 (i0 + id) (i1 + id) id in \ \ let rec loop2 is id = \ \ \ \ if n \<= is then () else ( \ \ \ \ \ \ loop1 is (is + 1) id; \ \ \ \ \ \ loop2 (2 * id + (-1)) (4 * id)) in \ \ loop2 1 4; \; \ \ let rec loop1 j k = \ \ \ \ eif j \<= k then j + k \ \ \ \ else loop1 (j - k) (div2 k) in \; \ \ let rec loop2 i j = \ \ \ \ if n \<= i then () else ( \ \ \ \ \ \ if j \<= i then () else ( \ \ \ \ \ \ \ \ let xt = array_get px j in \ \ \ \ \ \ \ \ array_set px j (array_get px i); array_set px i (xt); \ \ \ \ \ \ \ \ let xt = array_get py j in \ \ \ \ \ \ \ \ array_set py j (array_get py i); array_set py i (xt)); \ \ \ \ \ \ let j' = loop1 j (div2 n) in \ \ \ \ \ \ loop2 (i + 1) j') in \ \ loop2 1 1; n \; let ffttest np = \ \ let enp = n2f np in \ \ let n2 = div2 np in \ \ let npm = n2 - 1 in \ \ let pxr = array_make (np+1) fl0 in \ \ let pxi = array_make (np+1) fl0 in \ \ let t = div pi enp in \ \ array_set pxr 1 (mult (minus enp fl1) fl05); \ \ array_set pxi 1 (fl0); \ \ array_set pxr (n2+1) (neg (mult fl1 fl05)); \ \ array_set pxi (n2+1) fl0; \ \ let rec forbod i = \ \ \ \ if i \<= npm then \ \ \ \ \ \ let j = np - i in \ \ \ \ \ \ array_set pxr (i+1) (neg (mult fl1 fl05)); \ \ \ \ \ \ array_set pxr (j+1) (neg (mult fl1 fl05)); \ \ \ \ \ \ let z = mult t (n2f i) in \ \ \ \ \ \ let y = mult (div (cos z) (sin z)) fl05 in \ \ \ \ \ \ array_set pxi (i+1) (neg y); array_set pxi (j+1) (y) \ \ \ \ else () in \ \ forbod 1; \ \ ignore (fft pxr pxi); \ \ (* lukstafi: kr and ki are placeholders? *) \ \ let rec loop i zr zi kr ki = \ \ \ \ if np \<= i then (zr, zi) else \ \ \ \ \ \ let a = abs (minus (array_get pxr (i+1)) (n2f i)) in \ \ \ \ \ \ let b = less zr a in \ \ \ \ \ \ let zr = if b then a else zr in \ \ \ \ \ \ let kr = eif b then i else kr in \ \ \ \ \ \ let a = abs (array_get pxi (i+1)) in \ \ \ \ \ \ let b = less zi a in \ \ \ \ \ \ let zi = if b then a else zi in \ \ \ \ \ \ let ki = eif b then i else ki in \ \ \ \ \ \ loop (i+1) zr zi kr ki in \ \ let zr, zi = loop 0 fl0 fl0 0 0 in \ \ let zm = if less (abs zr) (abs zi) then zi else zr in \ \ (*in print_float zm; print_newline ()*) zm \; let rec loop_np i np = \ \ if 17 \<= i then () else \ \ ( ignore (ffttest np); loop_np (i + 1) (2 * np) ) \; let doit _ = loop_np 4 16 Value items from : <\code> val ffor : \ \ \ >i, j, k, n[j > i > k > n]. \ \ \ Num n > Num j > (Bounded (k, i) > ()) > () \; val fft : \ \ \ >k, n[1 > n > n + 1 > k]. \ \ \ Array (Float, n + 1) > Array (Float, k) > Num n \; val ffttest : >n[2 > n]. Num n > Float \; val loop_np : >k, n[2 > n]. Num k > Num n > () \; val doit : >a. a > () : Manual> Type systems are an established natural deduction-style means to reason about programs. Dependent types can represent arbitrarily complex properties as they use the same language for both types and programs, the type of value returned by a function can itself be a function of the argument. Generalized Algebraic Data Types bring some of that expressivity to type systems that deal with data-types. Type systems with GADTs introduce the ability to reason about return type by case analysis of the input value, while keeping the benefits of a simple semantics of types, for example deciding equality between types can be very simple. Existential types hide some information conveyed in a type, usually when that information cannot be reconstructed in the type system. A part of the type will often fail to be expressible in the simple language of types, when the dependence on the input to the program is complex. GADTs express existential types by using local type variables for the hidden parts of the type encapsulated in a GADT. The type system for GADTs differs from more pragmatic approaches in mainstream functional languages in that we do not require any type annotations on expressions, even on recursive functions. The implementation also includes linear equations and inequalities over rational numbers in the language of types, with the possibility to introduce more domains in the future. The concrete syntax of is similar to that of OCaml. However, it does not currently cover records, the module system, objects, and polymorphic variant types. It supports higher-order functions, algebraic data-types including built-in tuple types, and linear pattern matching. It supports conjunctive patterns using the keyword, but it currently does not support disjunctive patterns. It currently has limited support for guarded patterns: after , only inequality => between values of the type are allowed. The sort of a type variable is identified by the first letter of the variable. ,,,,,,,... are in the sort of terms called , i.e. ``types proper''. ,,,,,,,... are in the sort of linear arithmetics over rational numbers called . Remaining letters are reserved for sorts that may be added in the future. Value constructors (like in OCaml) and type constructors (unlike in OCaml) have the same syntax: capitalized name followed by a tuple of arguments. They are introduced by and respectively. The declaration might be misleading in that it only lists the sorts of the arguments of the type, the resulting sort is always . Values assumed into the environment are introduced by . There is a built-in type corresponding to declaration and definitions of numeric constants ... The programmer can use declarations to give the semantics of choice to the data-type. The type with additional support as is the integers. When solving negative constraints, arising from clauses, we assume that the intended domain of the sort is integers. This is a workaround to the lack of strict inequality in the sort . We do not make the whole sort an integer domain because it would complicate the algorithms. In examples here we use Unicode characters. For ASCII equivalents, take a quick look at the tables in the following section. We start with a simple example, a function that can compute a value from a representation of an expression -- a ready to use value whether it be or . Prior to the introduction of GADT types, we could only implement a function >a. Term a > Value> where, using OCaml syntax, . <\code> datatype Term : type external let plus : Int > Int > Int = "(+)" external let is_zero : Int > Bool = "(=) 0" datacons Lit : Int > Term Int datacons Plus : Term Int * Term Int > Term Int datacons IsZero : Term Int > Term Bool datacons If : >a. Term Bool * Term a * Term a > Term a \; let rec eval = function \ \ \| Lit i -\> i \ \ \| IsZero x -\> is_zero (eval x) \ \ \| Plus (x, y) -\> plus (eval x) (eval y) \ \ \| If (b, t, e) -\> if eval b then eval t else eval e Let us look at the corresponding generated, also called , OCaml source code: <\code> type _ term = \ \ \| Lit : int -\> int term \ \ \| Plus : int term * int term -\> int term \ \ \| IsZero : int term -\> bool term \ \ \| If : (*>'a.*)bool term * 'a term * 'a term -\ 'a term \ \ let plus : (int -\> int -\> int) = (+) let is_zero : (int -\> bool) = (=) 0 let rec eval : type a . (a term -\> a) = \ \ (function Lit i -\> i \| IsZero x -\> is_zero (eval x) \ \ \ \ \| Plus (x, y) -\> plus (eval x) (eval y) \ \ \ \ \| If (b, t, e) -\> (if eval b then eval t else eval e)) The , and types are built-in. and follow the general scheme of exporting a datatype constructor with the same name, only lower-case. However, numerals , , ... are always type-checked as , ... can also be exported as a type other than , and then numerals are exported via an injection function (ending with) . The syntax allows us to name an OCaml library function or give an OCaml definition which we opt-out from translating to . Such a definition will be verified against the rest of the program when calls to verify the exported code. Another variant of (omitting the keyword) exports a value using in OCaml code, which is OCaml source declaration of the foreign function interface of OCaml. When we are not interested in linking and running the exported code, we can omit the part starting with the sign. The exported code will reuse the name in the FFI definition: .... The type inferred for the above example is >a. Term a>a>. GADTs make it possible to reveal that is a and therefore the result of should in its case be , is a and the result of should in its case be , etc. The >>> syntax is a syntactic sugar for ematch>>>>>>, and any such expressions are exported using expressions. is a function comparing values provided representation of their types: <\code> datatype Ty : type datatype Int datatype List : type datacons Zero : Int datacons Nil : >a. List a datacons TInt : Ty Int datacons TPair : >a, b. Ty a * Ty b > Ty (a, b) datacons TList : >a. Ty a > Ty (List a) datatype Boolean datacons True : Boolean datacons False : Boolean external eq_int : Int > Int > Bool external b_and : Bool > Bool > Bool external b_not : Bool > Bool external forall2 : >a, b. (a > b > Bool) > List a > List b > Bool \; let rec equal = function \ \ \| TInt, TInt -\> fun x y -\> eq_int x y \ \ \| TPair (t1, t2), TPair (u1, u2) -\> \ \ \ \ \ (fun (x1, x2) (y1, y2) -\> \ \ \ \ \ \ \ \ b_and (equal (t1, u1) x1 y1) \ \ \ \ \ \ \ \ \ \ \ \ \ \ (equal (t2, u2) x2 y2)) \ \ \| TList t, TList u -\> forall2 (equal (t, u)) \ \ \| _ -\> fun _ _ -\> False returns an unexpected type: >a,b.(Ty a, Ty b)>a>a>Bool>, one of four maximally general types of as defined above. The other maximally general ``wrong'' types are >a,b.(Ty a, Ty b)>b>b>Bool> and >a,b.(Ty a, Ty b)>b>a>Bool>. This illustrates that unrestricted type systems with GADTs lack principal typing property. commits to a type of a toplevel definition before proceeding to the next one, so sometimes we need to provide more information in the program. Besides type annotations, there are three means to enrich the generated constraints: syntax for providing negative constraints, > and = e2;>> for positive constraints, and syntax for including constraints of use cases with constraint of a toplevel definition. To ensure only one maximally general type for , we use and . We can either add the clauses: <\code> \ \ \| TInt, TList l -\> (function Nil -\> assert false) \ \ \| TList l, TInt -\> (fun _ -\> function Nil -\> assert false) The first assertion excludes independence of the first encoded type and the second argument. The second assertion excludes independence of the second encoded type and the third argument. Or we can add the clause: <\code> test b_not (equal (TInt, TList TInt) Zero Nil) The test ensures that arguments of distinct types can be given. returns the expected type >a,b.(Ty a, Ty b)>a>b>Bool>. Now we demonstrate numerical invariants: <\code> datatype Binary : num datatype Carry : num datacons Zero : Binary 0 datacons PZero : >n[0>n]. Binary n > Binary(2 n) datacons POne : >n[0>n]. Binary n > Binary(2 n + 1) datacons CZero : Carry 0 datacons COne : Carry 1 \; let rec plus = \ \ function CZero -\> \ \ \ \ (function Zero -\> (fun b -\> b) \ \ \ \ \ \ \| PZero a1 as a -\> \ \ \ \ \ \ \ \ (function Zero -\> a \ \ \ \ \ \ \ \ \ \ \| PZero b1 -\> PZero (plus CZero a1 b1) \ \ \ \ \ \ \ \ \ \ \| POne b1 -\> POne (plus CZero a1 b1)) \ \ \ \ \ \ \| POne a1 as a -\> \ \ \ \ \ \ \ \ (function Zero -\> a \ \ \ \ \ \ \ \ \ \ \| PZero b1 -\> POne (plus CZero a1 b1) \ \ \ \ \ \ \ \ \ \ \| POne b1 -\> PZero (plus COne a1 b1))) \ \ \ \ \| COne -\> \ \ \ \ (function Zero -\> \ \ \ \ \ \ \ \ (function Zero -\> POne(Zero) \ \ \ \ \ \ \ \ \ \ \| PZero b1 -\> POne b1 \ \ \ \ \ \ \ \ \ \ \| POne b1 -\> PZero (plus COne Zero b1)) \ \ \ \ \ \ \| PZero a1 as a -\> \ \ \ \ \ \ \ \ (function Zero -\> POne a1 \ \ \ \ \ \ \ \ \ \ \| PZero b1 -\> POne (plus CZero a1 b1) \ \ \ \ \ \ \ \ \ \ \| POne b1 -\> PZero (plus COne a1 b1)) \ \ \ \ \ \ \| POne a1 as a -\> \ \ \ \ \ \ \ \ (function Zero -\> PZero (plus COne a1 Zero) \ \ \ \ \ \ \ \ \ \ \| PZero b1 -\> PZero (plus COne a1 b1) \ \ \ \ \ \ \ \ \ \ \| POne b1 -\> POne (plus COne a1 b1))) We get >i,k,n.Carry i>Binary k>Binary n>Binary (n + k + i)>. We can introduce existential types directly in type declarations. To have an existential type inferred, we have to use , or expressions, which differ from , , respectively in that the (return) type is an existential type. To use a value of an existential type, we have to bind it with a .. expression. Otherwise, the existential type will not be unpacked. An existential type will be automatically unpacked before being ``repackaged'' as another existential type. In the following artificial example, we abstract away the particular resulting location. <\code> datatype Room datatype Yard datatype Village datatype Castle : type datatype Place : type datacons Room : Room > Castle Room datacons Yard : Yard > Castle Yard datacons CastleRoom : Room > Place Room datacons CastleYard : Yard > Place Yard datacons Village : Village > Place Village \; external wander : >a. Place a > >b. Place b \; let rec find_castle = efunction \ \ \| CastleRoom x -\> Room x \ \ \| CastleYard x -\> Yard x \ \ \| Village _ as x -\> \ \ \ \ let y = wander x in \ \ \ \ find_castle y We get >a. Place a> >b. Castle b>. Next consider a slightly less artificial, toy example of computer hardware configuration. It illustrates many aspects of existential types in . We introduce functions and as external, i.e., ones whose definition is not type-checked by . Their types illustrate that existential types can be used in type annotations. Types and , although declared as data-types, are phantom types, i.e. are not inhabited and convey information as parameters of other types. <\code> datatype Slow \ datatype Fast \ datatype Budget datacons Small : Budget \ datacons Medium : Budget \ datacons Large : Budget datatype Memory : type \ datacons Best_mem : Memory Fast datatype Motherboard : type \ datacons Best_board : Motherboard Fast external config_mem_board : Budget > >a. (Memory a, Motherboard a) datatype CPU : type datacons FastCPU : CPU Fast \ datacons SlowCPU : CPU Slow datatype GPU : type datacons FastGPU : GPU Fast \ datacons SlowGPU : GPU Slow external config_gpu : Budget > >a. GPU a datatype PC : type * type * type * type datacons PC : \ \ >a,b,c,r. CPU a * GPU b * Memory c * Motherboard r > PC (a,b,c,r) datatype Usecase \ datacons Gaming : Usecase datacons Scientific : Usecase \ datacons Office : Usecase \; let budget_to_cpu = efunction \ \ \| Small -\ SlowCPU \| Medium -\ FastCPU \| Large -\ FastCPU let usecase_to_gpu budget = efunction \ \ \| Gaming -\ FastGPU \| Scientific -\ FastGPU \ \ \| Office -\ config_gpu budget let rec configure = efunction \ \ \| Small, Gaming -\ configure (Small, Office) \ \ \| Large, Gaming -\ PC (FastCPU, FastGPU, Best_mem, Best_board) \ \ \| budget, usecase -\ \ \ \ \ let mem, board = config_mem_board budget in \ \ \ \ let cpu = budget_to_cpu budget in \ \ \ \ let gpu = usecase_to_gpu budget usecase in \ \ \ \ PC (cpu, gpu, mem, board) infers the following types: <\code> budget_to_cpu : Size > >a.CPU a usecase_to_gpu : Usecase > >a.GPU a configure : (Size, Usecase) > >a, b, c.PC (a, b, c, c) The definition of illustrates explicit elimination of existential types by .. definitions: by design, inlining of or definitions would make the function not typeable. The call to and the recursive call to illustrate implicit elimination of existential types in return positions. A more practical existential type example: <\code> datatype Bool datacons True : Bool datacons False : Bool datatype List : type * num datacons LNil : >a. List(a, 0) datacons LCons : >n,a[0>n]. a * List(a, n) > List(a, n+1) \; let rec filter f = \ \ efunction LNil -\> LNil \ \ \ \ \| LCons (x, xs) -\> \ \ \ \ \ \ eif f x then \ \ \ \ \ \ \ \ \ \ let ys = filter f xs in \ \ \ \ \ \ \ \ \ \ LCons (x, ys) \ \ \ \ \ \ else filter f xs We get >n, a.(a>Bool)>List (a, n)> >k[0>k > k>n].List (a, k)>. Note that we need to use both and above, since every use of , or will force the types of its branches to be equal. In particular, for lists with length the resulting length would have to be the same in each branch. If the constraint cannot be met, as for with either or , the code will not type-check. A more complex example that computes bitwise -- stands for ``upper bound'': <\code> datatype Binary : num datacons Zero : Binary 0 datacons PZero : >n [0>n]. Binary n > Binary(2 n) datacons POne : >n [0>n]. Binary n > Binary(2 n + 1) \; let rec ub = efunction \ \ \| Zero -\> \ \ \ \ \ \ (efunction Zero -\> Zero \ \ \ \ \ \ \ \ \| PZero b1 as b -\> b \ \ \ \ \ \ \ \ \| POne b1 as b -\> b) \ \ \| PZero a1 as a -\> \ \ \ \ \ \ (efunction Zero -\> a \ \ \ \ \ \ \ \ \| PZero b1 -\> \ \ \ \ \ \ \ \ \ \ let r = ub a1 b1 in \ \ \ \ \ \ \ \ \ \ PZero r \ \ \ \ \ \ \ \ \| POne b1 -\> \ \ \ \ \ \ \ \ \ \ let r = ub a1 b1 in \ \ \ \ \ \ \ \ \ \ POne r) \ \ \| POne a1 as a -\> \ \ \ \ \ \ (efunction Zero -\> a \ \ \ \ \ \ \ \ \| PZero b1 -\> \ \ \ \ \ \ \ \ \ \ let r = ub a1 b1 in \ \ \ \ \ \ \ \ \ \ POne r \ \ \ \ \ \ \ \ \| POne b1 -\> \ \ \ \ \ \ \ \ \ \ let r = ub a1 b1 in \ \ \ \ \ \ \ \ \ \ POne r) >k,n.Binary k>Binary n>>:i[0>n > 0>k > n>i > k>i > i>n+k].Binary i>. Why cannot we shorten the above code by converting the initial cases to (efunction b -\ b)>? Without pattern matching, we do not make the contribution of available. Knowing i> and not knowing >n>, for the case 0>, we get: >k,n.Binary k>Binary n>>i[0>k>n>i>i>n+k].Binary i>. >i> follows from i>, >n+k> follows from i> and >k>, but >i> cannot be inferred from 0> and i> without knowing that >n>. Besides displaying types of toplevel definitions, can also export an OCaml source file with all the required GADT definitions and type annotations. Below we present, using examples, the syntax of : the mathematical notation, the concrete syntax in ASCII and the concrete syntax using Unicode. ||||||,\,\,\>>|,,,,,,,...>|>||>|,,,,,,,...>|>||n>>|>|>||>|>|>||>|>|>||>|>|>||k,nn|]>.\>>|=n].t>>|>k,n[k>n].t>>>||>>|>|>||>>|>|>||\\>>| t2>>|>>>>||>b>>|>|>||n>>|= n>>|> n>>>||\\>>|>|> b=a>>>>>> For the syntax of expressions, we discourage non-ASCII symbols. Below > stand for any expression, > stand for any pattern, stands for any lower-case identifier and for an upper-case identifier. > stands for , > for , and > for . |>| \ --lower-case identifier>>||>|>>||>| \ --upper-case identifier>>|| e>>|>>||.\.e|)>|)>>>| e>>>||.e\p.e|)>>>|e1 \| >...en>>>||.e\p.e|)> e>>|e1 \| >...>>||.e,K.e|)> e>>|>>||>> m\n.e,\|)> K>>|= n then e1 else e2>>>||.e\p.e|)>>>|e1 \| >...>>||.e\p.e|)> e>>|e1 \| >...>>||.e,K.e|)> e>>|>>||>> m\n.e,\|)> K>>|= n then e1 else e2>>>||>> x=e >> e>>|>>||>> p=e >> e>>|>>||>>>>|>>|| s>>|>>||>> \>>\>;e>>|>>||>> e\e;e>>|= e2; e3>>>>>> A built-in fail at runtime with the given text message is only needed for introducing existential types: a user-defined equivalent of would introduce a spurious branch for generalization. Toplevel expressions (corresponding to structure items in OCaml) introduce types, type and value constructors, global variables with given type \ (external names) or inferred type (definitions). |||||>>|| List(a,n+1)>>>||>n,a. a * List(a,n) > List(a,n+1)>>>||>n,a. List(a,n) \>k[k\=n].List(a,k)="c_foo">>>||>n,a. List(a,n) \>k[k\=n].List(a,k)>>>||>n,m. Num n>Num m \>k.Num k = "( * )">>>||...>>||...>>||......>>>>> Toplevel non-recursive definitions are polymorphic as an exception. In expressions, > definitions are monomorphic, one should use the > syntax to get a polymorphic -binding. Tests list expressions of type that at runtime have to evaluate to . Type inference is affected by the constraints generated to typecheck the expressions. There are variants of the if-then-else clause syntax supporting > conditions: <\itemize> = n1 && m2 \= n2 &&>> is >> \m\n.e,_.e|)> K>, = n then e1 else e2> is >> m\n.e,_ >> n+1\m.e|)> K> if integer mode is on (as in default setting), similarly for the variants. We add the standard syntactic sugar for function definitions: <\itemize> > >>>> = > in >> expands to > = fun >>>> -\ > in >> > >>>> = > in >> expands to > = fun >>>> -\ > in >> toplevel and definitions expand correspondingly. For simplicity of theory and implementation, mutual non-nested recursion and or-patterns are not provided. For mutual recursion, nest one recursive definition inside another. Like in OCaml, types of arguments in declarations of constructors are separated by asterisks. However, the type constructor for tuples is represented by commas, like in Haskell but unlike in OCaml. At any place between lexemes, regular comments encapsulated in > can occur. They are ignored during lexing. In front of all toplevel definitions and declarations, e.g. before a , , , or , and in front of > and > nodes in expressions, documentation comments > can be put. Documentation comments at other places are syntax errors. Documentation comments are preserved both in generated interface files and in exported source code files. The default settings of parameters should be sufficient for most cases. For example, after downloading source code and changing current directory to , we can enter, assuming a Unix-like shell: <\code> $ make main $ ./invargent examples/binary_upper_bound.gadt To get the inferred types printed on standard output, use the option: <\code> $ ./invargent -inform examples/avl_tree.gadt Below we demonstrate what happens with insufficiently high parameter setting. Consider this example: <\code> $ ./invargent -inform examples/flatten_septs.gadt File "examples/flatten_septs.gadt", line 8, characters 6-104: No answer in type: term abduction failed \; Perhaps increase the -term_abduction_timeout parameter. Perhaps increase the -term_abduction_fail parameter. $ ./invargent -inform -term_abduction_timeout 3000 examples/flatten_septs.gadt File "examples/flatten_septs.gadt", line 3, characters 26-261: No answer in num: numerical abduction failed \; Perhaps do not pass the -no_dead_code flag. Perhaps increase the -num_abduction_timeout parameter. Perhaps increase the -num_abduction_fail parameter. $ ./invargent -inform -term_abduction_timeout 3000 \\ \ \ -num_abduction_rotations 4 examples/flatten_septs.gadt val flatten_septs : \ \ >n, a. List ((a, a, a, a, a, a, a), n) > List (a, 7 n) InvarGenT: Generated file examples/flatten_septs.gadti InvarGenT: Generated file examples/flatten_septs.ml InvarGenT: Command "ocamlc -w -25 -c examples/flatten_septs.ml" exited with code 0 The suggestions are generated only when the corresponding limit has actually been exceeded. Remember however that the limits will often be exceeded for erroneus programs which should not type-check. Moreover, as illustrated above, other settings might be the culprit. To understand the intent of the solver parameters, we need a rough ``birds-eye view'' understanding of how works. The invariants and postconditions that we solve for are logical formulas and can be ordered by strength. Least Upper Bounds (LUBs) and Greatest Lower Bounds (GLBs) computations are traditional tools used for solving recursive equations over an ordered structure. In case of implicational constraints that are generated for type inference with GADTs, constraint abduction is a form of LUB computation. is our term for computing the GLB wrt. strength for formulas that are conjunctions of atoms. We want the invariants of recursive definitions -- i.e. the types of recursive functions and formulas constraining their type variables -- to be as weak as possible, to make the use of the corresponding definitions as easy as possible. The weaker the invariant, the more general the type of definition. Therefore the use of LUB, constraint abduction. For postconditions -- i.e. the existential types of results computed by expressions and formulas constraining their type variables -- we want the strongest possible solutions, because stronger postcondition provides more information at use sites of a definition. Therefore we use GLB, constraint generalization, but only if existential types have been introduced by or . Below we discuss all of the options. We use the technical term to mean type shapes, types without the concern for the sort of numbers (or other sorts to come in the future). <\description> >Print type schemes of toplevel definitions as they are inferred. >Print the time it took to infer type schemes of toplevel definitions. >Do not generate the file. >Do not generate the file. >Overwrite the file if it already exists. >Generate the exported OCaml file under the provided name. >Do not call on the generated file. >The exported type for which is an alias (default ). If for different than , numerals are exported as integers passed to a function. The variant exports numerals by passing to a function. >Annotate the and .. nodes in generated OCaml code. This increases the burden on inference a bit because the variables associated with the nodes cannot be eliminated from the constraint during initial simplification. >Keep clauses in exported code. When faced with multiple maximally general types of a function, we sometimes want to prevent some interpretations by asserting that a combination of arguments is not possible. These arguments will not be compatible with the type inferred, causing exported code to fail to typecheck. Sometimes we indicate unreachable cases just for documentation. If the type is tight this will cause exported code to fail to typecheck too. This option keeps pattern matching branches with in their bodies in exported code nevertheless. >Allow more programs with dead code than would otherwise pass. >Reject all programs with dead code (may misclassify programs using or atoms). Unreachable pattern matching branches lead to unsatisfiable premises of the type inference constraint, which we detect. However, sometimes multiple implications in the simplified form of the constraint can correspond to the same path through the program, in particular when solving constraints with and clauses. Dead code due to datatype mismatch, i.e. patterns unreachable without resort to numerical constraints, is detected even without using this option. >Limit on term simple abduction steps (default 700). Simple abduction works with a single implication branch, which roughly corresponds to a single branch -- an execution path -- of the program. >Limit on backtracking steps in term joint abduction (default 4). Joint abduction combines results for all branches of the constraints. >Do not include alien (e.g. numerical) premise information in term abduction. >Include recursive branches in numerical abduction from the start. By default, in the second iteration of solving constraints, which is the first iteration that numerical abduction is performed, we only pass non-recursive branches to numerical abduction. This makes it faster but less likely to find the correct solution. >The iteration at which to start truncating postconditions by only keeping atoms present in the previous iteration, to force convergence (default 8). >Include postconditions from recursive calls in abduction from the start. We do not derive requirements put on postconditions by recursive calls on first iteration. The requirements may turn smaller after some derived invariants are included in the premises. This option turns off the special treatment of postconditions on first iteration. >Numerical abduction: coefficients from 1/N> to N> (default 3). Numerical abduction answers are built, roughly speaking, by adding premise equations of a branch with conclusion of a branch to get an equation or inequality that does not conflict with other branches, but is equivalent to the conclusion equation/inequality. This parameter decides what range of coefficients is tried. If the highest coefficient in correct answer is greater, abduction might fail. However, it often succeeds because of other mechanisms used by the abduction algorithm. >Keep less than elements in abduction sums (default 6). By elements here we mean distinct variables -- lack of constant multipliers in concrete syntax of types is just a syntactic shortcoming. >Limit on numerical simple abduction steps (default 1000). >Limit on backtracking steps in numerical joint abduction (default 10). >How much to penalize an abduction candidate inequality for containing a constant term (default 4). Too small a value may lead to divergence, e.g. in some examples abduction will pick an answer , which in the following step will force an answer , then , etc. >How much to reward introducing a constraint on so-far unconstrained varialbe, or penalize if negative (default 2). >How much to penalize an abduction candidate inequality for complexity of its coefficients; the coefficient of either the linear or power scaling of the coefficients (default 2.5). >Scale the complexity cost of coefficients linearly with a jump of the given height after coefficient 1 (default 2.0). >>Scale the complexity cost of coefficients according to the given power. >Prefer a bound coming from outer scope, to inequality between two local parameters. In numerical abduction heuristic, such bounds are usually doubly penalized: for having a constant, and non-locality of parameters. >Prefer a bound coming from outer scope, to inequality between two outer scope parameters. Outer-scope constraints sometimes lead to a solution not general enough. >Limit the effect of and prefer_bound_to_outer> to inequalities with a constant 1. This corresponds to an upper bound of an index into a zero-indexed array/matrix/etc. >Do not treat definitions with positive assertions (, ) specially. The special treatment is currently equivalent to passing reward_constrn -1> and . >Penalize abductive guess when the supporting argument comes from the partial answer, instead of from the current premise (default 4). Guesses involving the partial answer are less secure, for example they depend on the order in which the constraint to explain is being processed. >Filter out less general abduction candidate atoms (does not guarantee overall more general answers). The filtering is currently not performed by default to save on computational cost. >Turn off numerical abduction; will not ensure correctness. Numerical abduction uses a brute-force algorithm and will fail to work in reasonable time for complex constraints. However, including the effects of clauses, and inference of postconditions, do not rely on numerical abduction. If the numerical invariant of a typeable (i.e. correct) function follows from facts alone, a call with may still find the correct invariant and postcondition. >Do not add clause to the branch of an expression with a single inequality as condition. Expressions , resp. , with a single inequality as the condition are expanded into expressions , resp. , with conditions on both the branch and the branch. I.e. = n then e1 else e2> is expanded into = n -\ e1 \| _ when n+1 \= m -\ e2>. Passing will result in expansion = n -\ e1 \| _ -\ e2>. The same effect can be achieved for a particular expression by artificially incresing the number of inequalities: = n && m \= n then e1 else e2>. >Do not assume integers as the numerical domain when pruning redundant atoms. >Prune atoms that force a numerical variable to a single value under certain conditions; exclusive with . >In postconditions, check coefficients from (default 3). Numerical constraint generalization is performed by approximately finding the convex hull of the polytopes corresponding to disjuncts. A step in an exact algorithm involves rotating a side along a ridge -- an intersection with another side -- until the side touches yet another side. We approximate by trying out a couple of rotations: convex combinations of the inequalities defining the sides. This parameter decides how many rotations to try. >Limit the number of atoms , in (intermediate and final) postconditions (default 4). Unfortunately, inference time is exponential in the number of atoms of this form. The final postconditions usually have few of these atoms, but a greater number is sometimes needed in the intermediate steps of the main loop.\ >Limit the number of atoms x>, max(a,b)> in (intermediate and final) postconditions (default 4). Unfortunately, inference time is exponential in the number of atoms of this form. The final postconditions usually have few of these atoms, but a greater number is sometimes needed in the intermediate steps of the main loop. >Limit on main algorithm iterations (default 6). Answers found in an iteration of the main algorithm are propagated to use sites in the next iteration. However, for about four initial iterations, each iteration turns on additional processing which makes better sense with the results from the previous iteration propagated. At least three iterations will always be performed. >Keep some equations in term abduction answers even if redundant. Try keeping an initial guess out of a list of candidate equations before trying to drop the equation from consideration. We use fully maximal abduction for single branches, which cannot find answers not implied by premise and conclusion of a branch. But we seed it with partial answer to branches considered so far. Sometimes an atom is required to solve another branch although it is redundant in given branch. does not increase computational cost but sometimes leads to answers that are not most general. This can always be fixed by adding a clause to the definition which uses a type conflicting with the too specific type. >Try to guess equality-between-parameters before considering other possibilities. Implied by but less invasive. >More general invariant at expense of more existential postcondition. To avoid too abstract postconditions, constraint generalization can infer additional constraints over invariant parameters. In rare cases a weaker postcondition but a more general invariant can be beneficial. >Show datatypes encoding existential types, and their identifiers with uses of existential types. The type system in encodes existential types as GADT types, but this representation is hidden from the user. Using exposes the representation as follows. The encodings are exported in files as regular datatypes named , and existential types are printed using syntax >N:>> instead of \>, where is the identifier of an existential type. >Include inequalities in conclusion when solving numerical abduction. This setting leads to more inequalities being tried for addition in numeric abduction answer. >Do not keep information for annotating nodes. This may allow eliminating more variables during initial constraint simplification. >Keep information for annotating .. nodes. Will be set automatically anyway when is passed. >Annotate .. nodes in fallback mode of generation. When verifying the resulting file fails, a retry is made with nodes annotated. This option additionally annotates .. nodes with types in the regenerated file. Let us have a look at tests from the direcotory that need a non-default parameter setting. The program has already been shown above. It is the only example that needs the and settings. The need for comes from having an equation with large coefficient in the answer. The need for term_abduction_timeout> comes from having bigger type shapes to handle during term, i.e. type shape, abduction. <\code> $ ./invargent -inform examples/non_pointwise_leq.gadt File "examples/non_pointwise_leq.gadt", line 12, characters 14-60: No answer in type: Answers do not converge \; Perhaps increase the -iterations_timeout parameter or try one of the options: -more_existential, -prefer_guess, -prefer_bound_to_local. $ ./invargent -inform -prefer_guess examples/non_pointwise_leq.gadt val leq : >a. Nat a > NatLeq (a, a) InvarGenT: Generated file examples/non_pointwise_leq.gadti InvarGenT: Generated file examples/non_pointwise_leq.ml InvarGenT: Command "ocamlc -w -25 -c examples/non_pointwise_leq.ml" exited with code 0 Other examples that need the option: , , . On the other hand, is inferred with default settings. The response from the system does not always include an option which would make the inference succeed. <\code> $ ./invargent -inform examples/liquid_simplex_step_3a.gadt File "examples/liquid_simplex_step_3a.gadt", line 7, characters 49-1651: No answer in type: Answers do not converge \; Perhaps do not pass the -no_dead_code flag. Perhaps increase the -iterations_timeout parameter or try one of the options: -more_existential, -prefer_guess, -prefer_bound_to_local. Perhaps some definition is used with requirements on its inferred postcondition not warranted by the definition. $ ./invargent -inform -prefer_bound_to_local -only_off_by_1 \\ examples/liquid_simplex_step_3a.gadt val main_step3_test : >k, n[1 > n > 3 > k]. Matrix (n, k) > Float InvarGenT: Generated file examples/liquid_simplex_step_3a.gadti InvarGenT: Generated file examples/liquid_simplex_step_3a.ml File "examples/liquid_simplex_step_3a.ml", line 43, characters 8-9: Warning 26: unused variable m. InvarGenT: Command "ocamlc -w -25 -c examples/liquid_simplex_step_3a.ml" exited with code 0 The other examples that need the option, but not the only_off_by_1> option: , , . <\code> $ ./invargent -inform examples/pointwise_zip2_harder.gadt val zip2 : >a, b. Zip2 (a, b) > a > b InvarGenT: Generated file examples/pointwise_zip2_harder.gadti InvarGenT: Generated file examples/pointwise_zip2_harder.ml File "examples/pointwise_zip2_harder.ml", line 19, characters 21-32: Error: This kind of expression is not allowed as right-hand side of `let rec' InvarGenT: Command "ocamlc -w -25 -c examples/pointwise_zip2_harder.ml" exited with code 2 InvarGenT: Regenerated file examples/pointwise_zip2_harder.ml File "examples/pointwise_zip2_harder.ml", line 21, characters 21-32: Error: This kind of expression is not allowed as right-hand side of `let rec' InvarGenT: Command "ocamlc -w -25 -c examples/pointwise_zip2_harder.ml" exited with code 2 $ ./invargent -inform -no_ml examples/pointwise_zip2_harder.gadt val zip2 : >a, b. Zip2 (a, b) > a > b InvarGenT: Generated file examples/pointwise_zip2_harder.gadti The example is not compatible with the pass-by-value semantics. We can avoid the complaint of the OCaml compiler by passing either the flag or the flag. More interestingly, we can notice that the file is generated twice. This happens because , noticing the failure, generates an OCaml source with more type information, as if the option was used. The examples and contain assertions, but are nearly as hard as , respectively. They need the option to not switch to settings tuned for cases where assertions capture the harder aspects of the invariants to infer. Unfortunately, inference fails for some examples regardless of parameters setting. We discuss them in the next section. Inference> Type inference for the type system underlying is undecidable. In some cases, the failure to infer a type is not at all problematic. Consider this example due to Chuan-kai Lin: <\code> datatype EquLR : type * type * type datacons EquL : >a, b. EquLR (a, a, b) datacons EquR : >a, b. EquLR (a, b, b) datatype Box : type datacons Cons : >a. a > Box a external let eq : >a. a > a > Bool = "(=)" \; let vary = fun e y -\ \ \ match e with \ \ \| EquL, EquL -\ eq y "c" \ \ \| EquR, EquR -\ Cons (match y with True -\ 5 \| False -\ 7) Although has multiple types, it is a contrived example unlikely to have an intended type. However, not all cases of failure to infer a type for a correct program are due to contrived examples. The problems are not insurmountable theoretically. The algorithms used in the inference can incorporate heuristics for special cases, and can be modified to do a more exhaustive search. The example fails because of the limitations of the sort in representing disequalities. <\code> datatype Z datatype S : type datatype List : type * num datacons LNil : >a. List(a, Z) datacons LCons : >a, b. a * List(a, b) > List(a, S b) \; let head = function \ \ \| LCons (x, _) -\> x \ \ \| LNil -\> assert false If we omit the branch, we get the technically correct but inadequate type >a, b. List(a, b) > a>, because the type system does not guarantee exhaustiveness of the pattern matching. The intended type is >a, b. List(a, S b) > a>. The example is inferred an insufficiently general type >a, b. FunDesc (b, b) > FunDesc (b, a) > FunDesc (b, a)>. <\code> datatype FunDesc : type * type datacons FDI : >a. FunDesc (a, a) datacons FDC : >a, b. b > FunDesc (a, b) datacons FDG : >a, b. (a > b) > FunDesc (a, b) external fd_fun : >a, b. FunDesc (a, b) > a > b \; let fd_comp fd1 fd2 = \ \ let o f g x = f (g x) in \ \ match fd1 with \ \ \ \ \| FDI -\> fd2 \ \ \ \ \| FDC b -\>\ \ \ \ \ \ \ (match fd2 with \ \ \ \ \ \ \ \ \| FDI -\> fd1 \ \ \ \ \ \ \ \ \| FDC c -\> FDC (fd_fun fd2 b) \ \ \ \ \ \ \ \ \| FDG g -\> FDC (fd_fun fd2 b)) \ \ \ \ \| FDG f -\> \ \ \ \ \ \ (match fd2 with \ \ \ \ \ \ \ \ \| FDI -\> fd1 \ \ \ \ \ \ \ \ \| FDC c -\> FDC c \ \ \ \ \ \ \ \ \| FDG g -\> FDG (o (fd_fun fd2) f)) This happens because the second argument is not expanded when is equal to . Type inference cannot carry out the different reasoning steps leading to the more general type. In the example it turns out to be too hard to infer the full postcondition. <\code> datatype Array : type * num external let array_make : \ \ >n, a [0>n]. Num n > a > Array (a, n) = "fun a b -\ Array.make a b" external let array_get : >n, k, a [0>k > k+1>n]. Array (a, n) > Num k > a = \ \ "fun a b -\ Array.get a b" external let array_length : \ \ >n, a [0>n]. Array (a, n) > Num n = "fun a -\ Array.length a" datatype LinOrder datacons LE : LinOrder datacons GT : LinOrder datacons EQ : LinOrder external let compare : >a. a > a > LinOrder = \ \ "fun a b -\> let c = Pervasives.compare a b in \ \ \ \ \ \ \ \ \ \ \ \ \ \ if c \< 0 then LE else if c \> 0 then GT else EQ" external let equal : >a. a > a > Bool = "fun a b -\ a = b" external let div2 : >n. Num (2 n) > Num n = "fun x -\ x / 2" \; let bsearch key vec = \ \ let rec look key vec lo hi = \ \ \ \ eif lo \<= hi then \ \ \ \ \ \ \ \ let m = div2 (hi + lo) in \ \ \ \ \ \ \ \ let x = array_get vec m in \ \ \ \ \ \ \ \ ematch compare key x with \ \ \ \ \ \ \ \ \ \ \| LE -\> look key vec lo (m + (-1)) \ \ \ \ \ \ \ \ \ \ \| GT -\> look key vec (m + 1) hi \ \ \ \ \ \ \ \ \ \ \| EQ -\> eif equal key x then m else -1 \ \ \ \ else -1 in \ \ look key vec 0 (array_length vec + (-1)) \ We get the result type >n[0 > n + 1].Num n> instead of >k[k > n > 0 > k + 1].Num k>. The inference of the intended type succeeds after we introduce an appropriate assertion, e.g. . Alternatively, we could include a use case for where the full postcondition is required. Examples , and result in uninformative, empty postconditions, because to tell more would require inspecting the behavior of the respective function across recursive calls. To save space, we list just the function definition from : <\code> let rec enter_var arr2 n j c j' = \ \ eif j' + 2 \<= n then \ \ \ \ let c' = matrix_get arr2 0 j' in \ \ \ \ eif less c' c then enter_var arr2 n j' c' (j'+1) \ \ \ \ else enter_var arr2 n j c (j'+1) \ \ else j Fortunately, if the function is used in the same toplevel definition in which it is defined, use-site requirements facilitate the inference of the intended postcondition. The example poses too big a challenge for . To get it pass the inference, we streamline one of the nested definitions, to not introduce another, unnecessary level of nesting. This gives the example , which needs to be run with the option . Additionally, we can relax the constraint on the processed portion of the matrix, coming from the restriction on the matrix size intended in the original source of the example. In , the whole matrix is processed and the inferred type is most general, under the default settings -- no need to pass any options to . The reason is too difficult for is that the nesting interferes with the propagation of use-site constraints to the postcondition of the nested definition (the inside ). Inference works for , because the assertion provides the required information to infer the invariants directly. <\initial> <\collection> <\references> <\collection> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |\>|5>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <\auxiliary> <\collection> <\associate|bib> StratifiedGADTs ComplDecidableGADTs PointwiseGADTs simonet-pottier-hmg-toplas StratifiedGADTs ComplDecidableGADTs PointwiseGADTs ADTReconstruct InterpolationInfer DML99 DML99 KnowlesF07 InterpolationInfer DML99 PointwiseGADTs DSolvePaper PracticalGADTsInfer PracticalGADTsInfer DSolvePaper DSolvePaper DML99 DMLArrays DSolvePaper SpecLearnArrays MartinLof Cayenne IdrisCurrent IdrisEarly DML99 simonet-pottier-hmg-toplas OutsideIn PointwiseGADTs DSolvePaper DSolveTechRep DSolveThesis AbductionSolvMaher simonet-pottier-hmg-toplas DML99 DMLThesis IndexedTypes ExTyADTs HMX XiGRDTs CheneyHinzePhantomTypes Sheard04 simonet-pottier-hmg-toplas IndexedTypes simonet-pottier-hmg-toplas simonet-pottier-hmg-toplas simonet-pottier-hmg-toplas simonet-pottier-hmg-toplas OutsideIn ComplDecidableGADTs OutsideIn OutsideIn OutsideIn OutsideIn OutsideIn AbductionSolvMaher OutsideIn OutsideIn PracticalGADTsInfer PointwiseGADTs PracticalGADTsInfer Milner78 Mycroft84 PracticalGADTsInfer PracticalGADTsInfer PracticalGADTsInfer RefinementFreemanPfenning HMX Flanagan06 KnowlesF07 DSolvePaper AbstractLiquid DSolvePaper DSolveTechRep DSolveThesis DSolvePaper AssertionGraphs AbstractStateGraphs TypeQualifiers DSolvePaper DSolvePaper KnowlesF07 AbstractLiquid SulzmannAbdGADTsRep SulzmannAbdGADTs AbdEADTs AbductionMaher AbductionSolvMaher AbductionLinArithMaher AbductionSolvMaher AbductionSolvMaher AbductionSolvMaher AbductionMaher SulzmannAbdGADTs AbdEADTs AbductionSolvMaher AbductionLinArithMaher simonet-pottier-hmg-toplas simonet-pottier-hmg-toplas simonet-pottier-hmg-toplas simonet-pottier-hmg-toplas simonet-pottier-hmg-toplas KnowlesF07 AbductionSolvMaher AbdEADTs Cousot77 AbductionSequents AbductionMaher AbductionMaher UnificationBaader UnificationBaader AbductionMaher AbductionMaher InductLoopInv simulRigidEUnifUndec DisunificationComon DisunificationComon AbductionMaher AbductionSolvMaher AbductionMaher MaherParamSubstitutions AbductionSolvMaher AbductionSolvMaher PracticalGADTsInfer AbductionSolvMaher AbductionLinArithMaher UnificationBaader AntiUnifAlg ConvexHull PracticalGADTsInfer PracticalGADTsInfer OutsideIn PointwiseGADTs PointwiseGADTs DSolvePaper DSolvePaper DSolveThesis DSolvePaper PracticalGADTsInfer PracticalGADTsInfer PracticalGADTsInfer DML99 DML99 DML99 simonet-pottier-hmg-toplas Henglein93 Cousot77 Mycroft84 KnowlesF07 regis-gianas-pottier-08 DSolvePaper AbstractLiquid AbdEADTs SulzmannAbdGADTs AbdEADTs SulzmannAbdGADTs AbductionMaher AbductionSolvMaher UnificationBaader AbductionSolvMaher AbductionLinArithMaher HeytingAbdMaher InterpolationInfer KnowlesF07 LightDML CEGAR SpecLearnArrays SpecLearnArrays ADTReconstruct StratifiedGADTs ComplDecidableGADTs PointwiseGADTs PracticalGADTsInfer OutsideIn PracticalGADTsInfer ADTReconstruct PracticalGADTsInfer ADTReconstruct InductLoopInv InductLoopInv InductLoopInv InductLoopInv InductLoopInv InductLoopInv LoopQuantElim LoopQuantElim RodriKapurICTAC04 RodriKapurJSC07 LoopQuantElim RodriKapurICTAC04 RodriKapurICTAC04 RodriKapurJSC07 AntiUnifPlotkin AntiUnifReynolds AntiUnifInv ConvexHull DSolvePaper AbstractLiquid LightDML AbductionSolvMaher simonet-pottier-hmg-toplas simonet-pottier-hmg-toplas simonet-pottier-hmg-toplas simonet-pottier-hmg-toplas AbductionSolvMaher PracticalGADTsInfer AbductionSolvMaher ArithQuantElim ArithQuantElim AntiUnifAlg ConvexHull ConvexHull OutsideIn PointwiseGADTs PracticalGADTsInfer PracticalGADTsInfer PracticalGADTsInfer PracticalGADTsInfer PracticalGADTsInfer PracticalGADTsInfer PointwiseGADTs PracticalGADTsInfer PracticalGADTsInfer PracticalGADTsInfer PracticalGADTsInfer PracticalGADTsInfer PracticalGADTsInfer PracticalGADTsInfer <\associate|table> > > |HMG>|> |HMG>|> |HMG>|> |HMG>: expressions and clauses|> > > > |MMG>|: patterns>|> |MMG>: expressions|> |MMG>: clauses|> > > > > > > |MMG>>|> > |Abd,|\>,,C|\>|)>>|> |LUB|\>|)>=\|\>.A>|> |Split,|\>,A,|\>>|\>,>|\>|)>>|> |k> of solving for predicate variables|> > > > > <\associate|toc> |math-font-series||font-shape||Abstract> |.>>>>|> |math-font-series||font-shape||Streszczenie> |.>>>>|> |math-font-series||font-shape||Acknowledgements> |.>>>>|> |math-font-series||font-shape||1.Introduction> |.>>>>|> 1.1.Contributions |.>>>>|> 1.2.Examples |.>>>>|> |math-font-series||font-shape||2.Background and Related Work> |.>>>>|> 2.1.The DML System |.>>>>|> |2.1.1.The Type System |.>>>>|> > |2.1.2.Bidirectional Type Inference |.>>>>|> > |2.1.3.Relevance |.>>>>|> > 2.2.The |HMG> Formalization |.>>>>|> |2.2.1.The Untyped Calculus |.>>>>|> > |2.2.2.The |HMG> Type System |.>>>>|> > |2.2.3.Constraint Derivation |.>>>>|> > |2.2.4.Relevance |.>>>>|> > 2.3.The |OutsideIn> System |.>>>>|> |2.3.1.Type Inference |.>>>>|> > |2.3.2.Relevance |.>>>>|> > 2.4.Pointwise GADTs |.>>>>|> |2.4.1.Type Inference |.>>>>|> > |2.4.2.Relevance |.>>>>|> > 2.5.Liquid Types |.>>>>|> |2.5.1.The Type System |.>>>>|> > |2.5.2.Liquid Types Inference |.>>>>|> > |2.5.3.Relevance |.>>>>|> > 2.6.Herbrand Constraint Abduction |.>>>>|> |2.6.1.Relevance |.>>>>|> > |math-font-series||font-shape||3.The Type System> |.>>>>|> 3.1.The Language of Constraints |.>>>>|> 3.2.The Type System with GADTs |.>>>>|> 3.3.Type Inference Constraints |.>>>>|> 3.4.Existential Types |.>>>>|> 3.5.Type Inference Constraints for Existential Types |.>>>>|> 3.6.Semantics by Reduction to |HMG> |.>>>>|> |math-font-series||font-shape||4.Solving Second Order Constraints> |.>>>>|> 4.1.Overview of Solving for Predicate Variables |.>>>>|> 4.2.Constraint Abduction |.>>>>|> |4.2.1.Formulating the Joint Constraint Abduction Problem |.>>>>|> > |4.2.2.Abduction Algorithm for The Combination of Domains |.>>>>|> > |4.2.3.Joint Constraint Abduction |.>>>>|> > |4.2.4.Simple Constraint Abduction |.>>>>|> > |4.2.4.1.Abduction for Terms |.>>>>|> > |4.2.4.2.Abduction for Linear Arithmetic |.>>>>|> > 4.3.Constraint Generalization |.>>>>|> |4.3.1.Algorithm for Combining Domains |.>>>>|> > |4.3.2.Linear Arithmetic |.>>>>|> > |4.3.3.Abductive Constraint Generalization |.>>>>|> > 4.4.Negative Constraints |.>>>>|> 4.5.Details of Solving for Predicate Variables |.>>>>|> |math-font-series||font-shape||5.|InvarGenT>: Tests and Limitations> |.>>>>|> 5.1.Benchmarks |.>>>>|> 5.2.|InvarGenT> Failure Cases |.>>>>|> |5.2.1.The Need to Expand Pattern Variables |.>>>>|> > |5.2.2.Constraints Shared by Constructors of a Datatype |.>>>>|> > |5.2.3.Negative Constraints in the Sort of Terms |.>>>>|> > |5.2.4.Insufficient Context to Infer Postconditions |.>>>>|> > |5.2.5.Insufficient Search |.>>>>|> > |5.2.6.Nested Definitions with Tied Postconditions |.>>>>|> > |math-font-series||font-shape||6.Conclusions> |.>>>>|> 6.1.Related Work |.>>>>|> 6.2.Future Work |.>>>>|> 6.3.Summary |.>>>>|> |math-font-series||font-shape||Bibliography> |.>>>>|> |math-font-series||font-shape||Appendix A.Proofs> |.>>>>|> A.1.The Type System |.>>>>|> |A.1.1.The Logic of Constraints |.>>>>|> > |A.1.2.The GADT Type System |.>>>>|> > |A.1.3.Existential Types |.>>>>|> > |A.1.4.Semantics by Reduction to |HMG> |.>>>>|> > A.2.Constraint Abduction |.>>>>|> |A.2.1.Formulating the Joint Constraint Abduction Problem |.>>>>|> > |A.2.2.Abduction Algorithm for The Combination of Domains |.>>>>|> > A.3.Constraint Generalization |.>>>>|> A.4.Solving for Predicate Variables |.>>>>|> |math-font-series||font-shape||Appendix B.Algorithmic Details> |.>>>>|> B.1.Generating and Normalizing Formulas |.>>>>|> |B.1.1.Normalization |.>>>>|> > |B.1.1.1.Implementation Details |.>>>>|> > |B.1.2.Simplification |.>>>>|> > B.2.Abduction |.>>>>|> |B.2.1.Abduction for Terms with Alien Subterms |.>>>>|> > |B.2.2.Joint Constraint Abduction |.>>>>|> > |B.2.3.Simple Constraint Abduction for Terms |.>>>>|> > |B.2.3.1.Heuristic for Better Answers to Invariants |.>>>>|> > |B.2.4.Simple Constraint Abduction for Linear Arithmetics |.>>>>|> > B.3.Constraint Generalization |.>>>>|> |B.3.1.Extended Convex Hull |.>>>>|> > |B.3.2.Issues in Inferring Postconditions |.>>>>|> > |B.3.3.Abductive Constraint Generalization |.>>>>|> > B.4.Incorporating Negative Constraints |.>>>>|> B.5.|opti> and |subopti>: |minimum> and |maximum> Relations in |language||num> |.>>>>|> |B.5.1.Normalization, Validity and Implication Checking |.>>>>|> > |B.5.2.Abduction |.>>>>|> > |B.5.3.Constraint Generalization |.>>>>|> > B.6.Solving for Predicate Variables |.>>>>|> |B.6.1.Solving for Predicates in Premises |.>>>>|> > |B.6.2.Solving for Existential Types Predicates and Main Algorithm |.>>>>|> > |B.6.3.Stages of Iteration |.>>>>|> > |B.6.4.Implementation Details |.>>>>|> > B.7.Generating OCaml Source and Interface Code |.>>>>|> |math-font-series||font-shape||Appendix C.Source Code of Examples> |.>>>>|> C.1.Incompleteness Example for |language||OutsideIn>: Function |language||rx> |.>>>>|> C.2.Pointwise Examples |.>>>>|> |C.2.1.Function |language||rotate> |.>>>>|> > |C.2.2.Function |language||zip2>: |N>-way |language||zip_with> |.>>>>|> > |C.2.3.Function |language||rotl> |.>>>>|> > |C.2.4.Function |language||ins> |.>>>>|> > |C.2.5.Function |language||extract> |.>>>>|> > |C.2.6.Function |language||run_state> |.>>>>|> > C.3.Non-Pointwise Examples |.>>>>|> |C.3.1.Function |language||joint> |.>>>>|> > |C.3.2.Function |language||rotr> |.>>>>|> > |C.3.3.Function |language||delmin> |.>>>>|> > |C.3.4.Function |language||fd_comp> |.>>>>|> > |C.3.5.Function |language||zip1>: |N>-way |language||zip_with> |.>>>>|> > |C.3.6.Function |language||leq> |.>>>>|> > |C.3.7.Function |language||run_state> |.>>>>|> > C.4.Run-time Type Representations |.>>>>|> |C.4.1.Function |language||eval> |.>>>>|> > |C.4.2.Function |language||equal> |.>>>>|> > C.5.Lists with Length |.>>>>|> |C.5.1.Function |language||head> |.>>>>|> > |C.5.2.Function |language||append> |.>>>>|> > |C.5.3.Function |language||flatten_pairs> |.>>>>|> > |C.5.4.Function |language||filter> |.>>>>|> > |C.5.5.Function |language||zip> |.>>>>|> > C.6.Binary Numbers |.>>>>|> |C.6.1.Function |language||plus> |.>>>>|> > |C.6.2.Function |language||increment> |.>>>>|> > |C.6.3.Function |language||bitwise_or> |.>>>>|> > C.7.AVL Trees |.>>>>|> C.8.Arrays and Matrices |.>>>>|> |C.8.1.Program |language||dotprod> |.>>>>|> > |C.8.2.Program |language||bcopy> |.>>>>|> > |C.8.3.Program |language||bsearch> |.>>>>|> > |C.8.4.Function |language||bsearch2> |.>>>>|> > |C.8.5.Program |language||queen> |.>>>>|> > |C.8.6.Function |language||swap_interval> |.>>>>|> > |C.8.7.Program |language||isort> |.>>>>|> > |C.8.8.Program |language||tower> |.>>>>|> > |C.8.9.Program |language||matmult> |.>>>>|> > |C.8.10.Program |language||heapsort> |.>>>>|> > |C.8.11.Program |language||simplex> |.>>>>|> > |C.8.12.Program |language||gauss> |.>>>>|> > |C.8.13.Program |language||fft> |.>>>>|> > |math-font-series||font-shape||Appendix D.|InvarGenT>: Manual> |.>>>>|> D.1.Introduction |.>>>>|> D.2.Tutorial |.>>>>|> D.3.Syntax |.>>>>|> D.4.Solver Parameters and CLI |.>>>>|> D.5.Limitations of Current |InvarGenT> Inference |.>>>>|>