Results 11  20
of
29
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 7 (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
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...
Type checking dependent (record) types and subtyping
 Journal of Functional and Logic Programming 10(2):137–166
"... ..."
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 2 (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 c ..."
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.
Roles, Stacks, Histories: A Triple for Hoare
, 2009
"... Behavioural type and effect systems regulate properties such as adherence to object and communication protocols, dynamic security policies, avoidance of race conditions, and many others. Typically, each system is based on some specific syntax of constraints, and is checked with an ad hoc solver. Ins ..."
Abstract
 Add to MetaCart
Behavioural type and effect systems regulate properties such as adherence to object and communication protocols, dynamic security policies, avoidance of race conditions, and many others. Typically, each system is based on some specific syntax of constraints, and is checked with an ad hoc solver. Instead, we advocate types refined with firstorder logic formulas as a basis for behavioural type systems, and general purpose automated theorem provers as an effective means of checking programs. To illustrate this approach, we define a triple of securityrelated type systems: for rolebased access control, for stack inspection, and for historybased access control. The three are all instances of a refined state monad. Our semantics allows a precise comparison of the similarities and differences of these mechanisms. In our examples, the benefit of behavioural typechecking is to rule out the possibility of unexpected security exceptions, a common problem with codebased access control.
unknown title
"... Traditional static type systems are very effective for verifying basic interface specifications, but are somewhat limited in the kinds specifications they support. Dynamicallychecked contracts can enforce more precise specifications, but these are not checked until run time, resulting in incomplete ..."
Abstract
 Add to MetaCart
Traditional static type systems are very effective for verifying basic interface specifications, but are somewhat limited in the kinds specifications they support. Dynamicallychecked contracts can enforce more precise specifications, but these are not checked until run time, resulting in incomplete detection of defects. Hybrid type checking is a synthesis of these two approaches that enforces precise interface specifications, via static analysis where possible, but also via dynamic checks where necessary. This paper explores the key ideas and implications of hybrid type checking, in the context of the simplytyped λcalculus with arbitrary refinements of base types.