Substructural typestates

Abstract

Finding simple, yet expressive, verification techniques to reason about both aliasing and mutable state has been a major challenge for static program verification. One such approach, of practical relevance, is centered around a lightweight typing discipline where types denote abstract object states, known as typestates.In this paper, we show how key typestate concepts can be precisely captured by a substructural type-and-effect system, exploiting ideas from linear and separation logic. Building on this foundation, we show how a small set of primitive concepts can be composed to express high-level idioms such as objects with multiple independent state dimensions, dynamic state tests, and behaviororiented usage protocols that enforce strong information hiding. By exploring the relationship between two mainstream modularity concepts, state abstraction and hiding, we also provide new insights on how they naturally fit together and complement one another.Technically, our results are based on a typed lambda calculus with mutable references, location-dependent types, and secondorder polymorphism. The soundness of our type system is shown through progress and preservation theorems. We also describe a prototype implementation of a type checker for our system, which is available on the web and can be used to experiment with the examples in the paper.

Rely-Guarantee Protocols

“…Technically, we build on [21] (a variant of L 3 [1] adapted for usability) by supporting sharing of mutable state through rely-guarantee protocols. As in L 3 , a cell is decomposed in two components: a pure reference (that can be freely copied), and a linear [14] capability used to track the contents of that cell.…”

“…As in L 3 , a cell is decomposed in two components: a pure reference (that can be freely copied), and a linear [14] capability used to track the contents of that cell. Unlike L 3 , by extending [21] our language implicitly threads capabilities through the code, reducing syntactic overhead. To support this separation of references and capabilities, our language uses location-dependent types to relate a reference to its respective capability.…”

“…Some non-essential details are only discussed in [21] since they should be close to type-theoretic concepts and, therefore, straightforward to grasp. In fact, the core system is very similar to that used in [21] but with the addition of intersection types and all of our sharing constructs. For consistency of the presentation, we include all sharing mechanisms here but leave their discussion to Section 4.…”

“…To illustrate this, we use the linear stack ADT from [21] where the stack object has two possible typestates: Empty and Non-Empty. The object, with an initial typestate E(mpty), is accessible through closures returned by the following "constructor" function, newStack:…”

“…Static approaches to reason about such state protocols (of which we follow the typestate [7,21,27,28] approach) have two advantages: errors such as writing to a closed pipe can be avoided on the one hand, and defensive run-time tests of the state of an object can become superfluous on the other hand. In typestate systems, abstractions expose a more refined type that models a set of abstract states representing the internal, changing, type of the state (such as the two states above, open and closed) enabling the static modular manipulation of stateful objects.…”