Results 1  10
of
31
Tridirectional Typechecking
, 2004
"... In prior work we introduced a pure type assignment system that encompasses a rich set of property types, including intersections, unions, and universally and existentially quantified dependent types. In this paper ..."
Abstract

Cited by 40 (7 self)
 Add to MetaCart
In prior work we introduced a pure type assignment system that encompasses a rich set of property types, including intersections, unions, and universally and existentially quantified dependent types. In this paper
Strongly Typed FlowDirected Representation Transformations (Extended Abstract)
 In ICFP ’97 [ICFP97
, 1997
"... We present a new framework for transforming data representations in a strongly typed intermediate language. Our method allows both value producers (sources) and value consumers (sinks) to support multiple representations, automatically inserting any required code. Specialized representations can be ..."
Abstract

Cited by 30 (13 self)
 Add to MetaCart
We present a new framework for transforming data representations in a strongly typed intermediate language. Our method allows both value producers (sources) and value consumers (sinks) to support multiple representations, automatically inserting any required code. Specialized representations can be easily chosen for particular source/sink pairs. The framework is based on these techniques: 1. Flow annotated types encode the "flowsfrom" (source) and "flowsto" (sink) information of a flow graph. 2. Intersection and union types support (a) encoding precise flow information, (b) separating flow information so that transformations can be well typed, (c) automatically reorganizing flow paths to enable multiple representations. As an instance of our framework, we provide a function representation transformation that encompasses both closure conversion and inlining. Our framework is adaptable to data other than functions.
Modular setbased analysis from contracts
 In Morrisett and Peyton Jones [27
"... In PLT Scheme, programs consist of modules with contracts. The latter describe the inputs and outputs of functions and objects via predicates. A runtime system enforces these predicates; if a predicate fails, the enforcer raises an exception that blames a specific module with an explanation of the ..."
Abstract

Cited by 26 (4 self)
 Add to MetaCart
(Show Context)
In PLT Scheme, programs consist of modules with contracts. The latter describe the inputs and outputs of functions and objects via predicates. A runtime system enforces these predicates; if a predicate fails, the enforcer raises an exception that blames a specific module with an explanation of the fault. In this paper, we show how to use such module contracts to turn setbased analysis into a fully modular parameterized analysis. Using this analysis, a static debugger can indicate for any given contract check whether the corresponding predicate is always satisfied, partially satisfied, or (potentially) completely violated. The static debugger can also predict the source of potential errors, i.e., it is sound with respect to the blame assignment of the contract system.
Type Assignment for Intersections and Unions in CallbyValue Languages
"... We develop a system of type assignment with intersection types, union types, indexed types, and universal and existential dependent types that is sound in a callby value functional language. The combination of logical and computational principles underlying our formulation naturally leads to the c ..."
Abstract

Cited by 25 (10 self)
 Add to MetaCart
(Show Context)
We develop a system of type assignment with intersection types, union types, indexed types, and universal and existential dependent types that is sound in a callby value functional language. The combination of logical and computational principles underlying our formulation naturally leads to the central idea of typechecking subterms in evaluation order. We thereby provide a uniform generalization and explanation of several earlier isolated systems. The proof of progress and type preservation, usually formulated for closed terms only, relies on a notion of definite substitution.
Relating Typability and Expressiveness in FiniteRank Intersection Type Systems (Extended Abstract)
 In Proc. 1999 Int’l Conf. Functional Programming
, 1999
"... We investigate finiterank intersection type systems, analyzing the complexity of their type inference problems and their relation to the problem of recognizing semantically equivalent terms. Intersection types allow something of type T1 /\ T2 to be used in some places at type T1 and in other places ..."
Abstract

Cited by 22 (9 self)
 Add to MetaCart
(Show Context)
We investigate finiterank intersection type systems, analyzing the complexity of their type inference problems and their relation to the problem of recognizing semantically equivalent terms. Intersection types allow something of type T1 /\ T2 to be used in some places at type T1 and in other places at type T2 . A finiterank intersection type system bounds how deeply the /\ can appear in type expressions. Such type systems enjoy strong normalization, subject reduction, and computable type inference, and they support a pragmatics for implementing parametric polymorphism. As a consequence, they provide a conceptually simple and tractable alternative to the impredicative polymorphism of System F and its extensions, while typing many more programs than the HindleyMilner type system found in ML and Haskell. While type inference is computable at every rank, we show that its complexity grows exponentially as rank increases. Let K(0, n) = n and K(t + 1, n) = 2^K(t,n); we prove that recognizing the pure lambdaterms of size n that are typable at rank k is complete for dtime[K(k1, n)]. We then consider the problem of deciding whether two lambdaterms typable at rank k have the same normal form, Generalizing a wellknown result of Statman from simple types to finiterank intersection types. ...
A Typed Intermediate Language for FlowDirected Compilation
, 1997
"... We present a typed intermediate language # CIL for optimizing compilers for functionoriented and polymorphically typed programming languages (e.g., ML). The language # CIL is a typed lambda calculus with product, sum, intersection, and union types as well as function types annotated with flow label ..."
Abstract

Cited by 22 (13 self)
 Add to MetaCart
(Show Context)
We present a typed intermediate language # CIL for optimizing compilers for functionoriented and polymorphically typed programming languages (e.g., ML). The language # CIL is a typed lambda calculus with product, sum, intersection, and union types as well as function types annotated with flow labels. A novel formulation of intersection and union types supports encoding flow information in the typed program representation. This flow information can direct optimization.
Expansion: the Crucial Mechanism for Type Inference with Intersection Types: Survey and Explanation
 In: (ITRS ’04
, 2005
"... The operation of expansion on typings was introduced at the end of the 1970s by Coppo, Dezani, and Venneri for reasoning about the possible typings of a term when using intersection types. Until recently, it has remained somewhat mysterious and unfamiliar, even though it is essential for carrying ..."
Abstract

Cited by 18 (8 self)
 Add to MetaCart
(Show Context)
The operation of expansion on typings was introduced at the end of the 1970s by Coppo, Dezani, and Venneri for reasoning about the possible typings of a term when using intersection types. Until recently, it has remained somewhat mysterious and unfamiliar, even though it is essential for carrying out compositional type inference. The fundamental idea of expansion is to be able to calculate the effect on the final judgement of a typing derivation of inserting a use of the intersectionintroduction typing rule at some (possibly deeply nested) position, without actually needing to build the new derivation.
Branching Types
, 2002
"... Although systems with intersection types have many unique capabilities, there has never been a fully satisfactory explicitly typed system with intersection types. We introduce and prove the basic properties of # , a typed #calculus with branching types and types with quantification over type ..."
Abstract

Cited by 15 (5 self)
 Add to MetaCart
(Show Context)
Although systems with intersection types have many unique capabilities, there has never been a fully satisfactory explicitly typed system with intersection types. We introduce and prove the basic properties of # , a typed #calculus with branching types and types with quantification over type selection parameters. The new system # an explicitly typed system with the same expressiveness as a system with intersection types. Typing derivations in # use branching types to squash together what would be separate parallel derivations in earlier systems with intersection types.
Types, potency, and idempotency: why nonlinearity and amnesia make a type system work
 In ICFP ’04: Proceedings of the ninth ACM SIGPLAN international conference on Functional programming, 138–149, ACM
, 2004
"... Useful type inference must be faster than normalization. Otherwise, you could check safety conditions by running the program. We analyze the relationship between bounds on normalization and type inference. We show how the success of type inference is fundamentally related to the amnesia of the type ..."
Abstract

Cited by 10 (1 self)
 Add to MetaCart
(Show Context)
Useful type inference must be faster than normalization. Otherwise, you could check safety conditions by running the program. We analyze the relationship between bounds on normalization and type inference. We show how the success of type inference is fundamentally related to the amnesia of the type system: the nonlinearity by which all instances of a variable are constrained to have the same type. Recent work on intersection types has advocated their usefulness for static analysis and modular compilation. We analyze SystemI (and some instances of its descendant, System E), an intersection type system with a type inference algorithm. Because SystemI lacks idempotency, each occurrence of a variable requires a distinct type. Consequently, type inference is equivalent to normalization in every single case, and time bounds on type inference and normalization are identical. Similar relationships hold for other intersection type systems without idempotency. The analysis is founded on an investigation of the relationship between linear logic and intersection types. We show a lockstep correspondence between normalization and type inference. The latter shows the promise of intersection types to facilitate static analyses of varied granularity, but also belies an immense challenge: to add amnesia to such analysis without losing all of its benefits.
Program Representation Size in an Intermediate Language with Intersection and Union Types
 In Proceedings of the Third Workshop on Types in Compilation (TIC 2000
, 2000
"... The CIL compiler for core Standard ML compiles whole programs using a novel typed intermediate language (TIL) with intersection and union types and ow labels on both terms and types. The CIL term representation duplicates portions of the program where intersection types are introduced and union ..."
Abstract

Cited by 9 (7 self)
 Add to MetaCart
(Show Context)
The CIL compiler for core Standard ML compiles whole programs using a novel typed intermediate language (TIL) with intersection and union types and ow labels on both terms and types. The CIL term representation duplicates portions of the program where intersection types are introduced and union types are eliminated. This duplication makes it easier to represent type information and to introduce customized data representations. However, duplication incurs compiletime space costs that are potentially much greater than are incurred in TILs employing typelevel abstraction or quanti cation. In this paper, we present empirical data on the compiletime space costs of using CIL as an intermediate language. The data shows that these costs can be made tractable by using suciently negrained ow analyses together with standard hashconsing techniques. The data also suggests that nonduplicating formulations of intersection (and union) types would not achieve signi cantly better space complexity.