The Essence of Dependent Object Types

Amin, Nada; Grütter, Samuel; Odersky, Martin; Rompf, Tiark; Stucki, Sandro

doi:10.1007/978-3-319-30936-1_14

Cited by 63 publications

(85 citation statements)

References 30 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…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.…”

Section: Overviewmentioning

confidence: 99%

“…To support such patterns LACASA enables boxes to have unique fields which store boxes. 6 Access is restricted to maintain external uniqueness [18] of unique fields (see Section 3 for a formalization of the uniqueness and aliasing guarantees of unique fields).…”

Section: Overviewmentioning

confidence: 99%

“…The extracted box is accessible via the pack parameter of the subsequent "spore" (see Section 5). 6 As a pragmatic extension, LACASA also enables actors to have unique fields; this is safe, since actors are alias-free, in contrast to ActorRefs.…”

Section: Overviewmentioning

confidence: 99%

See 2 more Smart Citations

LaCasa: lightweight affinity and object capabilities in Scala

HallerPhilipp¹,

LoikoAlex²

2016

SIGPLAN Not.

View full text Add to dashboard Cite

Aliasing is a known source of challenges in the context of imperative object-oriented languages, which have led to important advances in type systems for aliasing control. However, their large-scale adoption has turned out to be a surprisingly difficult challenge. While new language designs show promise, they do not address the need of aliasing control in existing languages.This paper presents a new approach to isolation and uniqueness in an existing, widely-used language, Scala. The approach is unique in the way it addresses some of the most important obstacles to the adoption of type system extensions for aliasing control. First, adaptation of existing code requires only a minimal set of annotations. Only a single bit of information is required per class. Surprisingly, the paper shows that this information can be provided by the object-capability discipline, widely-used in program security. We formalize our approach as a type system and prove key soundness theorems. The type system is implemented for the full Scala language, providing, for the first time, a sound integration with Scala's local type inference. Finally, we empirically evaluate the conformity of existing Scala open-source code on a corpus of over 75,000 LOC.

show abstract

Section: Overviewmentioning

confidence: 99%

Section: Overviewmentioning

confidence: 99%

See 1 more Smart Citation

LaCasa: lightweight affinity and object capabilities in Scala

HallerPhilipp¹,

LoikoAlex²

2016

SIGPLAN Not.

View full text Add to dashboard Cite

show abstract

“…After many false starts, the first mechanized soundness proof for a calculus of the DOT (Dependent Object Types) [4] family was finally presented in 2014 [5].…”

Section: Introductionmentioning

confidence: 99%

Type soundness for dependent object types (DOT)

RompfTiark

AminNada²

2016

SIGPLAN Not.

Self Cite

View full text Add to dashboard Cite

Scala's type system unifies aspects of ML modules, objectoriented, and functional programming. The Dependent Object Types (DOT) family of calculi has been proposed as a new theoretic foundation for Scala and similar expressive languages. Unfortunately, type soundness has only been established for restricted subsets of DOT. In fact, it has been shown that important Scala features such as type refinement or a subtyping relation with lattice structure break at least one key metatheoretic property such as environment narrowing or invertible subtyping transitivity, which are usually required for a type soundness proof.The main contribution of this paper is to demonstrate how, perhaps surprisingly, even though these properties are lost in their full generality, a rich DOT calculus that includes recursive type refinement and a subtyping lattice with intersection types can still be proved sound. The key insight is that subtyping transitivity only needs to be invertible in code paths executed at runtime, with contexts consisting entirely of valid runtime objects, whereas inconsistent subtyping contexts can be permitted for code that is never executed.

show abstract

“…However, in a language like Scala which is enriched with features like inheritance, typecase [1], traits [9], GADTs [4,12], path-dependent types [2] and union types [3], exhaustivity checking becomes complex. Without good abstraction, each feature complicates the algorithm a little bit and the combination of features results in a monolithic algorithm that's impossible to maintain.…”

Section: Introductionmentioning

confidence: 99%

A generic algorithm for checking exhaustivity of pattern matching (short paper)

Liu

2016

Proceedings of the 2016 7th ACM SIGPLAN Symposium on Scala

View full text Add to dashboard Cite

Algebraic data types and pattern matching are key features of functional programming languages. Exhaustivity checking of pattern matching is a safety belt that defends against unmatched exceptions at runtime and boosts type safety. However, the presence of language features like inheritance, typecase, traits, GADTs, path-dependent types and union types makes the checking difficult and the algorithm complex. In this paper we propose a generic algorithm that decouples the checking algorithm from specific type theories. The decoupling makes the algorithm simple and enables easy customization for specific type systems.

show abstract

The Essence of Dependent Object Types

Cited by 63 publications

References 30 publications

LaCasa: lightweight affinity and object capabilities in Scala

LaCasa: lightweight affinity and object capabilities in Scala

Type soundness for dependent object types (DOT)

A generic algorithm for checking exhaustivity of pattern matching (short paper)

Contact Info

Product

Resources

About