Results 1  10
of
63
The Essence of Principal Typings
 In Proc. 29th Int’l Coll. Automata, Languages, and Programming, volume 2380 of LNCS
, 2002
"... Let S be some type system. A typing in S for a typable term M is the collection of all of the information other than M which appears in the final judgement of a proof derivation showing that M is typable. For example, suppose there is a derivation in S ending with the judgement A M : # meanin ..."
Abstract

Cited by 94 (12 self)
 Add to MetaCart
(Show Context)
Let S be some type system. A typing in S for a typable term M is the collection of all of the information other than M which appears in the final judgement of a proof derivation showing that M is typable. For example, suppose there is a derivation in S ending with the judgement A M : # meaning that M has result type # when assuming the types of free variables are given by A. Then (A, #) is a typing for M .
Principality and Decidable Type Inference for FiniteRank Intersection Types
 In Conf. Rec. POPL ’99: 26th ACM Symp. Princ. of Prog. Langs
, 1999
"... Principality of typings is the property that for each typable term, there is a typing from which all other typings are obtained via some set of operations. Type inference is the problem of finding a typing for a given term, if possible. We define an intersection type system which has principal typin ..."
Abstract

Cited by 54 (17 self)
 Add to MetaCart
Principality of typings is the property that for each typable term, there is a typing from which all other typings are obtained via some set of operations. Type inference is the problem of finding a typing for a given term, if possible. We define an intersection type system which has principal typings and types exactly the strongly normalizable terms. More interestingly, every finiterank restriction of this system (using Leivant's first notion of rank) has principal typings and also has decidable type inference. This is in contrast to System F where the finite rank restriction for every finite rank at 3 and above has neither principal typings nor decidable type inference. This is also in contrast to earlier presentations of intersection types where the status (decidable or undecidable) of these properties is unknown for the finiterank restrictions at 3 and above. Furthermore, the notion of principal typings for our system involves only one operation, substitution, rather than severa...
Ur: StaticallyTyped Metaprogramming with TypeLevel Record Computation
, 2010
"... Dependent types provide a strong foundation for specifying and verifying rich properties of programs through typechecking. The earliest implementations combined dependency, which allows types to mention program variables; with typelevel computation, which facilitates expressive specifications that ..."
Abstract

Cited by 31 (3 self)
 Add to MetaCart
(Show Context)
Dependent types provide a strong foundation for specifying and verifying rich properties of programs through typechecking. The earliest implementations combined dependency, which allows types to mention program variables; with typelevel computation, which facilitates expressive specifications that compute with recursive functions over types. While many recent applications of dependent types omit the latter facility, we argue in this paper that it deserves more attention, even when implemented without dependency. In particular, the ability to use functional programs as specifications enables staticallytyped metaprogramming: programs write programs, and static typechecking guarantees that the generating process never produces invalid code. Since our focus is on generic validity properties rather than full correctness verification, it is possible to engineer type inference systems that are very effective in narrow domains. As a demonstration, we present Ur, a programming language designed to facilitate metaprogramming with firstclass records and names. On top of Ur, we implement Ur/Web, a special standard library that enables the development of modern Web applications. Adhoc code generation is already in wide use in the popular Web application frameworks, and we show how that generation may be tamed using types, without forcing metaprogram authors to write proofs or forcing metaprogram users to write any fancy types.
Principality and Type Inference for Intersection Types Using Expansion Variables
, 2003
"... Principality of typings is the property that for each typable term, there is a typing from which all other typings are obtained via some set of operations. Type inference is the problem of finding a typing for a given term, if possible. We define an intersection type system which has principal typ ..."
Abstract

Cited by 30 (12 self)
 Add to MetaCart
Principality of typings is the property that for each typable term, there is a typing from which all other typings are obtained via some set of operations. Type inference is the problem of finding a typing for a given term, if possible. We define an intersection type system which has principal typings and types exactly the strongly normalizable #terms. More interestingly, every finiterank restriction of this system (using Leivant's first notion of rank) has principal typings and also has decidable type inference.
The Implicit Calculus of Constructions  Extending Pure Type Systems with an Intersection Type Binder and Subtyping
 Proc. of 5th Int. Conf. on Typed Lambda Calculi and Applications, TLCA'01, Krakow
, 2001
"... In this paper, we introduce a new type system, the Implicit Calculus of Constructions, which is a Currystyle variant of the Calculus of Constructions that we extend by adding an intersection type binder called the implicit dependent product. Unlike the usual approach of Type Assignment Systems ..."
Abstract

Cited by 16 (0 self)
 Add to MetaCart
(Show Context)
In this paper, we introduce a new type system, the Implicit Calculus of Constructions, which is a Currystyle variant of the Calculus of Constructions that we extend by adding an intersection type binder called the implicit dependent product. Unlike the usual approach of Type Assignment Systems, the implicit product can be used at every place in the universe hierarchy. We study syntactical properties of this calculus such as the subject reduction property, and we show that the implicit product induces a rich subtyping relation over the type system in a natural way. We also illustrate the specicities of this calculus by revisitting the impredicative encodings of the Calculus of Constructions, and we show that their translation into the implicit calculus helps to reect the computational meaning of the underlying terms in a more accurate way.
Existential Label Flow Inference via CFL Reachability
 In SAS‘06
, 2005
"... Label flow analysis is a fundamental static analysis problem with a wide variety of applications. Previous work by Mossin developed a polynomial time subtypingbased label flow inference that supports HindleyMilner style polymorphism with polymorphic recursion. Rehof et al have developed an efficie ..."
Abstract

Cited by 15 (4 self)
 Add to MetaCart
(Show Context)
Label flow analysis is a fundamental static analysis problem with a wide variety of applications. Previous work by Mossin developed a polynomial time subtypingbased label flow inference that supports HindleyMilner style polymorphism with polymorphic recursion. Rehof et al have developed an efficient O(n 3) inference algorithm for Mossin’s system based on contextfree language (CFL) reachability. In this paper, we extend these results to a system that also supports existential polymorphism, which is important for precisely describing correlations among members of a structured type, even when values of that type are part of dynamic data structures. We first develop a provably sound checking system based on polymorphicallyconstrained types. As usual, we restrict universal quantification to the top level of a type, but existential quantification is first class, with subtyping allowed between existentials with the same binding structure. We then develop a CFLbased inference system. Programmers specify which positions in a type are existentially quantified, and the algorithm infers the constraints bound in the type, or rejects a program if the annotations are inconsistent. 1
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 14 (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.
Programming With Types
 CORNELL UNIVERSITY
, 2002
"... Runtime type analysis is an increasingly important linguistic mechanism in modern programming languages. Language runtime systems use it to implement services such as accurate garbage collection, serialization, cloning and structural equality. Component frameworks rely on it to provide reflection m ..."
Abstract

Cited by 11 (1 self)
 Add to MetaCart
Runtime type analysis is an increasingly important linguistic mechanism in modern programming languages. Language runtime systems use it to implement services such as accurate garbage collection, serialization, cloning and structural equality. Component frameworks rely on it to provide reflection mechanisms so they may discover and interact with program interfaces dynamically. Runtime type analysis is also crucial for large, distributed systems that must be dynamically extended, because it allows those systems to check program invariants when new code and new forms of data are added. Finally, many generic userlevel algorithms for iteration, pattern matching, and unification can be defined through type analysis mechanisms. However, existing frameworks for runtime type analysis were designed for simple type systems. They do not scale well to the sophisticated type systems of modern and nextgeneration programming languages that include complex constructs such as firstclass abstract types, recursive types, objects, and type parameterization. In addition, facilities to support type analysis often require complicated
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 9 (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.
Dependent types and program equivalence
 In Proceedings of the 37th ACM SIGACTSIGPLAN Symposium on Principles of Programming Languages (POPL). ACM
, 2009
"... The definition of type equivalence is one of the most important design issues for any typed language. In dependentlytyped languages, because terms appear in types, this definition must rely on a definition of term equivalence. In that case, decidability of type checking requires decidability for the ..."
Abstract

Cited by 8 (2 self)
 Add to MetaCart
(Show Context)
The definition of type equivalence is one of the most important design issues for any typed language. In dependentlytyped languages, because terms appear in types, this definition must rely on a definition of term equivalence. In that case, decidability of type checking requires decidability for the term equivalence relation. Almost all dependentlytyped languages require this relation to be decidable. Some, such as Coq, Epigram or Agda, do so by employing analyses to force all programs to terminate. Conversely, others, such as DML, ATS, Ωmega, or Haskell, allow nonterminating computation, but do not allow those terms to appear in types. Instead, they identify a terminating index language and use singleton types to connect indices to computation. In both cases, decidable type checking comes at a cost, in terms of complexity and expressiveness. Conversely, the benefits to be gained by decidable type checking are modest. Termination analyses allow dependently typed programs to verify total correctness properties. However, decidable type checking is not a prerequisite for type safety. Furthermore, decidability does not imply tractability. A decidable approximation of program equivalence may not be useful in practice. Therefore, we take a different approach: instead of a fixed notion for term equivalence, we parameterize our type system with an abstract relation that is not necessarily decidable. We then design a novel set of typing rules that require only weak properties of this abstract relation in the proof of the preservation and progress lemmas. This design provides flexibility: we compare valid instantiations of term equivalence which range from betaequivalence, to contextual equivalence, to some exotic equivalences.