A Distributed Object-Oriented Language with Session Types

Abstract:

In the age of the world-wide web and mobile computing, programming communication-centric software is essential. Thus, programmers and program designers are exposed to new levels of complexity, such as ensuring the correct composition of communication behaviours and guaranteeing deadlock-freedom
of their protocols.
This paper proposes the language L_doos, a simple distributed object-oriented language augmented with session communication primitives and types. L_doos provides a flexible object-oriented programming style for structural interaction protocols by prescribing channel usages within signatures of distributed classes.
We develop a typing system for L_doos and prove its soundness with respect to the operational semantics. We also show that in a well-typed L_doos program, there will never be a connection error, a communication error, nor an incorrect completion between server-client interactions. These results demonstrate that a consistent integration of object-oriented language features and session types offers a compositional method to statically check safety of communication protocols.

Ticket-passing style?

Upon further reflection, I think it does not make sense for application programmer to control CPU distribution down to the ticks.
This would over-specify the scheduling requirements, which often are quite lax.
Presence of multiple physical processors makes the situation even worse.

What probably makes sense is to allow the application developer to explicitly track the separate computation parts, assigning to them various properties, and enabling two-way reflective link between the programmer and the real scheduler.

Think of this as a task management system, e.g., Jira.
Persons acting in one role can create tasks, manage their dependencies, deadlines, estimates and priorities, while persons in another role execute the project making sure the tasks are completed at a satisfactory time.
The first role is like one for the application developer, the second one is for the scheduler of the language's runtime.

Manticore

naasking mentioned that Manticore has nested schedulers - sounds very interesting, and similar to what I want to achieve in Fluid. Must read that.

Fluid preManifesto

At this point of my life I don't have much time to actively pursue the research I would like to. I decided to make an overview of what is envisioned, so that at least I do not forget that myself when I have spare minute or two.

Fluid is a codename for programming language/framework/calculus/tool that should enable experiments with and teaching of various approaches to concurrency and possibly parallelism.
During my initial experiments with join calculus I decided that a lot of interesting stuff is being swept under the carpet. For one thing, scheduling of reactions is implicit on one hand, and rigid on the other. What if one had a language in which diving into the gory details of scheduling would be a matter of using some operator, like call/cc is being used to dive into underlying continuations? No scheduling would be left implicit, all interleaving would be deterministic and controlled - mostly using popular constructs from the library in a very lean syntactic way (monadic reflection?), but occasionally giving possibility to do exactly what is needed. At runtime, something similar to engines looks promising.

The language would follow the maxim Algorithm = Logic + Control, separating declarative part of the solution from the control of when to pursue which way and for how long. It must be possible to ration CPU cycles and other resources based on the perceived relative utility of the computations, as well as to prune the computations that are believed to have too few value to be worth any future resources. This utility-aware side of the research might come close to the mechanism design (most probably the algorithmic branch of it).

Having outsourced the scheduling to the user code, the next question is how to express the declarative part of the solution. After playing with various alternatives (promises, MVars, channels) I decided that concurrent constraint programming looks most general of them all. But which constraint system to choose? Or should I choose some specific system at all? As control part is very customizable, why not follow the same path in the logical part? I don't yet know the details, or whether it is possible at all, but the idea is to allow user code to define the constraint system as well.

To put it all in one line: Program = Logic + Control, Your Way, Best Value for Resources!

I would like to write much more, but my margin (of time) is too small, so I finish here.

A Software Architecture for Distributed Control Systems and Its Transition System Semantics

A software architecture for distributed control systems is presented that is based on a shared data space coordination model. The architecture, named SPLICE, is introduced in two steps.First we give the general structure of the coordination model including the shared data space and the basic operations and we define its semantics by means of a transition system. Second we present a transition system for a refinement of the coordination model: data is distributed and replicated across a communication network using a publication-subscription protocol. We also discuss methods in SPLICE for fault-tolerance and the possibility for on-line system modification and extensions.

Similar to Linda, JavaSpaces, and other paradigms of communication via shared store.

SOA kills ORM?

Recently I participated in several projects that heavily utilized services (message-based, shared-nothing, over-the-wire thingies). What I noticed is that object/relational mapping (ORM) tools are virtually useless for such projects. Indeed, significant, if not most value of ORM comes from ability to modify values in memory, using OO language constructs for that, and then just synchronize the memory with the database. This functionality goes completely unutilized in typical SOA application, where reads and writes are separated in time, use different objects and acces paths, and in fact can be performed from different machines. E.g., one service can read a list of tasks from the DB and return them as a message to the network peer. After traveling between peers this information (but not this specific object or message) in combination with information from other sources (e.g., user input) can be used to update a specific property of a specific task (written back to the DB). Has need for service/relational (or message/relational) mapping indeed arrived?

JoinJavaScript

Sometimes I have to use JavaScript for my daily programming, and while it takes some time to switch to it, it has certain beauty and allows some expressivity missing in "bigger" languages like Java or C#.

I tried to identify, what features make it shine, and what features might add even more to the mix.

So great and already present:

1. Free extension of any object with properties ("every object is a dictionary").
2. (Limited) introspection ("for in").
3. Closures as first-class values ("closure is a value", and even "closure is an object").
4. Prototypes for ad hoc extensibility, e.g., interception of closure invocation at prototype level.

Potentially great, but missing:

1. Ergonomic way to qualify property names (a la XML or RDF).
2. More and deeper interception - e.g., access to properties (get/put/foreach).
3. More advanced control operators - e.g., co-routines and generators.
4. Concurrency at language level.
5. More like a constraint on other features - capability-based security.

I see certain synergy among proposed features, so adding them may not automatically turn the language into a kitchen sink.

I would try to approach features 3 to 5 via join calculus. Now, if I only had time.