Coeffects: The next big programming challenge by Tomas Petricek.
From the post:
Context-aware programming matters
The phrase context in which programs are executed sounds quite abstract and generic. What are some concrete examples of such context? For example:
- When writing a cross-platform application, different platforms (and even different versions of the same platform) provide different contexts – the API functions that are available.
- When creating a mobile app, the different capabilities that you may (or may not) have access to are context (GPS sensor, accelerometer, battery status).
- When working with data (be it sensitive database or social network data from Facebook), you have permissions to access only some of the data (depending on your identity) and you may want to track provenance information. This is another example of a context.
These are all fairly standard problems that developers deal with today. As the number of devices where programs need to run increases, dealing with diverse contexts will be becoming more and more important (and I’m not even talking about ubiquitous computing where you need to compile your code to a coffee machine).
We do not preceive the above things as problems (at best, annoyances that we just have to deal with), because we do not realize that there should be a better way. Let me digg into four examples in a bit more detail.
This post is a good introduction to Tomas’ academic work.
A bit further on Tomas explains what he means by “coeffects:”
Coeffects: Towards context-aware languages
The above examples cover a couple of different scenarios, but they share a common theme – they all talk about some context in which an expression is evaluated. The context has essentially two aspects:
- Flat context represents additional data, resources and meta-data that are available in the execution environment (regardless of where in the program you access them). Examples include resources like GPS sensors or databases, battery status, framework version and similar.
- Structural context contains additional meta-data related to variables. This can include provenance (source of the variable value), usage information (how often is the value accessed) or security information (does it contain sensitive data).
As a proponent of statically typed functional languages I believe that a context-aware programming language should capture such context information in the type system and make sure that basic errors (like the ones demonstrated in the four examples above) are ruled out at compile time.
This is essentially the idea behind coeffects. Let’s look at an example showing the idea in (a very simplified) practice and then I’ll say a few words about the theory (which is the main topic of my upcoming PhD thesis).
I don’t know that Tomas would agree but I see his “coeffects,” particularly “meta-data related to variables,” as keying off the subject identity of variables.
Think of it this way: What is the meaning of any value with no express or implied context?
My answer would be that a value without context is meaningless.
Be example, how would you process the value “1” Is it a boolean? Integer? A string?
Imbuing data with “meta-data” (or explicit identity as I prefer) is a first step towards transparent data.
PS: See Petricek and Skeet’s Real-World Functional Programming.