Typechecking protocols with Mungo and StMungo: a session type toolchain for Java

Static typechecking is an important feature of many standard programming languages. However, static typing focuses on data rather than communication, and therefore does not help programmers correctly implement communication protocols in distributed systems. The theory of session types provides a basis for tackling this problem; we use it to develop two tools that support static typechecking of communication protocols in Java. The first tool, Mungo, extends Java with typestate definitions, which allow classes to be associated with state machines defining permitted sequences of method calls: for example, communication methods. The second tool, StMungo, takes a session type describing a communication protocol, and generates a typestate specification of the permitted sequences of messages in the protocol. Protocol implementations can be validated by Mungo against their typestate definitions and then compiled with a standard Java compiler. The result is a toolchain for static typechecking of communication protocols in Java. We formalise and prove soundness of the typestate inference system used by Mungo, and show that our toolchain can be used to typecheck a client for the standard Simple Mail Transfer Protocol (SMTP)

Behavioral types in programming languages

A recent trend in programming language research is to use behav- ioral type theory to ensure various correctness properties of large- scale, communication-intensive systems. Behavioral types encompass concepts such as interfaces, communication protocols, contracts, and choreography. The successful application of behavioral types requires a solid understanding of several practical aspects, from their represen- tation in a concrete programming language, to their integration with other programming constructs such as methods and functions, to de- sign and monitoring methodologies that take behaviors into account. This survey provides an overview of the state of the art of these aspects, which we summarize as the pragmatics of behavioral types

Deadlock-Free Typestate-Oriented Programming

Context. TypeState-Oriented Programming (TSOP) is a paradigm intended to help developers in the implementation and use of mutable objects whose public interface depends on their private state. Under this paradigm, well-typed programs are guaranteed to conform with the protocol of the objects they use. Inquiry. Previous works have investigated TSOP for both sequential and concurrent objects. However, an important difference between the two settings still remains. In a sequential setting, a well-typed program either progresses indefinitely or terminates eventually. In a concurrent setting, protocol conformance is no longer enough to avoid deadlocks, a situation in which the execution of the program halts because two or more objects are involved in mutual dependencies that prevent any further progress. Approach. In this work, we put forward a refinement of TSOP for concurrent objects guaranteeing that well-typed programs not only conform with the protocol of the objects they use, but are also deadlock free. The key ingredients of the type system are behavioral types, used to specify and enforce object protocols, and dependency relations, used to represent abstract descriptions of the dependencies between objects and detect circularities that might cause deadlocks. Knowledge. The proposed approach stands out for two features. First, the approach is fully compositional and therefore scalable: the objects of a large program can be type checked in isolation; deadlock freedom of an object composition solely depends on the types of the objects being composed; any modification/refactoring of an object that does not affect its public interface does not affect other objects either. Second, we provide the first deadlock analysis technique for join patterns, a high-level concurrency abstraction with which programmers can express complex synchronizations in a succinct and declarative form. Grounding. We detail the proposed typing discipline for a core programming language blending concurrent objects, asynchronous message passing and join patterns. We prove that the type system is sound and give non-trivial examples of programs that can be successfully analyzed. A Haskell implementation of the type system that demonstrates the feasibility of the approach is publicly available. Importance. The static analysis technique described in this work can be used to certify programs written in a core language for concurrent TSOP with proven correctness guarantees. This is an essential first step towards the integration and application of the technique in a real-world developer toolchain, making programming of such systems more productive and less frustrating

Concurrent Typestate-Oriented Programming in Java

We describe a generative approach that enables concurrent typestate-oriented programming in Java and other mainstream languages. The approach allows programmers to implement objects exposing a state-sensitive interface using a high-level synchronization abstraction that synchronizes methods with the states of the receiver object in which those methods have an effect. An external tool takes care of generating all the boilerplate code that implements the synchronization logic. Behavioral types are used to specify object protocols. The tool integrates protocol conformance verification with the synchronization logic so that protocol violations are promptly detected at runtime.Comment: In Proceedings PLACES 2019, arXiv:1904.0039

State Controlled Object Oriented Programming

In this thesis, we examine an extension to the idea of object oriented programming to make programs easier for people and compilers to understand. Often objects behave differently depending on the history of past operations as well as their input that is their behavior depends on state. We may think of the fields of an object as encoding two kinds of information: data that makes up the useful information in the object and state that controls its behavior. Object oriented languages do not distinguish these two. We propose that by specifying these two, programs become clearer for people to write and understand and easier for machines to transform and optimize. We introduce the notion of state controlled object oriented programming, abbreviated as “SCOOP”, which encompasses explicit support of state in objects. While introducing an extension to object oriented programming, our objective is to minimize any burden on the programmer while programming with SCOOP. Static detection of the current state of an object by programming languages has been a challenge. To overcome this challenge without compromising our objective, a technique is presented that advances contemporary work. We propose an implementation scheme for a SCOOP compiler that effectively synchronizes the external and internal representation of state of objects. As an implication of this scheme, SCOOP would provide the memento design pattern by default. We also show how a portion of an object particular to its state can be replaced dynamically, allowing state dependent polymorphism. Further, we discuss how programs coded in SCOOP can be model checked

Advanced typing for asset-aware programming languages

openLa rilevazione di errori nei linguaggi di programmazione è sempre stata importante nel ridurre la presenza di bug e vulnerabilità del software e lo sviluppo di strumenti che aiutino i programmatori in tal senso sono cruciali per le aziende del settore. Nei programmi è possibile riscontrare diverse tipologie di errori che possono causare comportamenti inaspettati da parte del software o addirittura al crash. Fortunatamente, alcuni di questi errori possono essere individuati usando sistemi di tipi e compilatori. Tuttavia, i moderni compilatori potrebbero non essere più abbastanza: infatti, lo spettro di possibili errori introdotti dai programmatori si è molto ampliato insieme alla complessità dei sistemi informatici odierni, come ad esempio le blockchain. I linguaggi per questi ambienti dovrebbero considerare una nuova categoria di errori correlata agli asset: infatti, in questi casi la loro duplicazione, creazione o perdita arbitraria dovrebbe essere evitata. Queste tipologie di errori sono strettamente correlati al concetto di stato di un oggetto, il quale è un’istanza di uno smart contract. In questa tesi, vengono discussi due linguaggi di programmazione typestate-oriented progettati per lo sviluppo di smart contracts, Stipula e Obsidian, vengono messi a confronto in termini di espressività e proprietà. In questa analisi, si può notare che Stipula adotta un approccio più safe e flessibile di Obsidian nella scrittura di legal contracts, grazie alla disponibilità di determinate primitive di linguaggio. Queste funzionalità permettono una realizzazione più semplice e comprensibile dei contratti e costringe il programmatore a un approccio più safe nello sviluppo. D’altro canto, Stipula non possiede altre funzionalità, come tipi user-defined e strutture dati, tipiche dei linguaggi di programmazione a oggetti: in particolare, non supporta un sistema di tipi completo e che permetta di assicurare proprietà di safety per gli asset. Successivamente, viene fornita e discussa una realizzazione in Obsidian delle currencies e dei tokens usati in Stipula allo scopo di trovare un modo di aggiungere in questo nuovo linguaggio un sistema di ownership, il quale potrebbe aiutare nella rilevazione di errori per riferimenti ad asset. Vengono, dunque, fornite le dimostrazioni che gli statement presi in considerazione sono ben tipati: gli strumenti teorici usati nelle dimostrazioni forniscono effettivamente delle indicazioni su come l’ownership dovrebbe funzionare in Stipula. Questa tesi si concentra sulla ricerca di funzionalità e pratiche per migliorare l’espressività dei linguaggi typestate-oriented. Obsidian è un linguaggio staticamente tipato e typestate-oriented con una particolare attenzione alla safety, alla security e all’usabilità. Queste caratteristiche fanno parte anche dei principali obiettivi di Stipula, un nuovo linguagggio typestate-oriented per i legal contracts. L’inserimento di tali funzionalità in Stipula potrebbe essere un buon modo per migliorarne le proprietà di safety e l’esperienza d’uso del programmatore.Error detection in programming languages has always been important in reducing bugs and vulnerabilities in programs and tools that help programmers in this task are crucial for the industry. Several kinds of error may occur in programs that can cause unexpected behaviours and lead to crashes. Fortunately, some of them can be detected using type systems and compilers. However, modern compilers may not be enough anymore: in fact, the range of mistakes that programmers may introduce is widely spread with the increasing complexity of today’s systems, such as blockchains. Languages for these environments should consider new classes of errors related to assets: in fact, in this context arbitrary duplication, creation or loss of assets should be avoided. These new kinds of error are strictly related to the concept of the state of objects, which are in blockchains smart contract instances. In this thesis, we discuss two typestated-oriented programming languages designed for smart contracts development, Stipula and Obsidian, and compare their expressiveness and main properties. In this analysis, we notice that Stipula adopts a safer and more flexible approach than Obsidian in legal contract writing, due to the primitives available for programmers. These features enable a simpler and more readable implementation of contracts and enforce a safer approach to development. On the other hand, Stipula lacks typical functionalities, such as user-defined data and data structures, that other object-oriented programming languages have: in particular, it does not support a full-fledged type system that ensures safety properties on asset operation. Then, an Obsidian implementation for currencies and tokens used in Stipula is provided and discussed in order to find hints to add in this new language ownership, which would help in error detection for asset references. Proofs that they are well-typed are provided: the tools used in these demonstrations give us some hints, especially on how ownership should work in Stipula statements. This thesis focused on the search for features and practises to improve the expressiveness of typestate-oriented programming languages. Obsidian is a statically-typed and typestate-oriented with careful attention to safety, security and usability. These features fall within the main goals of Stipula, a newborn typestate-oriented language for legal contracts. The insertion of such features in Stipula may be a good way to improve its safety and users’ experience

Typechecking Java Protocols with [St]Mungo

This is a tutorial paper on [St]Mungo, a toolchain based on multiparty session types and their connection to typestates for safe distributed programming in Java language. The StMungo (“Scribble-to-Mungo”) tool is a bridge between multiparty session types and typestates. StMungo translates a communication protocol, namely a sequence of sends and receives of messages, given as a multiparty session type in the Scribble language, into a typestate specification and a Java API skeleton. The generated API skeleton is then further extended with the necessary logic, and finally typechecked by Mungo. The Mungo tool extends Java with (optional) typestate specifications. A typestate is a state machine specifying a Java object protocol, namely the permitted sequence of method calls of that object. Mungo statically typechecks that method calls follow the object’s protocol, as defined by its typestate specification. Finally, if no errors are reported, the code is compiled with javac and run as standard Java code. In this tutorial paper we give an overview of the stages of the [St]Mungo toolchain, starting from Scribble communication protocols, translating to Java classes with typestates, and finally to typechecking method calls with Mungo. We illustrate the [St]Mungo toolchain via a real-world case study, the HTTP client-server request-response protocol over TCP. During the tutorial session, we will apply [St]Mungo to a range of examples having increasing complexity, with HTTP being one of them