Results 1  10
of
22
Intensional Polymorphism in TypeErasure 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 tagfree garbage collection, unboxed function arguments, polymorphic marshalling, and flattened data structu ..."
Abstract

Cited by 142 (38 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 tagfree garbage collection, unboxed function arguments, polymorphic marshalling, and flattened data structures. To date, languages that support intensional polymorphism have required a typepassing (as opposed to typeerasure) interpretation where types are constructed and passed to polymorphic functions at run time. Unfortunately, typepassing su#ers from a number of drawbacks: it requires duplication of runtime 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 129 (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 farreac 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 proofcarrying code
 In Seventeenth IEEE Symposium on Logic in Computer Science
, 2002
"... ProofCarrying Code (PCC) is a general framework for verifying the safety properties of machinelanguage programs. PCC proofs are usually written in a logic extended with languagespecific typing rules. In Foundational ProofCarrying Code (FPCC), on the other hand, proofs are constructed and verifie ..."
Abstract

Cited by 94 (19 self)
 Add to MetaCart
ProofCarrying Code (PCC) is a general framework for verifying the safety properties of machinelanguage programs. PCC proofs are usually written in a logic extended with languagespecific typing rules. In Foundational ProofCarrying Code (FPCC), on the other hand, proofs are constructed and verified using strictly the foundations of mathematical logic, with no typespecific 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 controlflow safety rather than more advanced properties. In this paper, we present a general framework for explicitly ..."
Abstract

Cited by 84 (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 controlflow 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 typetheoretic framework. 1
System F with type equality coercions
, 2007
"... We introduce System FC, which extends System F with support for nonsyntactic type equality. There are two main extensions: (i) explicit witnesses for type equalities, and (ii) open, nonparametric type functions, given meaning by toplevel equality axioms. Unlike System F, FC is expressive enough to ..."
Abstract

Cited by 75 (25 self)
 Add to MetaCart
We introduce System FC, which extends System F with support for nonsyntactic type equality. There are two main extensions: (i) explicit witnesses for type equalities, and (ii) open, nonparametric type functions, given meaning by toplevel equality axioms. Unlike System F, FC is expressive enough to serve as a target for several different sourcelanguage features, including Haskell’s newtype, generalised algebraic data types, associated types, functional dependencies, and perhaps more besides.
TypeIndexed 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 59 (21 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 typeindexed 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 typeindexed data types, discusses several examples of typeindexed data types, and shows how to specialize typeindexed 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
"... Multistage 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 53 (11 self)
 Add to MetaCart
Multistage 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, HindleyMilner 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 44 (11 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 lightweight 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.
Parametric HigherOrder Abstract Syntax for Mechanized Semantics
"... We present parametric higherorder 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 20 (2 self)
 Add to MetaCart
We present parametric higherorder 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 staticallytyped functional programming languages formalized with PHOAS; that is, each transformation has a machinechecked proof of type preservation and semantic preservation. Our examples include CPS translation and closure conversion for simplytyped lambda calculus, CPS translation for System F, and translation from a language with MLstyle pattern matching to a simpler language with no variablearity binding constructs. By avoiding the syntactic hassle associated with firstorder representation techniques, we achieve a very high degree of proof automation. Categories and Subject Descriptors F.3.1 [Logics and meanings
An open and shut typecase
, 2004
"... Two different ways of defining adhoc 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 18 (8 self)
 Add to MetaCart
Two different ways of defining adhoc 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 userdefined 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 adhoc polymorphism, using the same basic constructs.