A type-theoretic approach to higher-order modules with sharing

Harper, Robert; Lillibridge, Mark

doi:10.1145/174675.176927

Cited by 216 publications

(186 citation statements)

References 25 publications

Supporting

Mentioning

186

Contrasting

Order By: Relevance

“…In this context, path-dependent types go back at least to SML (Macqueen, 1986), with foundational work on transparent bindings by Harper and Lillibridge (1994) and Leroy (1994). Unlike DOT, their systems are stratified, i.e.…”

Section: Related Workmentioning

confidence: 99%

The Essence of Dependent Object Types

Amin

Grütter

Odersky

et al. 2016

A List of Successes That Can Change the World

View full text Add to dashboard Cite

Abstract. Focusing on path-dependent types, the paper develops foundations for Scala from first principles. Starting from a simple calculus D<: of dependent functions, it adds records, intersections and recursion to arrive at DOT, a calculus for dependent object types. The paper shows an encoding of System F with subtyping in D<: and demonstrates the expressiveness of DOT by modeling a range of Scala constructs in it.

show abstract

Section: Related Workmentioning

confidence: 99%

The Essence of Dependent Object Types

Amin

Grütter

Odersky

et al. 2016

A List of Successes That Can Change the World

View full text Add to dashboard Cite

show abstract

“…Units are analogous to ML's functor module system [25,26] and the mixins and traits of OO programming languages [27,28].…”

Section: Contracts For Nominally Linked Unitsmentioning

confidence: 99%

Nested and Dynamic Contract Boundaries

Strickland

Felleisen

2010

Implementation and Application of Functional Languages

View full text Add to dashboard Cite

Abstract. Previous work on software contracts assumes fixed and statically known boundaries between the parties to a contract. Implementations of contract monitoring systems rely on this assumption to explain the nature of contract violations and to assign blame to violators. In this paper, we explain how to implement arbitrary, nested, and dynamic contract boundaries with two examples. First, we add nestable contract regions to a static, first-order module system. Second, we show that even a dynamic, higher-order, and hierarchical module system can be equipped with software contracts that support precise blame assignment. Contracts for ModulesPLT Scheme [1] comes with a widely used contract system for specifying behavioral (functional) properties of module exports and imports. Roughly speaking, a behavioral software contract imposes restrictions on the domain and range of a function that flows from one module to another. If the function does not produce the kind of values promised in a contract, the run-time monitoring system raises a contract exception and blames the server module for exporting an ill-behaved function. Conversely, if the client module applies an imported function to values that fail to satisfy the domain contract, the run-time system blames the client for not living up to its promises.Unlike other systems for monitoring behavioral software contracts [2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17], PLT Scheme's contract system does not restrict contracts to first-order functions and methods. Instead, programmers may formulate contracts for all kinds of values, including higher-order values [18]. The module system, however, is restrictive. In particular, modules are merely first-order namespaces, without mechanism for nesting them or linking them in a recursive fashion. Naturally programmers chafe under this module system and call for more flexibility.At the same time, the theory of contracts assumes fixed and statically known boundaries between contract parties. Contract implementations combine compilers that can determine the parties to each contract from the source text with a run-time checking system that exploits this knowledge for blaming violators.In this paper, we relax these restrictions and show how to add arbitrary contract boundaries to the PLT Scheme module system and how to implement

show abstract

“…Modules that are sealed with a signature to impose type abstraction [11] are regarded as impure. In other words, sealing is regarded as a pro forma computational effect.…”

Section: Abstraction and Sealingmentioning

confidence: 99%

“…Some previous attempts have encountered difficulties with undecidability [11] or incompleteness of type checking [27]. In contrast, our formalism leads to a practical, implementable programming language.…”

Section: Existential Signaturesmentioning

confidence: 99%

See 1 more Smart Citation

A type system for higher-order modules

2003

Self Cite

View full text Add to dashboard Cite

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.

show abstract

A type-theoretic approach to higher-order modules with sharing

Cited by 216 publications

References 25 publications

The Essence of Dependent Object Types

The Essence of Dependent Object Types

Nested and Dynamic Contract Boundaries

A type system for higher-order modules

Contact Info

Product

Resources

About