Foundations of path-dependent types

Abstract

A scalable programming language is one in which the same concepts can describe small as well as large parts. Towards this goal, Scala unifies concepts from object and module systems. An essential ingredient of this unification is the concept of objects with type members, which can be referenced through path-dependent types. Unfortunately, pathdependent types are not well-understood, and have been a roadblock in grounding the Scala type system on firm theory.We study several calculi for path-dependent types. We present µDOT which captures the essence -DOT stands for Dependent Object Types. We explore the design space bottom-up, teasing apart inherent from accidental complexities, while fully mechanizing our models at each step. Even in this simple setting, many interesting patterns arise from the interaction of structural and nominal features.Whereas our simple calculus enjoys many desirable and intuitive properties, we demonstrate that the theory gets much more complicated once we add another Scala feature, type refinement, or extend the subtyping relation to a lattice. We discuss possible remedies and trade-offs in modeling type systems for Scala-like languages.

The Essence of Dependent Object Types

“…A preliminary version of DOT was formalized using a small-step operational semantics with a store (Amin et al, 2012) without giving a soundness proof. The first mechanized soundness proof was established for a more restricted variant (µDOT) using a closure-based big-step semantics (Amin et al, 2014). Soundness results with mechanized proofs for versions of System D <: and DOT similar to the ones presented here (but still based on big-step semantics) were only recently established (Rompf and Amin, 2015).…”

“…Work on DOT started in 2007, following earlier work on higher-level formalizations of Scala features (Odersky et al, 2003;Cremet et al, 2006). Preliminary versions of a calculus with path-dependent types were published in FOOL 2012 (Amin et al, 2012) and OOPSLA 2014 (Amin et al, 2014). Soundness results for versions of System D <: and DOT similar to the ones presented here, but based on big-step operational semantics, were recently established with mechanized proofs (Rompf and Amin, 2015).…”

Java and scala's type systems are unsound: the existential crisis of null pointers

“…But nonsense types might not always be written directly by programmers, and they may not be easy to identify. An insistence on preventing nonsense types is what most delayed the development of a core calculus for Scala because nonsense types can so easily arise from even the core features of the language [2].…”

LaCasa: lightweight affinity and object capabilities in Scala

“…In Scala, box.C is a path-dependent type [5,6]; box.C is equivalent to the type box.type#C which selects type C from the singleton type box.type. The type box.type is only compatible with singleton types x.type where the type checker can prove that x and box are always aliases.…”

“…Importantly, implicit resolution fails if no typecompatible implicit value is in scope, or if multiple ambiguous type-compatible implicit values are in scope. 5 The benefit of marking acc as implicit is that within the body of receive, acc does not have to be passed explicitly to methods requiring access permissions, including LACASA expressions like open. Figure 2 makes Figure 3.…”