Program representation size in an intermediate language with intersection and union types

The CIL compiler for core Standard ML compiles whole programs using a novel typed intermediate language (TIL) with intersection and union types and flow 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 compile-time space costs that are potentially much greater than are incurred in TILs employing type-level abstraction or quantification. In this paper, we present empirical data on the compile-time space costs of using CIL as an intermediate language. The data shows that these costs can be made tractable by using sufficiently fine-grained flow analyses together with standard hash-consing techniques. The data also suggests that non-duplicating formulations of intersection (and union) types would not achieve significantly better space complexity.National Science Foundation (CCR-9417382, CISE/CCR ESS 9806747); Sun grant (EDUD-7826-990410-US); Faculty Fellowship of the Carroll School of Management, Boston College; U.K. Engineering and Physical Sciences Research Council (GR/L 36963, GR/L 15685

Lambda-Dropping: Transforming Recursive Equations into Programs with Block Structure

Lambda-lifting a functional program transforms it into a set of recursiveequations. We present the symmetric transformation: lambda-dropping.Lambda-dropping a set of recursive equations restores blockstructure and lexical scope.For lack of scope, recursive equations must carry around all theparameters that any of their callees might possibly need. Both lambda-liftingand lambda-dropping thus require one to compute a transitiveclosure over the call graph:- for lambda-lifting: to establish the Def/Use path of each freevariable (these free variables are then added as parameters toeach of the functions in the call path);- for lambda-dropping: to establish the Def/Use path of each parameter(parameters whose use occurs in the same scope as theirdefinition do not need to be passed along in the call path).Without free variables, a program is scope-insensitive. Its blocks arethen free to float (for lambda-lifting) or to sink (for lambda-dropping)along the vertices of the scope tree.We believe lambda-lifting and lambda-dropping are interesting perse, both in principle and in practice, but our prime application is partialevaluation: except for Malmkjær and Ørbæk's case study presented atPEPM'95, most polyvariant specializers for procedural programs operateon recursive equations. To this end, in a pre-processing phase,they lambda-lift source programs into recursive equations. As a result,residual programs are also expressed as recursive equations, often withdozens of parameters, which most compilers do not handle efficiently.Lambda-dropping in a post-processing phase restores their block structureand lexical scope thereby significantly reducing both the compiletime and the run time of residual programs.

A Type- and Control-Flow Analysis for System F: Technical Report

We present a monovariant flow analysis for System F (with recursion). The flow analysis yields both control-flow information, approximating the λ- and Λ-expressions that may be bound to variables, and type-flow information, approximating the type expressions that may instantiate type variables. Moreover, the two flows are mutually beneficial: the control flow determines which Λ-expressions may be applied to which type expressions (and, hence, which type expressions may instantiate which type variables), while the type flow filters the λ- and Λ-expressions that may be bound to variables (by rejecting expressions with static types that are incompatible with the static type of the variable under the type flow). As is typical for a monovariant control-flow analysis, control-flow information is expressed as an abstract environment mapping variables to sets of (syntactic) λ- and Λ-expressions that occur in the program under analysis. Similarly, type-flow information is expressed as an abstract environment mapping type variables to sets of (syntactic) types that occur in the program under analysis. Compatibility of static types (with free type variables) under a type flow is decided by interpreting the abstract environment as productions for a regular-tree grammar and querying if the languages generated by taking the types in question as starting terms have a non-empty intersection. This is a companion technical report, providing additional commentary and proof details, to a paper [11] appearing in Implementation and Application of Functional Languages: 24th International Symposium (IFL’12)

Simple Noninterference from Parametricity

In this paper we revisit the connection between parametricity and noninterference. Our primary contribution is a proof of noninterference for a polyvariant variation of the Dependency Core Calculus of in the Calculus of Constructions. The proof is modular: it leverages parametricity for the Calculus of Constructions and the encoding of data abstraction using existential types. This perspective gives rise to simple and understandable proofs of noninterference from parametricity. All our contributions have been mechanised in the Agda proof assistant