Results 1 - 10
of
45
A Type-Theoretic Approach to Higher-Order Modules with Sharing
, 1994
"... The design of a module system for constructing and main- taining large programs is a difficult task that raises a number of theoretical and practical issues. A fundamental issue is the management of the flow of information between program units at compile time via the notion of an interface. Experie ..."
Abstract
-
Cited by 251 (23 self)
- Add to MetaCart
The design of a module system for constructing and main- taining large programs is a difficult task that raises a number of theoretical and practical issues. A fundamental issue is the management of the flow of information between program units at compile time via the notion of an interface. Experience has shown that fully opaque interfaces are awkward to use in practice since too much information is hidden, and that fully transparent interfaces lead to excessive interdependencies, creating problems for maintenance and separate compilation. The "sharing" specifications of Standard ML address this issue by allowing the programmer to specify equational relationships between types in separate modules, but are not expressive enough to allow the programmer com- plete control over the propagation of type information be- tween modules.
The Programming Language Jigsaw: Mixins, Modularity And Multiple Inheritance
, 1992
"... This dissertation provides a framework for modularity in programming languages. In this framework, known as Jigsaw, inheritance is understood to be an essential linguistic mechanism for module manipulation. In Jigsaw, the roles of classes in existing languages are "unbundled," by providing a suite o ..."
Abstract
-
Cited by 138 (4 self)
- Add to MetaCart
This dissertation provides a framework for modularity in programming languages. In this framework, known as Jigsaw, inheritance is understood to be an essential linguistic mechanism for module manipulation. In Jigsaw, the roles of classes in existing languages are "unbundled," by providing a suite of operators independently controlling such effects as combination, modification, encapsulation, name resolution, and sharing, all on the single notion of module. All module operators are forms of inheritance. Thus, inheritance is not in conflict with modularity in this system, but is indeed its foundation. This allows a previously unobtainable spectrum of features to be combined in a cohesive manner, including multiple inheritance, mixins, encapsulation and strong typing. Jigsaw has a rigorous semantics, based upon a denotational model of inheritance. Jigsaw provides a notion of modularity independent of a particular computational paradigm. Jigsaw can therefore be applied to a wide variet...
The Cecil Language, Specification and Rationale
, 1993
"... Cecil is a new purely object-oriented language intended to support rapid construction of highquality, extensible software. Cecil combines multi-methods with a classless object model, object-based encapsulation, and optional static type checking. Cecil's static type system distinguishes between subty ..."
Abstract
-
Cited by 109 (20 self)
- Add to MetaCart
Cecil is a new purely object-oriented language intended to support rapid construction of highquality, extensible software. Cecil combines multi-methods with a classless object model, object-based encapsulation, and optional static type checking. Cecil's static type system distinguishes between subtyping and code inheritance, but Cecil enables these two graphs to be described with a single set of declarations, optimizing the common case where the two graphs are parallel. Cecil includes a fairly flexible form of parameterization, including both explicitly parameterized objects, types, and methods and implicitly parameterized methods related to the polymorphic functions commonly found in functional languages. By making type declarations optional, Cecil aims to support mixed exploratory and production programming styles. This document describes the design of the Cecil language as of March, 1993. It mixes the specification of the language with discussions of design issues and explanations of...
Modularity meets Inheritance
- IN PROC. INTERNATIONAL CONFERENCE ON COMPUTER LANGUAGES
, 1992
"... We "unbundle" several roles of classes in existing languages, by providing a suite of operators independently controlling such effects as combination, modification, encapsulation, name resolution, and sharing, all on the single notion of module. All module operators are forms of inheritance. Thus, ..."
Abstract
-
Cited by 86 (8 self)
- Add to MetaCart
We "unbundle" several roles of classes in existing languages, by providing a suite of operators independently controlling such effects as combination, modification, encapsulation, name resolution, and sharing, all on the single notion of module. All module operators are forms of inheritance. Thus, inheritance not only is not in conflict with modularity in our system, but is its foundation. This allows a previously unobtainable spectrum of features to be combined in a cohesive manner, including multiple inheritance, mixins, encapsulation and strong typing. We demonstrate our approach in a language (called Jigsaw, as in the tool, not the puzzle!). Our language is modular in two senses: it manipulates modules, and it is highly modular in its own conception, permitting various module combinators to be included, omitted, or newly constructed in various realizations.
A Type System for Higher-Order Modules
, 2003
"... We present a type theory for higher-order modules that accounts for many central issues in module system design, including translucency, applicativity, generativity, and modules as first-class values. Our type system harmonizes design elements from previous work, resulting in a simple, economical ac ..."
Abstract
-
Cited by 77 (19 self)
- Add to MetaCart
We present a type theory for higher-order modules that accounts for many central issues in module system design, including translucency, applicativity, generativity, and modules as first-class values. Our type system harmonizes design elements from previous work, resulting in a simple, economical account of modular programming. The main unifying principle is the treatment of abstraction mechanisms as computational effects. Our language is the first to provide a complete and practical formalization of all of these critical issues in module system design.
Programming with Intersection Types and Bounded Polymorphism
, 1991
"... representing the official policies, either expressed or implied, of the U.S. Government. ..."
Abstract
-
Cited by 64 (4 self)
- Add to MetaCart
representing the official policies, either expressed or implied, of the U.S. Government.
Using Parameterized Signatures to Express Modular Structure
- POPL'96
, 1996
"... Module systems are a powerful, practical tool for managing the complexity of large software systems. Previous attempts to formulate a type-theoretic foundation for modular programming have been based on existential, dependent, or manifest types. These approaches can be distinguished by their use of ..."
Abstract
-
Cited by 63 (1 self)
- Add to MetaCart
Module systems are a powerful, practical tool for managing the complexity of large software systems. Previous attempts to formulate a type-theoretic foundation for modular programming have been based on existential, dependent, or manifest types. These approaches can be distinguished by their use of different quantifiers to package the operations that a module exports together with appropriate implementation types. In each case, the underlying type theory is simple and elegant, but significant and sometimes complex extensions are needed to account for features that are im- portant in practical systems, such as separate compilation and propagation of type information between modules. This paper presents a simple type-theoretic fi'amework for modular programming using parameterized signatmes. The use of quantifiers is treated as a necessary, but independent concern. Using familiar concepts of polymorphism, the resulting module system is easy to understaud and admits true separate compilation. It is also very powerful, supporting high-order, polymorphic, and first-class modules without further extension.
Polymorphic Type Inference and Abstract Data Types
- ACM Transactions on Programming Languages and Systems
, 1994
"... Data Types Konstantin Läufer Martin Odersky Loyola University of Chicago Universität Karlsruhe laufer@math.luc.edu odersky@ira.uka.de June 5, 1994 Technical Report LUC-001 Abridged version appeared in Transactions of Programming Languages and Systems Abstract Many statically-typed programming lan ..."
Abstract
-
Cited by 58 (3 self)
- Add to MetaCart
Data Types Konstantin Läufer Martin Odersky Loyola University of Chicago Universität Karlsruhe laufer@math.luc.edu odersky@ira.uka.de June 5, 1994 Technical Report LUC-001 Abridged version appeared in Transactions of Programming Languages and Systems Abstract Many statically-typed programming languages provide an abstract data type construct, such as the module in Modula-2. However, in most of these languages, implementations of abstract data types are not first-class values. Thus they cannot be assigned to variables, passed as function parameters, or returned as function results. Several higher-order functional languages feature strong and static type systems, parametric polymorphism, algebraic data types, and explicit type variables. Most of them rely on Hindley -Milner type inference instead of requiring explicit type declarations for identifiers. Although some of these languages support abstract data types, it appears that none of them directly provides light-weight abstract dat...
Translucent Sums: A Foundation for Higher-Order Module Systems
, 1997
"... The ease of understanding, maintaining, and developing a large program depends crucially on how it is divided up into modules. The possible ways a program can be divided are constrained by the available modular programming facilities ("module system") of the programming language being used. Experien ..."
Abstract
-
Cited by 53 (0 self)
- Add to MetaCart
The ease of understanding, maintaining, and developing a large program depends crucially on how it is divided up into modules. The possible ways a program can be divided are constrained by the available modular programming facilities ("module system") of the programming language being used. Experience with the Standard-ML module system has shown the usefulness of functions mapping modules to modules and modules with module subcomponents. For example, functions over modules permit abstract data types (ADTs) to be parameterized by other ADTs, and submodules permit modules to be organized hierarchically. Module systems with such facilities are called higher-order, by analogy with higher-order functions. Previous higher-order module systems can be classified as either opaque or transparent. Opaque systems totally obscure information about the identity of type components of modules, often resulting in overly abstract types. This loss of type identities precludes most interesting uses of hi...
The Cecil language -- specification and rationale: Version 3.2
, 2004
"... Cecil is a purely object-oriented language intended to support rapid construction of high-quality, extensible software. Cecil combines multi-methods with a simple classless object model, a kind of dynamic inheritance, modules, and optional static type checking. Instance variables in Cecil are access ..."
Abstract
-
Cited by 49 (4 self)
- Add to MetaCart
Cecil is a purely object-oriented language intended to support rapid construction of high-quality, extensible software. Cecil combines multi-methods with a simple classless object model, a kind of dynamic inheritance, modules, and optional static type checking. Instance variables in Cecil are accessed solely through messages, allowing instance variables to be replaced or overridden by methods and vice versa. Cecil’s predicate objects mechanism allows an object to be classified automatically based on its run-time (mutable) state. Cecil’s static type system distinguishes between subtyping and code inheritance, but Cecil enables these two graphs to be described with a single set of declarations, streamlining the common case where the two graphs are parallel. Cecil includes a fairly flexible form of parameterization, including explicitly parameterized objects, types, and methods, as well as implicitly parameterized methods related to the polymorphic functions commonly found in functional languages. By making type declarations optional, Cecil aims to allow mixing of and migration between exploratory and production programming styles. Cecil supports a module mechanism that enables independently-developed subsystems to be encapsulated, allowing them to be type-checked and reasoned about in isolation despite the presence of multi-methods and subclassing. Objects can be extended externally with additional

