Results 11  20
of
22
Using dependent types to certify the safety of assembly code
 In SAS’05
, 2005
"... Abstract. There are many sourcelevel analyses or instrumentation tools that enforce various safety properties. In this paper we present an infrastructure that can be used to check independently that the assembly output of such tools has the desired safety properties. By working at assembly level we ..."
Abstract

Cited by 6 (1 self)
 Add to MetaCart
Abstract. There are many sourcelevel analyses or instrumentation tools that enforce various safety properties. In this paper we present an infrastructure that can be used to check independently that the assembly output of such tools has the desired safety properties. By working at assembly level we avoid the complications with unavailability of source code, with sourcelevel parsing, and we certify the code that is actually deployed. The novel feature of the framework is an extensible dependentlytyped framework that supports type inference and mutation of dependent values in memory. The type system can be extended with new types as needed for the sourcelevel tool that is certified. Using these dependent types, we are able to express the invariants enforced by CCured, a sourcelevel instrumentation tool that guarantees type safety in legacy C programs. We can therefore check that the x86 assembly code resulting from compilation with CCured is in fact typesafe. 1
Type Theoretical Foundations for Data Structures, Classes, and Objects
, 2004
"... In this thesis we explore the question of how to represent programming data structures in a constructive type theory. The basic data structures in programing languages are records and objects. Most known papers treat such data structure as primitive. That is, they add new primitive type constructors ..."
Abstract

Cited by 5 (0 self)
 Add to MetaCart
In this thesis we explore the question of how to represent programming data structures in a constructive type theory. The basic data structures in programing languages are records and objects. Most known papers treat such data structure as primitive. That is, they add new primitive type constructors and supporting axioms for records and objects. This approach is not satisfactory. First of all it complicates a type theory a lot. Second, the validity of the new axioms is not easily established. As we will see the naive choice of axioms can lead to contradiction even in the simplest cases. We will show that records and objects can be defined in a powerful enough type theory. We will also show how to use these type constructors to define abstract data structure. BIOGRAPHICAL SKETCH Alexei Kopylov was born in Moscow State University on April 2, 1974. His parents were students in the Department of Mathematics and Mechanics there. First year of his life Alexei lived in a student dormitory in the main building of the Moscow State University. Then his parents moved to Chernogolovka, a cozy scientific town near Moscow. Alexei returned to Moscow State University as a student in 1991. Five years later he graduated from the Department of Mathematics and Mechanics and entered the graduate school of the same Department.
Programming Language Semantics in Foundational Type Theory
 In Proc. the IFIP TC2/WG2.2,2.3 International Conference on Programming Concepts and Methods (PROCOMET’98
, 1996
"... There are compelling benefits to using foundational type theory as a framework for programming language semantics. I give a semantics of an expressive programming calculus in the foundational type theory of Nuprl. Previous typetheoretic semantics have used less expressive type theories, or have sacr ..."
Abstract

Cited by 5 (1 self)
 Add to MetaCart
There are compelling benefits to using foundational type theory as a framework for programming language semantics. I give a semantics of an expressive programming calculus in the foundational type theory of Nuprl. Previous typetheoretic semantics have used less expressive type theories, or have sacrificed important programming constructs such as recursion and modules. The primary mechanisms of this semantics are partial types, for typing recursion, set types, for encoding power and singleton kinds, which are used for subtyping and module programming, and very dependent function types, for encoding signatures. Keywords Semantics, program verification, type theory, functional programming 1 INTRODUCTION Type theory has become a popular framework for formal reasoning in computer science and has formed the basis for a number of automated deduction systems, including Automath, Nuprl, HOL and Coq, among others. In addition to formalizing mathematics, these systems are widely used for the a...
Naïve computational type theory
 Proof and SystemReliability, Proceedings of International Summer School Marktoberdorf, July 24 to August 5, 2001, volume 62 of NATO Science Series III
, 2002
"... The basic concepts of type theory are fundamental to computer science, logic and mathematics. Indeed, the language of type theory connects these regions of science. It plays a role in computing and information science akin to that of set theory in pure mathematics. There are many excellent accounts ..."
Abstract

Cited by 5 (1 self)
 Add to MetaCart
The basic concepts of type theory are fundamental to computer science, logic and mathematics. Indeed, the language of type theory connects these regions of science. It plays a role in computing and information science akin to that of set theory in pure mathematics. There are many excellent accounts of the basic ideas of type theory, especially at the interface of computer science and logic — specifically, in the literature of programming languages, semantics, formal methods and automated reasoning. Most of these are very technical, dense with formulas, inference rules, and computation rules. Here we follow the example of the mathematician Paul Halmos, who in 1960 wrote a 104page book called Naïve Set Theory intended to make the subject accessible to practicing mathematicians. His book served many generations well. This article follows the spirit of Halmos ’ book and introduces type theory without recourse to precise axioms and inference rules, and with a minimum of formalism. I start by paraphrasing the preface to Halmos ’ book. The sections of this article follow his chapters closely. Every computer scientist agrees that every computer scientist must know some type theory; the disagreement begins in trying to decide how much is some. This article contains my partial answer to that question. The purpose of the article is to tell the beginning student of advanced computer science the basic type theoretic facts of life, and to do so with a minimum of philosophical discourse and logical formalism. The point throughout is that of a prospective computer scientist eager to study programming languages, or database systems, or computational complexity theory, or distributed systems or information discovery. In type theory, “naïve ” and “formal ” are contrasting words. The present treatment might best be described as informal type theory from a naïve point of view. The concepts are very general and very abstract; therefore they may
A Predicative TypeTheoretic Interpretation of Objects
, 1997
"... Predicative type theories are powerful tools for giving foundational interpretations of programming languages. Due to their explicit inductive construction, predicative type theories have multiple mathematical models that provide precise definitions of programming language features. However, not all ..."
Abstract

Cited by 4 (0 self)
 Add to MetaCart
Predicative type theories are powerful tools for giving foundational interpretations of programming languages. Due to their explicit inductive construction, predicative type theories have multiple mathematical models that provide precise definitions of programming language features. However, not all features have predicative interpretations, and current interpretations of objects rely on impredicative type theories, such as Girard's System F, because of the difficulty in specifying a type for objects in the presence of selfapplication. In this paper we show that objects have a predicative interpretation. We show that predicativity is associated with method monotonicity, and that binary methods prevent the inductive type construction. Our interpretation differs from impredicative accounts by replacing the use of recursive types for objects with conditions for method polymorphism over the self type. We further give a propositional meaning to objects in the type theory, providing a calc...
Inheritance of Proofs
, 1996
"... The CurryHoward isomorphism, a fundamental property shared by many type theories, establishes a direct correspondence between programs and proofs. This suggests that the same structuring principles that ease programming be used to simplify proving as well. To exploit objectoriented structuring me ..."
Abstract

Cited by 4 (0 self)
 Add to MetaCart
The CurryHoward isomorphism, a fundamental property shared by many type theories, establishes a direct correspondence between programs and proofs. This suggests that the same structuring principles that ease programming be used to simplify proving as well. To exploit objectoriented structuring mechanisms for verification, we extend the objectmodel of Pierce and Turner, based on the higher order typed calculus F ! , with a proof component. By enriching the (functional) signature of objects with a specification, the methods and their correctness proofs are packed together in the objects. The uniform treatment of methods and proofs gives rise in a natural way to objectoriented proving principles  including inheritance of proofs, late binding of proofs, and encapsulation of proofs  as analogues to objectoriented programming principles. We have used Lego, a typetheoretic proof checker, to explore the feasibility of this approach. In particular, we have verified a small hier...
Naïve Type Theory
, 2002
"... This article follows the spirit of Halmos' book and introduces type theory without recourse to precise axioms and inference rules, and with a minimum of formalism. I start by paraphrasing the preface to Halmos' book. The sections of this article follow his chapters closely. Every computer scientist ..."
Abstract
 Add to MetaCart
This article follows the spirit of Halmos' book and introduces type theory without recourse to precise axioms and inference rules, and with a minimum of formalism. I start by paraphrasing the preface to Halmos' book. The sections of this article follow his chapters closely. Every computer scientist agrees that every computer scientist must know some type theory; the disagreement begins in trying to decide how much is some. This article contains my partial answer to that question. The purpose of the article is to tell the beginning student of advanced computer science the basic type theoretic facts of life, and to do so with a minimum of philosophical discourse and logical formalism. The point throughout is that of a prospective computer scientist eager to study programming languages, or database systems, or computational complexity theory, or distributed systems or information discovery
Caltech
"... Abstract This article presents a theory of classes and inheritance built on top of constructive typetheory. Classes are defined using dependent and very dependent function types that are found in the Nuprl constructive type theory. Inheritance is defined in terms of a general subtypingrelation over ..."
Abstract
 Add to MetaCart
Abstract This article presents a theory of classes and inheritance built on top of constructive typetheory. Classes are defined using dependent and very dependent function types that are found in the Nuprl constructive type theory. Inheritance is defined in terms of a general subtypingrelation over the underlying types. Among the basic types is the intersection type which plays a critical role in the applications because it provides a method of composing program components.The class theory is applied to defining algebraic structures such as monoids, groups, rings, etc. and relating them. It is also used to define communications protocols as infinite stateautomata. The article illustrates the role of these formal automata in defining the services of a distributed group communications system. In both applications the inheritance mechanismsallow reuse of proofs and the statement of general properties of system composition. 1 Introduction The results presented here were created as part of a broad effort to understand how to use computers to significantly automate the design and development of software systems. This is one of the main goals of the "PRL project " at Cornell1. One of the basic tenants of our approach to this task is that we should seek the most naturally expressive formal language in which to specify the services, characteristics and constraints that a software system must satisfy. If the formal expression of services is close to a natural one, then people can more readily use it. We also want to allow very compact notations for concepts used to describe systems, and this effect is also a consequence of expressive richness. We have discovered that it is frequently the case that the system we have built to implement one formal language will support an even richer one. So we have come to see our work as also progressively improving the reach of our tools.
An Implementation of Type:Type
, 2000
"... We present a denotational semantics of a type system with dependent types, where types are interpreted as finitary projections. We prove then the correctness of a typechecking algorithm w.r.t. this semantics. In this way, we can justify some simple optimisation in this algorithm. We then sketch h ..."
Abstract
 Add to MetaCart
We present a denotational semantics of a type system with dependent types, where types are interpreted as finitary projections. We prove then the correctness of a typechecking algorithm w.r.t. this semantics. In this way, we can justify some simple optimisation in this algorithm. We then sketch how to extend this semantics to allow a simple record mechanism with manifest fields.
CS 671, Automated Reasoning Lesson 20: Type Constructs based on Intersection (II):
, 2001
"... Last time we discussed record types and their representation through intersection types. We had defined {x1:T 1;..; xn:T n} ≡ {x1:T 1} ∩.. ∩ {xn:T n} where {x:T} ≡ z:Labels → if z=x then T else Top That is, records are represented as dependent functions with a type of labels as domain whose range ..."
Abstract
 Add to MetaCart
Last time we discussed record types and their representation through intersection types. We had defined {x1:T 1;..; xn:T n} ≡ {x1:T 1} ∩.. ∩ {xn:T n} where {x:T} ≡ z:Labels → if z=x then T else Top That is, records are represented as dependent functions with a type of labels as domain whose range types depend on the value of the chosen label. Finite record type declarations are underspecified type declarations for these functions, as they only specify the type of the function’s results for input labels that are explicitly mentioned. By intersecting these declarations we refine the function’s range for other input labels as well and thus specify it for a larger collection of labels. 3 We will now use the same methodology to define dependent records, i.e. types of the form {x1:T 1; x2:T2[x1];..; xn:Tn[x1;..xn−1]} In a dependent record r, the type of a component xi may depend on the values of the components x1..xi−1., that is r.x ∈T