Last edited: November, 2017
The Go language runtime system has deservedly gained a reputation for efficiency and scaleability across architectures with numbers of processors ranging from one to hundreds. But the Go language itself leaves something to be desired by those who seek higher level ways of directly realizing systems as concurrent compositions of well-specified components communicating by means of channels.
The goal of this project is to define a concurrent language that, like Go, encourages inter-module information sharing by channel communication (in contrast to encouraging the implementation of intermodule communication by memory sharing). Like Communicating Scala Objects, which was modelled, to a certain extent, on OCCAM 3, it should incorporate robust language constructs for concurrent composition, alternation, and termination of composites.
CHOP programming should have something of the flavour of CSO programming, but its design should be semantically conservative -- in the sense that it should be possible for programs in CHOP to be simply translateable into efficient Go programs. We have done some preliminary development of a Go library that supports CSO-like parallel composition, and CSO-like termination of networks of connected components using the propagation of channel closures.
The goal of this project is to reimplement, in Go, an interpreter (or compiler+virtual machine) for a concurrent programming language based on the prototype-based object-oriented language Obol.
The goal of this project is to attempt to answer the question: What would a small extensible operating system kernel implemented in Go look like? We are not particularly ambitious, but we think it might be possible to build something useful for Raspberry-Pi-like machines along the lines of Martin Richards's venerable microkernel *TRIPOS* <http://www.cl.cam.ac.uk/~mr10/Cintpos.html>__.
The Scala language is a powerful object oriented language, with a type system, that is much more flexible and expressive than Java's. Scala's compilers translate into code for the Java Virtual machine. It is particularly convenient to express new programming constructs in Scala.
In 2008 we designed and implemented an OCCAM/CSP-style concurrency library for Scala, called CSO: (see this paper, and the CSO distribution.) The library has been used in a variety of applications as well as for teaching the principles of concurrent programming.
The following projects are associated with CSO:
The goal of this project is to build support in the CSO library for the construction of a variety of models of distributed system. The project will start by implementing a few critical low-level abstractions such as logical time, message piggybacking, and heartbeats. We will test the utility of the implementation by building a small number of simple distributed systems, such as the replicated database described (abstractly) in Bill Roscoe's book.
The goal of this project is to construct a library of communicating components, based on the Scala/CSO library to support the programming of a family of webservers that could range in scale from a full-scale commercial server to an embedded server used to provide a browser-based GUI to a specific application.
The objective of this project is to design a dedicated appliance based on affordable hardware that can be used to make life easier for disabled and/or elderly people (for example stroke victims or those suffering from arthritis) who find it hard to use modern communication tools (such as Skype, Google duo, appear.in, email, etc.) on conventional general-purpose machines (such as laptops and tablets).
There are many barriers -- both cognitive and physical barriers -- to overcome. The physical barriers to controlling applications running on modern desktop machines are almost self-evident. Phones and tablets are somewhat better. Still, the approach taken to security (knowing passwords, having fingers that you can manipulate to the point where the fingerprint reader can check them, etc. etc) can also make it difficult for many people to benefit from even the simplest apps.
For an example of what we mean by cognitive barriers, just count the number of windows that can appear concurrently on the screen of a device during a Skype conversation, and ask yourself how a non-expert of advanced age can be expected to know what gave rise to them. Now imagine yourself as someone of advanced years who simply wants to be visible on Skype so as to receive calls from their family, or to be able to call a relative without having to navigate an address book.
Some of them are messages from the operating system (asking you whether you want to accept the latest software updates); some of them are from the web browser that you accidentally started last week and may not know how to close, etc. etc. Some (see below) may have been caused by your thumb brushing the screen of the tablet by accident....
Some barriers are a mixture of congnitive and physical. Imagine you're in the middle of a video conversation using (say) Google's excellent //appear.in/ and you accidentally grasp the wrong edge of the tablet on which you are making the call. The next thing that happens is that the operating system kernel pops up a message in an unexpected place asking whether you want to power off the machine, restart it, or ignore the message.
Oege de Moor and I wrote a paper on Modeless Structure Editing for Tony Hoare's retirement symposium. The first phase of this project will construct (in Scala or Java or Go) a structure editing toolkit implementing the model explained in this paper. Subsequent phases will provide one or two case studies in its use.