Results 1  10
of
11
ConstraintBased Type Inference for Guarded Algebraic Data Types
, 2003
"... Guarded algebraic data types, which subsume the concepts known in the literature as indexed types, guarded recursive datatype constructors, and phantom types, and are closely related to inductive types, have the distinguishing feature that, when typechecking a function defined by cases, every branch ..."
Abstract

Cited by 25 (3 self)
 Add to MetaCart
Guarded algebraic data types, which subsume the concepts known in the literature as indexed types, guarded recursive datatype constructors, and phantom types, and are closely related to inductive types, have the distinguishing feature that, when typechecking a function defined by cases, every branch must be checked under di#erent typing assumptions. This mechanism allows exploiting the presence of dynamic tests in the code to produce extra static type information.
A constraintbased approach to guarded algebraic data types
 ACM Trans. Prog. Languages Systems
, 2007
"... We study HMG(X), an extension of the constraintbased type system HM(X) with deep pattern matching, polymorphic recursion, and guarded algebraic data types. Guarded algebraic data types subsume the concepts known in the literature as indexed types, guarded recursive datatype constructors, (firstcla ..."
Abstract

Cited by 24 (0 self)
 Add to MetaCart
We study HMG(X), an extension of the constraintbased type system HM(X) with deep pattern matching, polymorphic recursion, and guarded algebraic data types. Guarded algebraic data types subsume the concepts known in the literature as indexed types, guarded recursive datatype constructors, (firstclass) phantom types, and equality qualified types, and are closely related to inductive types. Their characteristic property is to allow every branch of a case construct to be typechecked under different assumptions about the type variables in scope. We prove that HMG(X) is sound and that, provided recursive definitions carry a type annotation, type inference can be reduced to constraint solving. Constraint solving is decidable, at least for some instances of X, but prohibitively expensive. Effective type inference for guarded algebraic data types is left as an issue for future research.
Decision procedures for algebraic data types with abstractions
 IN 37TH ACM SIGACTSIGPLAN SYMPOSIUM ON PRINCIPLES OF PROGRAMMING LANGUAGES (POPL), 2010. DECISION PROCEDURES FOR ORDERED COLLECTIONS 15 SHE75. SAHARON SHELAH. THE MONADIC THEORY OF ORDER. THA ANNALS OF MATHEMATICS OF MATHEMATICS
, 2010
"... We describe a family of decision procedures that extend the decision procedure for quantifierfree constraints on recursive algebraic data types (term algebras) to support recursive abstraction functions. Our abstraction functions are catamorphisms (term algebra homomorphisms) mapping algebraic data ..."
Abstract

Cited by 23 (11 self)
 Add to MetaCart
We describe a family of decision procedures that extend the decision procedure for quantifierfree constraints on recursive algebraic data types (term algebras) to support recursive abstraction functions. Our abstraction functions are catamorphisms (term algebra homomorphisms) mapping algebraic data type values into values in other decidable theories (e.g. sets, multisets, lists, integers, booleans). Each instance of our decision procedure family is sound; we identify a widely applicable manytoone condition on abstraction functions that implies the completeness. Complete instances of our decision procedure include the following correctness statements: 1) a functional data structure implementation satisfies a recursively specified invariant, 2) such data structure conforms to a contract given in terms of sets, multisets, lists, sizes, or heights, 3) a transformation of a formula (or lambda term) abstract syntax tree changes the set of free variables in the specified way.
Implementing Typeful Program Transformations
"... The notion of program transformation is ubiquitous in programming language studies on interpreters, compilers, partial evaluators, etc. In order to implement a program transformation, we need to choose a representation in the meta language, that is, the programming language in which we construct p ..."
Abstract

Cited by 11 (1 self)
 Add to MetaCart
The notion of program transformation is ubiquitous in programming language studies on interpreters, compilers, partial evaluators, etc. In order to implement a program transformation, we need to choose a representation in the meta language, that is, the programming language in which we construct programs, for representing object programs, that is, the programs in the object language on which the program transformation is to be performed. In practice, most representations chosen for typed...
A Formalization of Strong Normalization for SimplyTyped LambdaCalculus and System F
 LFMTP 2006
, 2006
"... We formalize in the logical framework ATS/LF a proof based on Tait’s method that establishes the simplytyped lambdacalculus being strongly normalizing. In this formalization, we employ higherorder abstract syntax to encode lambdaterms and an inductive datatype to encode the reducibility predicat ..."
Abstract

Cited by 7 (0 self)
 Add to MetaCart
We formalize in the logical framework ATS/LF a proof based on Tait’s method that establishes the simplytyped lambdacalculus being strongly normalizing. In this formalization, we employ higherorder abstract syntax to encode lambdaterms and an inductive datatype to encode the reducibility predicate in Tait’s method. The resulting proof is particularly simple and clean when compared to previously formalized ones. Also, we mention briefly how a proof based on Girard’s method can be formalized in a similar fashion that establishes System F being strongly normalizing.
ATS/LF: a type system for constructing proofs as total functional programs
, 2004
"... The development of Applied Type System (ATS) [36, 31] stems from an earlier attempt to introduce dependent types into practical programming [38, 37]. While there is already a framework Pure Type System [4] (PTS) that offers a simple and general approach to designing and formalizing type systems, ..."
Abstract

Cited by 2 (1 self)
 Add to MetaCart
The development of Applied Type System (ATS) [36, 31] stems from an earlier attempt to introduce dependent types into practical programming [38, 37]. While there is already a framework Pure Type System [4] (PTS) that offers a simple and general approach to designing and formalizing type systems,
Pattern Matching Coverage Checking with Dependent Types using Set Approximations
"... Definition of functions by pattern matching has proved to be a key feature of functional programming languages. These definitions allow a clear, easy to read, concise expression of functions. Proof assistants — like the the Coq proof assistant (Coq) — and some programming languages — like the Epigr ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
Definition of functions by pattern matching has proved to be a key feature of functional programming languages. These definitions allow a clear, easy to read, concise expression of functions. Proof assistants — like the the Coq proof assistant (Coq) — and some programming languages — like the Epigram (Epigram) or Agda (Agda) systems — introduce types that can depend on values. These dependent types allow to refine the definition of a type by the use of values. This results in a more precise specification of data types and functions. For example, it is possible, in such a system, to define the type of the lists of a given length n. The user can then express the fact that the head function — computing the first element of a list — can only be applied to non empty lists. This refinement reduces the number of run times error and allows to integrate program design and program verification. In presence of dependent types, some cases in a definition by pattern matching can become useless. For example, the case of the empty list is useless in the definition of the function head: the type of this function is specified to prevent the user to apply it to an empty list. For the sake of clarity and expressivity, we do not want the user to have to handle these useless cases. Especially, if the user is using dependent types for programming, handling such useless cases breaks, by introducing pieces of proof, the natural flow of the program. But forgetting a useful case can break the consistency of the system. This creates the need for a method to safely detect and remove useless cases in a definition by pattern matching. Alas, this problem — even restricted to algebraic data types — is undecidable in presence of dependent types. We introduce a new method to detect useless cases based on the computation of over–approximations of the inhabitants of inductive data types and contexts. Not only, this method is proved correct but can also produce — in a systematic way — a complete matching in Coq, ensuring that the logical power of the system remains unchanged. Moreover, it is modular over the kind of approximated sets used. We give two example implementations of such
Lambda Calculus and Related Systems
"... In this paper, we show how pattern matching can be seen to arise from a proof term assignment for the focused sequent calculus. This use of the CurryHoward correspondence allows us to give a novel coverage checking algorithm, and makes it possible to give a rigorous correctness proof for the classi ..."
Abstract
 Add to MetaCart
In this paper, we show how pattern matching can be seen to arise from a proof term assignment for the focused sequent calculus. This use of the CurryHoward correspondence allows us to give a novel coverage checking algorithm, and makes it possible to give a rigorous correctness proof for the classical pattern compilation strategy of building decision trees via matrices of patterns. Categories and Subject Descriptors F.4.1 [Mathematical Logic]: