Coeffects: Context-aware programming languages by Tomas Petricek.
From the webpage:
Coeffects are Tomas Petricek‘s PhD research project. They are a programming language abstraction for understanding how programs access the context or environment in which they execute.
The context may be resources on your mobile phone (battery, GPS location or a network printer), IoT devices in a physical neighborhood or historical stock prices. By understanding the neighborhood or history, a context-aware programming language can catch bugs earlier and run more efficiently.
This page is an interactive tutorial that shows a prototype implementation of coeffects in a browser. You can play with two simple context-aware languages, see how the type checking works and how context-aware programs run.
This page is also an experiment in presenting programming language research. It is a live environment where you can play with the theory using the power of new media, rather than staring at a dead pieces of wood (although we have those too).
(break from summary)
Programming languages evolve to reflect the changes in the computing ecosystem. The next big challenge for programming language designers is building languages that understand the context in which programs run.
This challenge is not easy to see. We are so used to working with context using the current cumbersome methods that we do not even see that there is an issue. We also do not realize that many programming features related to context can be captured by a simple unified abstraction. This is what coeffects do!
…
What if we extend the idea of context to include the context within which words appear?
For example, writing a police report, the following sentence appeared:
There were 20 or more <proxy string=”black” pos=”noun” synonym=”African” type=”race”/>s in the group.
For display purposes, the string value “black” appears in the sentence:
There were 20 or more blacks in the group.
But a search for the color “black” would not return that report because the type = color does not match type = race.
On the other hand, if I searched for African-American, that report would show up because “black” with type = race is recognized as a synonym for people of African extraction.
Inline proxies are the easiest to illustrate but that is only one way to serialize such a result.
If done in an authoring interface, such an approach would have the distinct advantage of offering the original author the choice of subject properties.
The advantage of involving the original author is that they have an interest in and awareness of the document in question. Quite unlike automated processes that later attempt annotation by rote.