Results 1 
6 of
6
Subtyping recursive types
 ACM TRANSACTIONS ON PROGRAMMING LANGUAGES AND SYSTEMS
, 1993
"... We investigate the interactions of subtyping and recursive types, in a simply typed λcalculus. The two fundamental questions here are whether two (recursive) types are in the subtype relation, and whether a term has a type. To address the first question, we relate various definitions of type equiva ..."
Abstract

Cited by 324 (8 self)
 Add to MetaCart
We investigate the interactions of subtyping and recursive types, in a simply typed λcalculus. The two fundamental questions here are whether two (recursive) types are in the subtype relation, and whether a term has a type. To address the first question, we relate various definitions of type equivalence and subtyping that are induced by a model, an ordering on infinite trees, an algorithm, and a set of type rules. We show soundness and completeness between the rules, the algorithm, and the tree semantics. We also prove soundness and a restricted form of completeness for the model. To address the second question, we show that to every pair of types in the subtype relation we can associate a term whose denotation is the uniquely determined coercion map between the two types. Moreover, we derive an algorithm that, when given a term with implicit coercions, can infer its least
A Foundation for Actor Computation
 Journal of Functional Programming
, 1998
"... We present an actor language which is an extension of a simple functional language, and provide a precise operational semantics for this extension. Actor configurations represent open distributed systems, by which we mean that the specification of an actor system explicitly takes into account the in ..."
Abstract

Cited by 249 (51 self)
 Add to MetaCart
(Show Context)
We present an actor language which is an extension of a simple functional language, and provide a precise operational semantics for this extension. Actor configurations represent open distributed systems, by which we mean that the specification of an actor system explicitly takes into account the interface with external components. We study the composability of such systems. We define and study various notions of testing equivalence on actor expressions and configurations. The model we develop provides fairness. An important result is that the three forms of equivalence, namely, convex, must, and may equivalences, collapse to two in the presence of fairness. We further develop methods for proving laws of equivalence and provide example proofs to illustrate our methodology.
Operational Semantics for MultiLanguage Programs
, 2007
"... Interlanguage interoperability is big business, as the success of Microsoft’s.NET and COM and Sun’s JVM show. Programming language designers are designing programming languages that reflect that fact — SML#, Mondrian, and Scala, to name just a few examples, all treat interoperability with other lan ..."
Abstract

Cited by 51 (8 self)
 Add to MetaCart
Interlanguage interoperability is big business, as the success of Microsoft’s.NET and COM and Sun’s JVM show. Programming language designers are designing programming languages that reflect that fact — SML#, Mondrian, and Scala, to name just a few examples, all treat interoperability with other languages as a central design feature. Still, current multilanguage research tends not to focus on the semantics of interoperation features, but only on how to implement them efficiently. In this paper, we take first steps toward higherlevel models of interoperating systems. Our technique abstracts away the lowlevel details of interoperability like garbage collection and representation coherence, and lets us focus on semantic properties like typesafety and observable equivalence. Beyond giving simple expressive models that are natural compositions of singlelanguage models, our studies have uncovered several interesting facts about interoperability. For example, higherorder contracts naturally emerge as the glue to ensure that interoperating languages respect each other’s type systems. While we present our results in an abstract setting, they shed light on real multilanguage systems and tools such as the JNI, SWIG, and Haskell’s stable pointers.
Type System of an ObjectOriented Database Programming Language (Extended Abstract)
 ACM COMPUTING SURVEYS (CSUR
, 1999
"... In this paper we present the type system of the TIGUKAT database programming language. It is a highly parametric objectoriented type system that combines multiple dispatch with reflexivity, separation of interface and implementation, precise behavior typing, and union and intersection types. We dem ..."
Abstract

Cited by 7 (0 self)
 Add to MetaCart
In this paper we present the type system of the TIGUKAT database programming language. It is a highly parametric objectoriented type system that combines multiple dispatch with reflexivity, separation of interface and implementation, precise behavior typing, and union and intersection types. We demonstrate the inner workings of the type system by considering a concrete example of type specification in TIGUKAT. We also review type systems of several existing programming languages and conclude that the proposed type system has a unique combination of features particularly suited for objectoriented database programming.
Rationalising Eiffel's Type System
 Proc. 18th Conf. Techn. ObjectOriented
, 1995
"... forbidding the redefinition of attribute types, inverting the routine argument redefinition rule to observe contravariance (redefined arguments should have more general types), judging type compatibility between parameterised types after replacing the type parameters and introducing an explicit type ..."
Abstract

Cited by 1 (1 self)
 Add to MetaCart
forbidding the redefinition of attribute types, inverting the routine argument redefinition rule to observe contravariance (redefined arguments should have more general types), judging type compatibility between parameterised types after replacing the type parameters and introducing an explicit type attribute scheme to handle Eiffel's anchored types. Contravariance is a counterintuitive finding for subtyping models of inheritance because it prevents the uniform specialisation of function arguments and results. It forbids the replacement of a function f:t®t closed over a type t by a function f:s®s closed over a subtype s Í t [Cardelli 86]. While insisting that Eiffel should obey the contravariant rule, Cook ruefully admits that: Eiffel has too many polymorphic type mechanisms: conformance, generic and anchored types, some of which are flawed and others redundant. Cook's suggested 1989 corrections to Eiffel's type rules, most notably to make inheritance obey subtyping, were not accepte...
AOn SubtypingRelation Completeness, with an Application to IsoRecursive Types
"... Wellknown techniques exist for proving the soundness of subtyping relations with respect to type safety. However, completeness has not been treated with widely applicable techniques, as far as we’re aware. This paper develops some techniques for stating and proving that a subtyping relation is comp ..."
Abstract
 Add to MetaCart
(Show Context)
Wellknown techniques exist for proving the soundness of subtyping relations with respect to type safety. However, completeness has not been treated with widely applicable techniques, as far as we’re aware. This paper develops some techniques for stating and proving that a subtyping relation is complete with respect to type safety and applies the techniques to the study of isorecursive subtyping. The common subtyping rules for isorecursive types—the “Amber rules”—are shown to be incomplete with respect to type safety. That is, there exist isorecursive types τ1 and τ2 such that τ1 can safely be considered a subtype of τ2, but τ1≤τ2 is not derivable with the Amber rules. This paper defines new, algorithmic rules for subtyping isorecursive types and proves that the rules are sound and complete with respect to type safety. The fully implemented subtyping algorithm is optimized to run in O(mn) time, where m is the number of µterms in the types being considered and n is the size of the types being considered.