Results 11  20
of
24
Some Algorithmic and ProofTheoretical Aspects of Coercive Subtyping
 In Proceedings of TYPES'96, Lecture Notes in Computer Science
, 1996
"... . Coercive subtyping offers a conceptually simple but powerful framework to understand subtyping and subset relationships in type theory. In this paper we study some of its prooftheoretic and computational properties. 1 Introduction Coercive subtyping, as first introduced in [Luo96], offers a conc ..."
Abstract

Cited by 6 (0 self)
 Add to MetaCart
. Coercive subtyping offers a conceptually simple but powerful framework to understand subtyping and subset relationships in type theory. In this paper we study some of its prooftheoretic and computational properties. 1 Introduction Coercive subtyping, as first introduced in [Luo96], offers a conceptually simple but powerful framework to understand subtyping and subset relationships in type theories with sophisticated type structures such as dependent types, inductive types, and type universes. A basic idea behind coercive subtyping is that subtyping provides a powerful mechanism for notational abbreviation in type theory. If A is a subtype of B given by a specified coercion function, an object of type A can be regarded as an object of type B, that is, its image via the coercion function, and hence objects of a subtype can be used as abbreviations for objects of a supertype. With coercive subtyping, this abbreviational mechanism is formally treated at the level of the logical framewo...
H.: Typing in Model Management
 ICMT 2009. LNCS
, 2009
"... Abstract. Model management is essential for coping with the complexity introduced by the increasing number and varied nature of artifacts involved in MDEbased projects. Global Model Management (GMM) addresses this issue enabling the representation of artifacts, particularly transformation compositi ..."
Abstract

Cited by 6 (3 self)
 Add to MetaCart
Abstract. Model management is essential for coping with the complexity introduced by the increasing number and varied nature of artifacts involved in MDEbased projects. Global Model Management (GMM) addresses this issue enabling the representation of artifacts, particularly transformation composition and execution, by a model called a megamodel. Typing information about artifacts can be used for preventing type errors during execution. In this work, we present a type system for GMM that improves its current typing approach and enables formal reasoning about the type of artifacts within a megamodel. This type system is able to capture nontrivial situations such as the use of higher order transformations. 1
Type Checking Dependent (Record) Types and Subtyping
 Journal of Functional Programming
, 2000
"... . In this work we put forward an algorithm for the mechanical verification of an extension of MartinLof's theory of types with dependent record types and subtyping. We first give a concise description of that theory and motivate its use for the formalization of algebraic constructions. Then we c ..."
Abstract

Cited by 3 (1 self)
 Add to MetaCart
. In this work we put forward an algorithm for the mechanical verification of an extension of MartinLof's theory of types with dependent record types and subtyping. We first give a concise description of that theory and motivate its use for the formalization of algebraic constructions. Then we concentrate in the informal explanation and specification of a proof checker that we implemented on machine. The logical heart of this proof checker is a type checking algorithm for the forms of judgement of a particular formulation of the extended theory which incorporates a notion of parameter. The algorithm has been proven sound with respect to the latter calculus. We include a discussion on that proof in the present work. 1. Introduction The subject of this paper is the specification and implementation of a proof checker for an extension of MartinLof's theory of logical types [Mar87] with dependent record types and subtyping. The original formulation of MartinLof's theory of types...
Coercive Subtyping for the Calculus of Constructions (extended abstract)
"... We present a coercive subtyping system for the calculus of constructions. The proposed system λC co ≤ is obtained essentially by adding coercions and ηconversion to λC≤[10], which is a subtyping extension to the calculus of constructions without coercions. Following [17, 18], the coercive subtyping ..."
Abstract

Cited by 3 (1 self)
 Add to MetaCart
We present a coercive subtyping system for the calculus of constructions. The proposed system λC co ≤ is obtained essentially by adding coercions and ηconversion to λC≤[10], which is a subtyping extension to the calculus of constructions without coercions. Following [17, 18], the coercive subtyping c: A ≤ B is understood as a special case of typing in arrow type c: A → B such that the term c behaves like an identity function. We prove that, with respect to this semantic interpretation, the proposed coercive subtyping system is sound and complete, and that this completeness leads to transitivity elimination (transitivity rule is admissible). In and CCβη, this fact implies that λC co ≤ has confluence, subject reduction and strong normalization. We propose a formalization of coercion inference problem and present a sound and complete coercion inference algorithm. addition, we establish the equivalence between λC co
How to Reconcile Subtypes, Dependent Types and Deep Polymorphism in one Language
, 1991
"... this report may apply, should support following activities: 1. formulation of a requirement (e.g., total correctness statement, or algebraic specification, or process logic formula), 2. description of a construction (e.g. resp., imperative program, or algebra, or process), 3. verification that a giv ..."
Abstract

Cited by 2 (2 self)
 Add to MetaCart
this report may apply, should support following activities: 1. formulation of a requirement (e.g., total correctness statement, or algebraic specification, or process logic formula), 2. description of a construction (e.g. resp., imperative program, or algebra, or process), 3. verification that a given construction satisfies a given requirement. The verification step 3 above cannot, for any realistic classes of requirements and constructions, be fully automated. Therefore, it generates a proof obligation that may be either proven by hand, or passed over to a heuristic theorem prover, or left unproven but recorded in the construction's documentation for future reference, in case something goes wrong. But then, it is acceptable that the steps 1 and 2 generate proof obligations as well. For instance, an attempt to automatically type check a construction might break down at some point, in which case the type checker would generate a proof obligation for that point and then proceed as if everything worked well. It is important that the number and the complexity of generated proof obligations be kept within reasonable limits. In particular, no proof obligations should be generated where no dependent types and no subtypes are involved. This report presents a simple but powerful language SDDP
Subtyping Parametric and Dependent Types
, 1996
"... A type may be a subtype of another type. The intuition about this should be clear: a type is a type of data, some data then may live in a given type as well as in a larger one, up to a simple "transformation". The advantage is that those data may be "seen" or used in different contexts. The formal ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
A type may be a subtype of another type. The intuition about this should be clear: a type is a type of data, some data then may live in a given type as well as in a larger one, up to a simple "transformation". The advantage is that those data may be "seen" or used in different contexts. The formal treatment of this intuition, though, is not so obvious, in particular when data may be programs. In Object Oriented Programming, where the issue of "reusing data" is crucial, there has been a longlasting discussion on "inheritance" and ... little agreement. There are several ways to understand and formalize inheritance, which depend on the specific programming environment used. Since early work of Cardelli and Wegner, there has been a large amount of papers developing several possible functional approaches to inheritance, as subtyping. Indeed, functional subtyping captures only one point of view on inheritance, yet this notion largely motivated most of that work. Whethe
Aiding Dependent Type Checking with Rewrite Rules
, 2001
"... Dependent type checking in Cayenne often fails when the programmer has relied on nontrivial properties of functions that are used in types. For instance, associativity of addition on natural numbers does not follow immediately from the function definition, but it may be required during the type che ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
Dependent type checking in Cayenne often fails when the programmer has relied on nontrivial properties of functions that are used in types. For instance, associativity of addition on natural numbers does not follow immediately from the function definition, but it may be required during the type checking process. We propose to tackle this problem by allowing the programmer to annotate programs with rewrite rules whenever such additional properties are required. We discuss two motivating examples and report on a feasibility study where we integrated a rewriting system into a type checking algorithm for a language with dependent types and general recursion.
Verifying (parametric) Algebras Against Specifications
, 1993
"... this paper. For the approaches 2 or 3 to be followed the syntax of axioms should first be fully elaborated which is beyond the scope of the paper. 3 Further properties ..."
Abstract
 Add to MetaCart
this paper. For the approaches 2 or 3 to be followed the syntax of axioms should first be fully elaborated which is beyond the scope of the paper. 3 Further properties
HindleyMilner for dependent and subset types
, 1995
"... syntax x , y : Var ::= : : : ff : TpVar ::= : : : c : Const ::= : : : tc : TpConst ::= : : : tp : Type ::= TpVar fi fi fi TpConst fi fi fi ((Var:Type FormSeq) ?Type) t : Term ::= Var fi fi fi Const fi fi fi (Var.Term) fi fi fi (Var:Type FormSeq.Term) fi fi fi (Term Term) f : Form :: ..."
Abstract
 Add to MetaCart
syntax x , y : Var ::= : : : ff : TpVar ::= : : : c : Const ::= : : : tc : TpConst ::= : : : tp : Type ::= TpVar fi fi fi TpConst fi fi fi ((Var:Type FormSeq) ?Type) t : Term ::= Var fi fi fi Const fi fi fi (Var.Term) fi fi fi (Var:Type FormSeq.Term) fi fi fi (Term Term) f : Form ::= (Term = Term) fi fi fi (8Var:Type FormSeq =? FormSeq) F : FormSeq ::= " fi fi fi FormSeq , Form \Gamma : Context ::= FormSeq fi fi fi Context ; (Var:Type) ; FormSeq sh : Shape ::= TpVar fi fi fi TpConst fi fi fi (Type ? Type) Parentheses may be skipped subject to usual conventions. Wherever the grammar presented requires a FormSeq or a Context and it happens to be empty ("), spurious separators (comma, semicolon, vertical bar) are skipped; e.g, (f : (k:nat)?real)? real and (k:nat);(x:real) denote respectively ((f : ((k:nat")?real)") ? real) and ;(k:nat);;(x:real); The notions of free and bound variable occurrences are the standard ones assuming the binding constructs...