For.example

I just had a heated debate with Toon Verwaest about applications of context aware programming languages. Given his background with AmbientTalk his views are rather different than mine. To him, context includes availability and proximity of mobile devices, whereas I am more focused on programming-language specific context. In this post, I’d like to order the views and thoughts that we had been discussing. In particular I’ll try to identify different kinds of context with regard to message dispatch. 

• The first distinction is between context of the sender and context of the receiver. In the first case, the behavior of an object depends on our view on it. In the second case, the behavior depends on the object itself. A special case of receiver (or is it sender?) context is multiple dispatch, that is context depending on the arguments of the sent message. 
• The next distinction is between programming-specific context and external context. External context depends neither on the sender nor on any other construct of the programming language. Examples of external context are the weather, the current room temperature, or the availability of external resources such as the wireless telephone network or a the printer next doors. External context often is either categorical or numerical, that is, it is either modeled by an enumeration of states or by some numerical value.
• I am unsure where spatial context deserves a distinction of its own. For example, for robots on a football field proximity to the other players and the goals is context as well (taken from Collaborative Confusion, via HOP). Clearly, external context is a generalization of spatial context but there may be good reasons to treat spatiality as a context of its own. Geometry and metric distance set spatial context apart from other external contexts. Actually, positions in any metric space can be used to define spatial proximity.
• Programming-specific context is obviously further subdivided into lexical and dynamic context. Lexical context is typically given by the location in the source code. More general, it is given by location within an program’s structure. Dynamic context on the other hand is given by the flow of execution. Technically, dynamic context often boils down to the context given by the call stack.
• However, lexical and dynamic context are not the only programming-specific context. Considering Adrian Lienhard’s theory of aliases we can dispatch messages based on the object flow. For example, the reference returned by a collection’s #get method could understand the context-aware method #next which yields the next object within the aforementioned collection. This approach may take us beyond a mere sender-receiver distinction to behavior that depends on the origin of a reference.
• Other programming-specific contexts are composition and state. For example, messages sent to a collection could be dispatched to different methods depending on the type of the collection’s elements, which is what we do in Swarm Behavior. In the same way, we can imagine behavior that depends on the state of the sender. Given the popularity of both the State and the Strategy pattern, it seems useful to bring this kind of context closer to the language.

Enought brain dump, I am now off to read the Context-oriented Programming paper by Robert Hirschfeld, Pascal Costanza, and Oscar Nierstrasz. And as you can imagine, discussion with Toon is already continuing by chat…