It seems the only way to make co-action complete is to make coherence deterministic. That is my strong preference anyway. Unfortunately I have also discovered that the “client/server barriers” I proposed in the NEPLS talk do not work in all cases. I am thinking about alternatives, but so far they all require making static declarations in the code, which is a burden to the programmer. Perhaps it is better to just live with incompleteness for screwy code like the counterexample, which probably never actually occurs. Either way, it is not as pretty a picture as I was hoping for.

Co-action

Co-action is a new form of synchronous reactive programming. From the programmer’s point of view, all actions take place simultaneously, and all interdependencies between actions are resolved instantaneously. Eliminating execution order avoids many of the complexities and pitfalls of imperative programming. What is novel is that co-action also supports an imperative model of state, with a heap of dynamically allocated objects pointing to one another, and assignment through pointer variables. Other forms of declarative programming either eliminate pointers or fall back to explicitly ordering execution. Co-action attempts to combine the best of both declarative and imperative programming.

Declarative languages avoid pointers for good reason: to determine a correct execution order, data flow dependencies must be known, but pointer aliasing makes that undecidable at compile time. Co-action instead finds a correct execution order at run time by monitoring program execution and doing rollbacks to backtrack. The undecidable problem at compile time is converted into a search problem at run time. Co-actions are in a sense the dual of transactions, combining synchronous actions instead of isolating asynchronous actions, and parallelizing instead of serializing.

To better study and communicate these ideas, I have defined a small formal calculus. The correctness criterion of an execution order is coherence: every field is written at most once, and prior to any reads. The completeness theorem states that if a coherent execution order exists, then the co-action execution algorithm will find it. As of this writing I have been unable to prove completeness, and am seeking advice.

Barbara Liskov gave her Turing award lecture, talking about how she invented Abstract Data Types thirty years ago. She has not been doing language research for 20 years, and says she is still waiting for someone to invent better language abstractions. She has been repeatedly quoted as saying that current PL research is a dead end, and that Java is good enough. The rumor here is that she is a big reason why no PL researchers have been hired by MIT in over a decade.

William Cook’s essay was the antidote to Liskov. I found it insightful, shedding new light on what we have thought were settled issues. Highly recommended.

Concurrency and multicore is still quite hot. All these talks had the obligatory motivation slide about how CPU clock speed has stalled and so multicore is the only way forward and we have to figure out how to program these beasts. I don’t get it. It is a solution looking for a problem. CPU cycles are a limiting factor in only a fraction of software. Server-side software scales across system farms, not cores. Desktop software is rarely CPU bound anymore. CPU cycles are a lot less important than programmer cycles. But people would probably find Coherence more interesting if I pitch it as a multicore solution. It could be, but I have been trying to focus on what is important, not what is popular.

My own talk got mixed reviews. It was generally compared unfavorably to the Flapjax paper (which won the best student paper award) because they both are concerned with the problem of callbacks. Flapjax uses the demonstrated techniques of FRP and has a solid implementation that is actually usable, whereas my talk was only a brief speculation about a fundamentally new approach that is completely unproven. Unfortunately we were scheduled at the same time, but I had a good talk with Leo Meyerovich and Arjun Guha later. They seem like nice guys, and I am hopeful that we can have a productive dialogue in the future (despite the nasty competitiveness that is common in our field). For example, I heard that Phil Wadler ripped Shriram in the Q&A because he didn’t give sufficient credit to prior FRP work. Why can’t we just all get along?

Phil Wadler and Guy Steele were both at my talk. I felt that Steele avoided talking to me for the rest of the show, giving me a stone face every time I greeted him. We have talked many times in the past, but I was dead to him.

Luckily there were a couple of people who liked the talk and went out of their way to tell me and to encourage me to keep going. I have invitations to visit two places once I have some progress to discuss. That was my main goal for this conference, so it was a success, even though I feel more than ever that I don’t belong in Computer Science.

This presentation about the Scala Eclipse plugin is alarming. These JVM languages tightly couple with Java, and so need to integrate with the Java IDE features. But the Eclipse project has been unwilling to support that. Scala and Groovy have had to resort to binary aspect weaving to monkey-patch Eclipse. Unfortunately it appears that is not sufficient, and the presentation concludes that forking the Eclipse JDT may be the only solution.

Fortunately IntelliJ seems to be doing a good job of supporting these new JVM languages. But it is sad to see that Eclipse, which started as a very progressive forward-looking initiative, is now a roadblock to progress.

I have been hugging trees because they seemed essential to my long-term agenda. But I realize now that if I defer the more ambitious aspects, I can still achieve some major goals with a more normal language, one that uses syntax for code and objects for data. Such a language is not only a lot simpler to invent, but also a lot more approachable to everyone else. Three realizations make this simplification now seem viable.

Firstly, I have remembered that I can make a syntactic language still appear to be live and example-centric in the IDE. That is what I did back in my original Example Centric Programming paper. That work was limited to a purely functional subset of Java. But now with coherence I can equally well visualize the execution of imperative code in the IDE.

Secondly, I can construct updatable views out of objects. My last paper talked about virtual trees, which are computed on demand, but can be read and written like normal trees. I can do the same thing with objects by automatically generating getter and setter methods, and by carefully limiting their visibility. Collections have to change substantially. This will not be a plain vanilla object model.

Thirdly, I can do hypothetical imperative computations (progressions in the paper) using object spaces. A space appears to be a copy of the entire heap, except with some specific changes. Spaces nest, which may offer some of the hierarchical goodness of trees, like deep copying.

The road forward looks like this: right now I am working on my talk at OOPSLA this month. I only have a 20 minute slot, so it will not be very deep. As usual I’ll post a video after the talk. Concurrently, I am working on an informal description of the syntax and semantics of the language to cover roughly the same capabilities as in the paper. I will try to present that in more detail later this fall at NEPLS. Then I need to do a prototype implementation, probably as a REPL without an IDE.

This is a complete 180 from my last move. Oh well. Research is confusing and unpredictable, and I’m not very good at it. I hope I eventually find my way out of the forest.