We recently published a new article on AmbientTalk, an actor language I co-designed with a focus on developing mobile applications for ad hoc wireless networks. The main novelty of the article is what we believe to be the first formal account of the communicating event loops model, which is the concurrency model underlying the family of actor languages upon which AmbientTalk is based. Interestingly, this model is also closest to the concurrency model you get in JavaScript, if you think of a WebWorker as an actor. The article gives a comprehensive overview of AmbientTalk’s roots, the language itself, and introduces a “featherweight AmbientTalk” calculus with an operational semantics. We use it to establish data race freedom (actors have isolated memory) and deadlock freedom (assuming all event loop turns are finite, all asynchronous messages sent between actors will eventually be processed). The article is published in the journal “Computer Languages, Systems & Structures”. A preprint copy of the paper is available here. Quoting the abstract:

The rise of mobile computing platforms has given rise to a new class of applications: mobile applications that interact with peer applications running on neighbouring phones. Developing such applications is challenging because of problems inherent to concurrent and distributed programming, and because of problems inherent to mobile networks, such as the fact that wireless network connectivity is often intermittent, and the lack of centralized infrastructure to coordinate the peers. We present AmbientTalk, a distributed programming language designed specifically to develop mobile peer-to-peer applications. AmbientTalk aims to make it easy to develop mobile applications that are resilient to network failures by design. We describe the language’s concurrency and distribution model in detail, as it lies at the heart of AmbientTalk’s support for responsive, resilient application development. The model is based on communicating event loops, itself a descendant of the actor model. We contribute a small-step operational semantics for this model and use it to establish data race and deadlock freedom.

As of this month, I’m working for Alcatel-Lucent Bell Labs in Antwerp, Belgium. I will be doing distributed systems research with a focus on programmability and programming models. I’m still active part-time at the VUB Software Languages Lab.

Yesterday I gave a talk at the European Conference on Object-oriented Programming (ECOOP) on our paper on direct proxies in JavaScript. The slides are available online. The talk is basically recounting the story of how Mark and I refactored the original JavaScript Proxy API into the current direct proxies API because of the interaction between proxies and frozen objects. I have previously written about that interaction on my blog. The paper further focuses on membranes as a case study for proxies.

At the May TC39 meeting I presented [pdf] an overview of Notification Proxies, as a possible alternative to Direct Proxies. This post briefly summarizes my talk, and the feedback I got from the committee. tl;dr: notification proxies are off the table, we’re sticking to direct proxies in ES6.

Read more

This post is about a project I’ve been working on together with Mark Miller (with the help of many others) which we call “Dr. SES”, for Distributed Resilient Secure ECMAScript”. Dr. SES is a JavaScript extension aimed at secure, distributed computing.

Dr. SES extends JavaScript with three features:

• SES: Dr. SES builds upon SES, the capability-secure subset of JavaScript. SES enables the safe execution of mobile code.
• Q: To engage in distributed computing, we need abstractions to send messages to remote objects, and the Promise abstraction to more easily manage asynchronous computations. Mark has previously proposed some extensions to ECMAScript to achieve precisely this. Luckily we do not have to wait for these extensions to land. Except for some syntactic sugar, we can get most of the functionality today via Kris Kowal’s Q library.
• Ken: Ken is a middleware that provides a persistent heap and reliable messaging between such persistent heaps. By integrating Ken with an existing JavaScript engine, we can achieve a JavaScript platform that persists across failures. One of my students is currently working on integrating Ken with the v8 engine, leading to an engine we call v8-ken.

Mark recently got invited as a speaker at ESOP 2013, and was given the opportunity to publish a paper to go along with the talk. The paper is probably the first written exposition of Dr. SES to date. It got published only recently, here’s a link to the pre-published version. The subject of the paper is not really about Dr. SES, but rather about what type of applications we can achieve on top of a platform such as Dr. SES. Nevertheless, Section 2 provides a good background on what Dr. SES ought to become. The paper is really a progress report, as Dr. SES is still very much a work in progress. Quoting the abstract of the paper:

Contracts enable mutually suspicious parties to cooperate safely through the exchange of rights. Smart contracts are programs whose behavior enforces the terms of the contract. This paper shows how such contracts can be specified elegantly and executed safely, given an appropriate distributed, secure, persistent, and ubiquitous computational fabric. JavaScript provides the ubiquity but must be significantly extended to deal with the other aspects. The first part of this paper is a progress report on our efforts to turn JavaScript into this fabric. To demonstrate the suitability of this design, we describe an escrow exchange contract implemented in 42 lines of JavaScript code.

The paper is based on two earlier talks of Mark:

• Bringing Object-orientation to Security Programming (video, slides), which provides a good introduction to object-capabilities and the Purse example in particular.
• Two-phase commit among strangers (slides, audio), which provides a general overview of Dr. SES (with a particular focus on Q) and of the escrow exchange contract, which is discussed in detail in the paper.

The source code discussed in the paper is available.