Decidable structures between Church-style and Curry-style

It is well-known that the type-checking and type-inference problems are undecidable for second order lambda-calculus in Curry-style, although those for Church-style are decidable. What causes the differences in decidability and undecidability on the problems? We examine crucial conditions on terms for the (un)decidability property from the viewpoint of partially typed terms, and what kinds of type annotations are essential for (un)decidability of type-related problems. It is revealed that there exists an intermediate structure of second order lambda-terms, called a style of hole-application, between Church-style and Curry-style, such that the type-related problems are decidable under the structure. We also extend this idea to the omega-order polymorphic calculus F-omega, and show that the type-checking and type-inference problems then become undecidable

Relating Church-Style and Curry-Style Subtyping

Type theories with higher-order subtyping or singleton types are examples of systems where computation rules for variables are affected by type information in the context. A complication for these systems is that bounds declared in the context do not interact well with the logical relation proof of completeness or termination. This paper proposes a natural modification to the type syntax for F-Omega-Sub, adding variable's bound to the variable type constructor, thereby separating the computational behavior of the variable from the context. The algorithm for subtyping in F-Omega-Sub can then be given on types without context or kind information. As a consequence, the metatheory follows the general approach for type systems without computational information in the context, including a simple logical relation definition without Kripke-style indexing by context. This new presentation of the system is shown to be equivalent to the traditional presentation without bounds on the variable type constructor.Comment: In Proceedings ITRS 2010, arXiv:1101.410

Typability and type inference in atomic polymorphism

It is well-known that typability, type inhabitation and type inference are undecidable in the Girard-Reynolds polymorphic system F. It has recently been proven that type inhabitation remains undecidable even in the predicative fragment of system F in which all universal instantiations have an atomic witness (system Fat). In this paper we analyze typability and type inference in Curry style variants of system Fat and show that typability is decidable and that there is an algorithm for type inference which is capable of dealing with non-redundancy constraints.The second author acknowledges the support of FCT — Fundação para a Ciência e a Tecnologia under the projects UIDB/04561/2020, UIDB/00408/2020 and UIDP/00408/2020, and she is also grateful to CMAFcIO — Centro de Matemática, Aplicações Fundamentais e Investigação Operacional and to LASIGE — Computer Science and Engineering Research Centre (Universidade de Lisboa).info:eu-repo/semantics/publishedVersio

Typability and type inference in atomic polymorphism

It is well-known that typability, type inhabitation and type inference are undecidable in the Girard-Reynolds polymorphic system F. It has recently been proven that type inhabitation remains undecidable even in the predicative fragment of system F in which all universal instantiations have an atomic witness (system Fat). In this paper we analyze typability and type inference in Curry style variants of system Fat and show that typability is decidable and that there is an algorithm for type inference which is capable of dealing with non-redundancy constraints.The second author acknowledges the support of FCT — Fundação para a Ciência e a Tecnologia under the projects UIDB/04561/2020, UIDB/00408/2020 and UIDP/00408/2020, and she is also grateful to CMAFcIO — Centro de Matemática, Aplicações Fundamentais e Investigação Operacional and to LASIGE — Computer Science and Engineering Research Centre (Universidade de Lisboa).info:eu-repo/semantics/publishedVersio

Elements of mathematics and logic for computer program analysis

1 Introduction 2 Induction and sequences 2.1 Induction on natural numbers 2.2 Words and sequences 2.3 A digression on set theory 2.4 Induction on words 2.5 Grammar rules and string rewriting 3 Terms 3.1 Definition of terms 3.2 Knaster-Tarski's fixpoint theorem (1927) 3.3 Kleene's fixpoint theorem (1952?) 3.4 Pattern matching and term rewriting 3.5 Models of a term algebra 4 Lambda-calculus 4.1 Definition of λ-calculus 4.2 Church-computable functions 4.3 Kleene-computable functions 4.4 Turing-computable functions 5 Simply-typed lambda-calculus 5.1 Curry-style simply-typed λ-calculus . 5.2 Unification 5.3 Type inference 5.4 Church-style simply-typed λ-calculus 6 First-order logic 6.1 Formulas and truth 6.2 Provability and deduction systems 6.3 Proof terms and Curry-Howard correspondence 7 To go further 8 Solutions to exercises 8.1 Section 2: Induction and sequences 8.2 Section 3: Terms 8.3 Section 4: Lambda-calculus 8.4 Section 5: Simply-typed lambda-calculus 8.5 Section 6: First-order logicMasterIn order to be able to rigorously prove the correctness of a program, one must have a formal definition of: what is a program, syntactically; how it is evaluated, that is, what is its semantics; how to formulate the properties we are interested in; and how to prove them. All this requires to understand some basic mathematical notions like induction, terms, formulas, deduction, etc. These notes are intended to give an introduction to some of these notions

Several types of types in programming languages

Types are an important part of any modern programming language, but we often forget that the concept of type we understand nowadays is not the same it was perceived in the sixties. Moreover, we conflate the concept of "type" in programming languages with the concept of the same name in mathematical logic, an identification that is only the result of the convergence of two different paths, which started apart with different aims. The paper will present several remarks (some historical, some of more conceptual character) on the subject, as a basis for a further investigation. The thesis we will argue is that there are three different characters at play in programming languages, all of them now called types: the technical concept used in language design to guide implementation; the general abstraction mechanism used as a modelling tool; the classifying tool inherited from mathematical logic. We will suggest three possible dates ad quem for their presence in the programming language literature, suggesting that the emergence of the concept of type in computer science is relatively independent from the logical tradition, until the Curry-Howard isomorphism will make an explicit bridge between them.Comment: History and Philosophy of Computing, HAPOC 2015. To appear in LNC