Results 1 - 10
of
12
A calculus for link-time compilation
, 2000
"... Abstract. We present a module calculus for studying a simple model of link-time compilation. The calculus is stratified into a term calculus, a core module calculus, and a linking calculus. At each level, we show that the calculus enjoys a computational soundness property: iftwo terms are equivalent ..."
Abstract
-
Cited by 21 (4 self)
- Add to MetaCart
Abstract. We present a module calculus for studying a simple model of link-time compilation. The calculus is stratified into a term calculus, a core module calculus, and a linking calculus. At each level, we show that the calculus enjoys a computational soundness property: iftwo terms are equivalent in the calculus, then they have the same outcome in a smallstep operational semantics. This implies that any module transformation justified by the calculus is meaning preserving. This result is interesting because recursive module bindings thwart confluence at two levels ofour calculus, and prohibit application ofthe traditional technique for showing computational soundness, which requires confluence. We introduce a new technique, based on properties we call lift and project, thatusesa weaker notion of confluence with respect to evaluation to establish computational soundness for our module calculus. We also introduce the weak distributivity property for a transformation T operating on modules D1 and D2 linked by ⊕: T (D1 ⊕ D2) =T (T (D1) ⊕ T (D2)). We argue that this property finds promising candidates for link-time optimizations. 1
An abstract model of Java dynamic linking and loading
- Proceedings of the Third International Workshop on Types in Compilation (TIC 2000), volume 2071 of LNCS
, 2001
"... We suggest a model for dynamic loading and linking as in Java. We distinguish five components in a Java implementation: evaluation, resolution, loading, verification, and preparation -- with their associated checks. We demonstrate how these five together guarantee type soundness. ..."
Abstract
-
Cited by 19 (5 self)
- Add to MetaCart
We suggest a model for dynamic loading and linking as in Java. We distinguish five components in a Java implementation: evaluation, resolution, loading, verification, and preparation -- with their associated checks. We demonstrate how these five together guarantee type soundness.
A Typed Context Calculus
, 2001
"... This paper develops a typed calculus for contexts i.e., lambda terms with "holes". In addition to ordinary lambda terms, the calculus contains labeled holes, hole abstraction and context application for manipulating first-class contexts. The primary operation for contexts is hole-filling, which capt ..."
Abstract
-
Cited by 9 (0 self)
- Add to MetaCart
This paper develops a typed calculus for contexts i.e., lambda terms with "holes". In addition to ordinary lambda terms, the calculus contains labeled holes, hole abstraction and context application for manipulating first-class contexts. The primary operation for contexts is hole-filling, which captures free variables. This operation conicts with substitution of the lambda calculus, and a straightforward mixture of the two results in an inconsistent system. We solve this problem by defining a type system that precisely specifies the variable-capturing nature of contexts and that keeps track of bound variable renaming. These mechanisms enable us to define a reduction system that properly integrates beta-reduction and hole-filling. The resulting calculus is Church-Rosser and the type system has the subject reduction property. We believe that the context calculus will serve as a basis for developing a programming language with advanced features that call for manipulation of open terms.
Managing the Evolution of .NET Programs
"... The component-based model of code execution imposes some requirements on the software components themselves, and at the same time lays some constraints on the modern run-time environment. Software components need to store descriptive metadata, and the run-time system must access this `reflectivel ..."
Abstract
-
Cited by 9 (1 self)
- Add to MetaCart
The component-based model of code execution imposes some requirements on the software components themselves, and at the same time lays some constraints on the modern run-time environment. Software components need to store descriptive metadata, and the run-time system must access this `reflectively' in order to implement dynamic linking. Software components also undergo dynamic evolution whereby a client component experiences the effects of modifications, made to a service component even though these occurred after the client was built.
Java Exceptions Throw no Surprises
, 2000
"... We outline a proof of type soundness for Java exceptions and exception handling. We distinguish between normal execution, where no exception is thrown -- or, more precisely, any exception thrown is handled -- and abnormal execution, where an exception is thrown and not handled. The type system disti ..."
Abstract
-
Cited by 8 (0 self)
- Add to MetaCart
We outline a proof of type soundness for Java exceptions and exception handling. We distinguish between normal execution, where no exception is thrown -- or, more precisely, any exception thrown is handled -- and abnormal execution, where an exception is thrown and not handled. The type system distinguishes normal types which describe the possible outcomes of normal execution, and abnormal types which describe the possible outcomes of abnormal execution. The type of a term consists of its normal type and its abnormal type. With this set-up we prove subject reduction. The meaning of our subject reduction theorem is stronger than usual: it guarantees that normal execution returns a value of a type compatible with the normal type of the term, and that abnormal execution throws an exception compatible with the abnormal type of the term. 1 Introduction Exceptions and exception handling aim to support the development of robust programs with reliable error detection, and fast error handling ...
Type inference, principal typings, and letpolymorphism for first-class mixin modules
- Heriot-Watt Univ., School of Math. & Comput. Sci
, 2005
"... A mixin module is a programming abstraction that simultaneously generalizes λ-abstractions, records, and mutually recursive definitions. Although various mixin module type systems have been developed, no one has investigated principal typings or developed type inference for first-class mixin modules ..."
Abstract
-
Cited by 7 (0 self)
- Add to MetaCart
A mixin module is a programming abstraction that simultaneously generalizes λ-abstractions, records, and mutually recursive definitions. Although various mixin module type systems have been developed, no one has investigated principal typings or developed type inference for first-class mixin modules, nor has anyone added Milner’s let-polymorphism to such a system. This paper proves that typability is NP-complete for the naive approach followed by previous mixin module type systems. Because a λ-calculus extended with record concatenation is a simple restriction of our mixin module calculus, we also prove the folk belief that typability is NP-complete for the naive early type systems for record concatenation. To allow feasible type inference, we present Martini, a new system of simple types for mixin modules with principal typings. Martini is conceptually simple, with no subtyping and a clean and balanced separation between unification-based type inference with type and row variables and constraint solving for safety of linking and field extraction. We have implemented a type inference algorithm and we prove its complexity to be O(n 2), or O(n) given a fixed bound on the number of field labels. 1 To prove the complexity, we need to present an algorithm for row unification that may have been implemented by others, but which we could not find written down anywhere. Because Martini has principal typings, we successfully extend it with Milner’s let-polymorphism. Categories and Subject Descriptors D.3.3 [Programming Languages]: Language Constructs and Features—Data types and structures; modules, packages; polymorphism
Mixin Modules for Dynamic Rebinding
- IN: TGC 2005 -SYMPOSIUM ON TRUSTWORTHY GLOBAL COMPUTING, LECTURE NOTES IN COMPUTER SCIENCE
, 2005
"... Dynamic rebinding is the ability of changing the definitions of names at execution time. While dynamic rebinding is clearly useful in practice, and increasingly needed in modern systems, most programming languages provide only limited and ad-hoc mechanisms, and no adequate semantic understanding cur ..."
Abstract
-
Cited by 6 (4 self)
- Add to MetaCart
Dynamic rebinding is the ability of changing the definitions of names at execution time. While dynamic rebinding is clearly useful in practice, and increasingly needed in modern systems, most programming languages provide only limited and ad-hoc mechanisms, and no adequate semantic understanding currently exists. Here, we provide
A calculus of components with dynamic type-checking
- Electronic Notes in Theoretical Computer Science, 2006. Formal Aspects of Component Software
, 2006
"... We present a simple module calculus modeling software composition in an open environment, where some components can be provided from the outside after execution has started. Operators for combining software components are as in previous module calculi; here, we focus on the new problems posed by the ..."
Abstract
-
Cited by 5 (2 self)
- Add to MetaCart
We present a simple module calculus modeling software composition in an open environment, where some components can be provided from the outside after execution has started. Operators for combining software components are as in previous module calculi; here, we focus on the new problems posed by the fact that components are not all available at compile time. In particular, we want to be able to statically check internal consistency of local code, by only specifying a required type for missing components, and then to perform dynamic checks which ensure that code received from the outside, which is assumed to travel with its type, can be successfully accepted, without requiring to type-check the whole code again. We consider two alternative solutions. The former uses simple dynamic checks based on standard subtyping, that is, a component can be safely combined with local code if it provides the expected features, and all additional features are hidden, thus avoiding conflict problems. The latter preserves the semantics we would get having all components statically available, but requires a more involved type system based on constraints, where dynamic checks prevent conflicts.
Type inference and principal typings for symmetric record concatenation and mixin modules
, 2005
"... The obvious simple type system for a λ-calculus extended with record concatenation has a typability problem that was believed to be expensive, and which we prove NP-complete. Some previous approaches to this problem employ subtyping polymorphism. We present Bowtie, a system of simple types for rec ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
The obvious simple type system for a λ-calculus extended with record concatenation has a typability problem that was believed to be expensive, and which we prove NP-complete. Some previous approaches to this problem employ subtyping polymorphism. We present Bowtie, a system of simple types for record concatenation which has principal typings, no subtyping, and a clean separation between unification-based type inference with type and row variables and constraint solving for safety of concatenation and field selection. Because Bowtie has no subtyping, we succeeded in straightforwardly generalizing it to a similar type system, Martini, for mixin modules. The type inference complexity for both systems is O(n 2), or O(n) given a bounded number of field labels. 1 We have implemented type inference for both type systems. Because they have principal typings, extending either with Milner’s let-polymorphism is straightforward.
Flattening versus direct semantics for Featherweight Jigsaw
- In FOOL'09 - Intl. Workshop on Foundations of Object Oriented Languages, 2009. To appear. Gary T. Leavens. Tutorial on JML, the
, 2007
"... Inheritance in object-oriented languages allows, roughly, to obtain the same effect one would get by duplicating the methods of the parent class in the heir. However, the key advantage is that source code duplication is avoided, and the code of the parent is, instead, found on demand, through a runt ..."
Abstract
-
Cited by 2 (2 self)
- Add to MetaCart
Inheritance in object-oriented languages allows, roughly, to obtain the same effect one would get by duplicating the methods of the parent class in the heir. However, the key advantage is that source code duplication is avoided, and the code of the parent is, instead, found on demand, through a runtime procedure called method lookup. In other words, two different semantics of inheritance can be given: flattening semantics, that is, by translation into a language with no inheritance, and direct semantics, that is, by formalizing dynamic method look-up. Analogously, many other composition mechanisms which have been proposed for enhancing the objectoriented paradigm, such as mixins and traits, can be formally defined either by translation into standard inheritance, or by a providing a direct execution model. Flattening semantics generally provides a simpler model and can be used as a guide in language design. However, it is not adequate for compositional analysis since the binary code for each code fragment, say, a class, can be generated only when all used fragments are available. In this paper we define both semantics and prove their equivalence for Featherweight Jigsaw, a class-based language providing a very general framework for software composition, subsuming, besides other mechanisms, standard inheritance, mixins, and traits.

