Results 1 - 10
of
21
Intensional Polymorphism in Type-Erasure Semantics
, 2002
"... Intensional polymorphism, the ability to dispatch to di#erent routines based on types at run time, enables a variety of advanced implementation techniques for polymorphic languages, including tag-free garbage collection, unboxed function arguments, polymorphic marshalling, and flattened data structu ..."
Abstract
-
Cited by 132 (36 self)
- Add to MetaCart
Intensional polymorphism, the ability to dispatch to di#erent routines based on types at run time, enables a variety of advanced implementation techniques for polymorphic languages, including tag-free garbage collection, unboxed function arguments, polymorphic marshalling, and flattened data structures. To date, languages that support intensional polymorphism have required a type-passing (as opposed to type-erasure) interpretation where types are constructed and passed to polymorphic functions at run time. Unfortunately, type-passing su#ers from a number of drawbacks: it requires duplication of run-time constructs at the term and type levels, it prevents abstraction, and it severely complicates polymorphic closure conversion.
Guarded Recursive Datatype Constructors
, 2003
"... introduc e a notion of guarded rec ursive (g.r.) datatype c#w struc tors, generalizing the notion ofrec# rsive datatypes in func tional programming languages suc h as ML and Haskell. We address both theoret ic#t and prac# ic## issues resulted from this generalization. On one hand, we design a type s ..."
Abstract
-
Cited by 115 (10 self)
- Add to MetaCart
introduc e a notion of guarded rec ursive (g.r.) datatype c#w struc tors, generalizing the notion ofrec# rsive datatypes in func tional programming languages suc h as ML and Haskell. We address both theoret ic#t and prac# ic## issues resulted from this generalization. On one hand, we design a type system to formalize the notion of g.r. datatypec onstruc - tors and then prove the soundness of the type system. On the other hand, we present some signific ant applic ations (e.g., implementing objec ts, implementing stagedc omputation, etc# ) of g.r. datatype c# nstruc#S rs, arguing that g.r. datatypec onstruc torsc an have far-reac hingc onsequenc es in programming. The mainc ontribution of the paper lies in the rec#I0 ition and then the formalization of a programming notion that is of both theoretic# l interest and prac tic# l use.
A syntactic approach to foundational proof-carrying code
- In Seventeenth IEEE Symposium on Logic in Computer Science
, 2002
"... Proof-Carrying Code (PCC) is a general framework for verifying the safety properties of machine-language programs. PCC proofs are usually written in a logic extended with language-specific typing rules. In Foundational Proof-Carrying Code (FPCC), on the other hand, proofs are constructed and verifie ..."
Abstract
-
Cited by 84 (18 self)
- Add to MetaCart
Proof-Carrying Code (PCC) is a general framework for verifying the safety properties of machine-language programs. PCC proofs are usually written in a logic extended with language-specific typing rules. In Foundational Proof-Carrying Code (FPCC), on the other hand, proofs are constructed and verified using strictly the foundations of mathematical logic, with no type-specific axioms. FPCC is more flexible and secure because it is not tied to any particular type system and it has a smaller trusted base. Foundational proofs, however, are much harder to construct. Previous efforts on FPCC all required building sophisticated semantic models for types. In this paper, we present a syntactic approach to FPCC that avoids the difficulties of previous work. Under our new scheme, the foundational proof for a typed machine program simply consists of the typing derivation plus the formalized syntactic soundness proof for the underlying type system. We give a translation from a typed assembly language into FPCC and demonstrate the advantages of our new system via an implementation in the Coq proof assistant. 1.
A type system for certified binaries
- In ACM Symposium on Principles of Programming Languages
, 2002
"... A certified binary is a value together with a proof that the value satisfies a given specification. Existing compilers that generate certified code have focused on simple memory and control-flow safety rather than more advanced properties. In this paper, we present a general framework for explicitly ..."
Abstract
-
Cited by 80 (12 self)
- Add to MetaCart
A certified binary is a value together with a proof that the value satisfies a given specification. Existing compilers that generate certified code have focused on simple memory and control-flow safety rather than more advanced properties. In this paper, we present a general framework for explicitly representing complex propositions and proofs in typed intermediate and assembly languages. The new framework allows us to reason about certified programs that involve effects while still maintaining decidable typechecking. We show how to integrate an entire proof system (the calculus of inductive constructions) into a compiler intermediate language and how the intermediate language can undergo complex transformations (CPS and closure conversion) while preserving proofs represented in the type system. Our work provides a foundation for the process of automatically generating certified binaries in a type-theoretic framework. 1
System F with type equality coercions
, 2007
"... We introduce System FC, which extends System F with support for non-syntactic type equality. There are two main extensions: (i) explicit witnesses for type equalities, and (ii) open, non-parametric type functions, given meaning by toplevel equality axioms. Unlike System F, FC is expressive enough to ..."
Abstract
-
Cited by 57 (21 self)
- Add to MetaCart
We introduce System FC, which extends System F with support for non-syntactic type equality. There are two main extensions: (i) explicit witnesses for type equalities, and (ii) open, non-parametric type functions, given meaning by toplevel equality axioms. Unlike System F, FC is expressive enough to serve as a target for several different source-language features, including Haskell’s newtype, generalised algebraic data types, associated types, functional dependencies, and perhaps more besides.
Type-Indexed Data Types
- SCIENCE OF COMPUTER PROGRAMMING
, 2004
"... A polytypic function is a function that can be instantiated on many data types to obtain data type specific functionality. Examples of polytypic functions are the functions that can be derived in Haskell, such as show , read , and ` '. More advanced examples are functions for digital searching, patt ..."
Abstract
-
Cited by 53 (19 self)
- Add to MetaCart
A polytypic function is a function that can be instantiated on many data types to obtain data type specific functionality. Examples of polytypic functions are the functions that can be derived in Haskell, such as show , read , and ` '. More advanced examples are functions for digital searching, pattern matching, unification, rewriting, and structure editing. For each of these problems, we not only have to define polytypic functionality, but also a type-indexed data type: a data type that is constructed in a generic way from an argument data type. For example, in the case of digital searching we have to define a search tree type by induction on the structure of the type of search keys. This paper shows how to define type-indexed data types, discusses several examples of type-indexed data types, and shows how to specialize type-indexed data types. The approach has been implemented in Generic Haskell, a generic programming extension of the functional language Haskell.
Tagless Staged Interpreters for Typed Languages
- In the International Conference on Functional Programming (ICFP ’02
, 2002
"... Multi-stage programming languages provide a convenient notation for explicitly staging programs. Staging a definitional interpreter for a domain specific language is one way of deriving an implementation that is both readable and efficient. In an untyped setting, staging an interpreter "removes a co ..."
Abstract
-
Cited by 43 (11 self)
- Add to MetaCart
Multi-stage programming languages provide a convenient notation for explicitly staging programs. Staging a definitional interpreter for a domain specific language is one way of deriving an implementation that is both readable and efficient. In an untyped setting, staging an interpreter "removes a complete layer of interpretive overhead", just like partial evaluation. In a typed setting however, Hindley-Milner type systems do not allow us to exploit typing information in the language being interpreted. In practice, this can have a slowdown cost factor of three or more times.
Dynamic Opacity for Abstract Types
"... Existential types are the standard formalisation of abstract types. While this formulation is sufficient in entirely statically typed languages, it proves to be too weak for languages enriched with forms of dynamic typing: in the presence of operations performing type analysis, the abstraction barri ..."
Abstract
-
Cited by 35 (8 self)
- Add to MetaCart
Existential types are the standard formalisation of abstract types. While this formulation is sufficient in entirely statically typed languages, it proves to be too weak for languages enriched with forms of dynamic typing: in the presence of operations performing type analysis, the abstraction barrier erected by the static typing rules for existential types is no longer impassable, because parametricity is violated. We present a light-weight calculus for polymorphic languages with abstract types that addresses this shortcoming. It features a variation of existential types that retains most of the simplicity of standard existentials. It relies on modified scoping rules and explicit coercions between the quantified variable and its witness type.
An open and shut typecase
, 2004
"... Two different ways of defining ad-hoc polymorphic operations commonly occur in programming languages. With the first form polymorphic operations are defined inductively on the structure of types while with the second form polymorphic operations are defined for specific sets of types. In intensional ..."
Abstract
-
Cited by 16 (9 self)
- Add to MetaCart
Two different ways of defining ad-hoc polymorphic operations commonly occur in programming languages. With the first form polymorphic operations are defined inductively on the structure of types while with the second form polymorphic operations are defined for specific sets of types. In intensional type analysis operations are defined by induction on the structure of types. Therefore no new cases are necessary for user-defined types, because these types are equivalent to their underlying structure. However, intensional type analysis is “closed ” to extension, as the behavior of the operations cannot be differentiated for the new types, thus destroying the distinctions that these types are designed to express. Haskell type classes on the other hand define polymorphic operations for sets of types. Operations defined by class instances are considered “open”—the programmer can add instances for new types without modifying existing code. However, the operations must be extended with specialized code for each new type, and it may be tedious or even impossible to add extensions that apply to a large universe of new types. Both approaches have their benefits, so it is important to let programmers decide which is most appropriate for their needs. In this paper, we define a language that supports both forms of ad-hoc polymorphism, using the same basic constructs.
Parametric Higher-Order Abstract Syntax for Mechanized Semantics
"... We present parametric higher-order abstract syntax (PHOAS), a new approach to formalizing the syntax of programming languages in computer proof assistants based on type theory. Like higherorder abstract syntax (HOAS), PHOAS uses the meta language’s binding constructs to represent the object language ..."
Abstract
-
Cited by 13 (1 self)
- Add to MetaCart
We present parametric higher-order abstract syntax (PHOAS), a new approach to formalizing the syntax of programming languages in computer proof assistants based on type theory. Like higherorder abstract syntax (HOAS), PHOAS uses the meta language’s binding constructs to represent the object language’s binding constructs. Unlike HOAS, PHOAS types are definable in generalpurpose type theories that support traditional functional programming, like Coq’s Calculus of Inductive Constructions. We walk through how Coq can be used to develop certified, executable program transformations over several statically-typed functional programming languages formalized with PHOAS; that is, each transformation has a machine-checked proof of type preservation and semantic preservation. Our examples include CPS translation and closure conversion for simply-typed lambda calculus, CPS translation for System F, and translation from a language with ML-style pattern matching to a simpler language with no variable-arity binding constructs. By avoiding the syntactic hassle associated with first-order representation techniques, we achieve a very high degree of proof automation. Categories and Subject Descriptors F.3.1 [Logics and meanings

