Context Oriented Programming (COP) concerns the ability of programs to adapt
to changes in their running environment. A number of programming languages
endowed with COP constructs and features have been developed. However, some
foundational issues remain unclear. This paper proposes adopting static
analysis techniques to reason on and predict how programs adapt their
behaviour. We introduce a core functional language, ContextML, equipped with
COP primitives for manipulating contexts and for programming behavioural
variations. In particular, we specify the dispatching mechanism, used to select
the program fragments to be executed in the current active context. Besides the
dynamic semantics we present an annotated type system. It guarantees that the
well-typed programs adapt to any context, i.e. the dispatching mechanism always
succeeds at run-time.Comment: In Proceedings PLACES 2012, arXiv:1302.579

Degano, Pierpaolo

Ferrari, Gian-Luigi

Galletta, Letterio

Mezzetti, Gianluca

Electronic Proceedings in Theoretical Computer Science

English

arXiv

Pierpaolo Degano

Gian-Luigi Ferrari

Letterio Galletta

Gianluca Mezzetti

Crossref

Typing Context-Dependent Behavioural Variation

Galletta, L

Archivio della ricerca della Scuola IMT Alti Studi Lucca

Context Oriented Programming (COP) concerns the ability of programs to adapt to changes in their running environment. A number of programming languages endowed with COP constructs and features have been developed. However, some foundational issues remain unclear. This paper proposes adopting static analysis techniques to reason on and predict how programs adapt their behaviour. We introduce a core functional language, ContextML, equipped with COP primitives for manipulating contexts and for programming behavioural variations. In particular, we specify the dispatching mechanism, used to select the program fragments to be executed in the current active context. Besides the dynamic semantics we present an annotated type system. It guarantees that the well-typed programs adapt to any context, i.e. the dispatching mechanism always succeeds at run-time

Directory of Open Access Journals

S. J. Gay and P. H. Kelly (Eds.): Programming Language Approaches toConcurrency- and Communication-cEntric Software (PLACES2012)EPTCS 109, 2013, pp. 28–33, doi:10.4204/EPTCS.109.5c© Degano, Ferrari, Galletta and MezzettiThis work is licensed under theCreative Commons Attribution License.Typing Context-Dependent Behavioural VariationsPierpaolo Degano Gian-Luigi Ferrari Letterio Galletta Gianluca Mezzettidegano@di.unipi.it giangi@di.unipi.it galletta@di.unipi.it mezzetti@di.unipi.itDipartimento di Informatica, Università di Pisa, Pisa, ItlyContext Oriented Programming (COP) concerns the ability ofpr grams to adapt to changes in theirrunning environment. A number of programming languages endowe with COP constructs and fea-tures have been developed. However, some foundational issues remain unclear. This paper proposesadopting static analysis techniques to reason on and predict how programs adapt their behaviour. Weintroduce a core functional language, ContextML, equippedwith COP primitives for manipulatingcontexts and for programming behavioural variations. In particular, we specify the dispatching mech-anism, used to select the program fragments to be executed inhe current active context. Besides thedynamic semantics we present an annotated type system. It guarantees that the well-typed programsadapt to any context, i.e. the dispatching mechanism alwayssucceeds at run-time.1 IntroductionComputers increasingly pervade our everyday life, pushed by the great improvements of hardware sys-tems and by the growing usage of digital information.On the one side, computer devices surround people in different shapes and sizes in a highly dis-tributed manner. Devices are often interconnected, can interact each others and share resources. Pro-grams themselves are resources being invokable remote services or downloadable code.On the other side, processing the great quantity of information generated and consumed by devicesleads to a paradigm, where most of the computation and of the storage is demanded to specific, powerfulremote entities. This is the case of Cloud or Grid systems, made of heterogeneous nodes, possiblydistributed in a wide-area.This new setting puts software system into a highly-dynamicenvironment where services, resourcesand hardware components appear, mutate, move and disappear. This calls for a a great shift of program-ming paradigm. In particular, there is a growing interest inthe design and development of applicationsthat are aware of their working environment and areadaptive, i.e. capable to adapt to different situations.Context-Oriented Programming (COP)[8] has been recently proposed to tackle such an issues. COPmakes available language primitives to express context-dependent behaviour (calledbehavioural varia-tion) in a modular fashion. Behavioural variations are chunks ofbehaviour that modify the execution ofa computational system depending on the current working environment. Layers are the linguistic mech-anism that enable the programmer to group variations. Layers can be activated in arbitrary places of thecode with appropriate primitives. Each layer activation has its own scope; activated layers are piled upinto a stack that is calledcontext. Therefore, the actual behaviour of a COP program is carriedout by adispatching procedure that selects the program fragments to be executeddepending on the context.Most of the research efforts in this field are focused on the concrete implementation details and onlya few papers [7, 4] investigated basic foundational issues.We briefly discuss them in Section 3.Our work aims at contributing to the foundations of COP programming languages. We introduce acore calculus (ContextML) with a precise semantic description of the adaptivity constructs.Degano, Ferrari, Galletta and Mezzetti 29To illustrate the novel features of ContextML we resort to a running example. Consider a programembedded in a mobile device, the behaviour of which depends othe active profile of its battery. Weassume that the battery level has two profiles, the power saving mode and the performance one. Theseprofiles are represented at code level as two different layers: PowerSavingModeandPerformanceMode.The functiongetBatteryProfile, described below, queries the sensor (batSensor) and returns thelayer describing the current active profile depending on athreshold value:λgetBatteryProfile()⇒if (batSensor()> threshold) thenPerformanceModeelsePowerSavingModeLayers are expressible values, hence they can be produced asr sults of function calls. The constructwith(e1) in e2 activates the layer obtained evaluatinge1 and delimits its activation scope to the inner ex-pressione2. For instance, in the code below, the layer obtained as result of the callgetBatteryProfile()is active throughout the execution of the inner expression.with(getBatteryProfile()) inPowerSavingMode.doSomeThing(),PerformanceMode.doSomeThingElse()In the inner expression, thelayered expression is defined by cases that specify the context-dependentbehavioural variation considered.Note that if the programmer neglects a case for the profile of the battery, e.g.OnDemandMode, thenthe program throws a run-time error being unable to adapt to the context. We propose to detect theseundesired behaviour by adopting static analysis techniques. To this aim we extend the ML type system inorder to guarantee that well-typed programs are always capable to react to their changing environment,i.e. the dispatching procedure always succeeds at run-time.2 ContextML: a context-oriented ML coreContextML is a purely functional fragment of ML extended with COP primitives. In ContextML thecontext is explicit and is part of the run-time environment.The language is endowed with primitives tomanipulate the context and to specify behavioural variation of expressions, depending on the context inwhich the program is evaluated. The structural operationalsemantics and the type system of ContextMLfollow.Dynamic Semantics Let N be the set of naturals,Ide a set of identifiers,LayerNames a set of layernames, then the syntax of ContextML is defined by the following grammar:n ∈ N x, f ∈ Ide L ∈ LayerNamesv,v1,v′ ::= n | L | λ f x ⇒ ee,e1,e′ ::= v | x | e1e2 | let x = e1 in e2 | e1 op e2 | if e0 then e1 else e2 | with(e1) in e2 | lexplexp ::= L.e | L.e, lexpThe novelties with respect to ML are layers as expressible values; thewith construct for activatinglayers; and the layered expressions (lexp). Recall that a contextC is a stack of active layers. We denotewith L :: C the pushing of layerL onC and with[L1, . . . ,Ln] a context withn elements whose top isL1.30 Typing Context-Dependent Behavioural Variationswith1L :: C ⊢ e → e′C ⊢ with(L) in e → with(L) in e′with2C ⊢ with(L) in v → vwith3C ⊢ e → e′C ⊢ with(e) in e1 → with(e′) in e1lexp∃k.k = min{ j | ∃v.L′j = Lv}∧L′k = Li[L′1, . . . ,L′m] ⊢ L1.e1, . . . ,Ln.en → eiFigure 1: ContextML semantics.The semantics is only defined for closed expression and is chara terised by judgements having theform C ⊢ e → e′ meaning that in contextC the closed expressione reduces toe′ in one evaluationstep. In Figure 1 we only show the semantic rules (with1),(with2),(with3),(lexp) that deal with the newconstructs, the others are inherited from the standard ML. We briefly comment on the new ones only.Rules forwith(e1) in e2 evaluatee2 in the context extended by the layer obtained evaluatinge1. When alayered expressionL1.e1, . . . ,Ln.en has to be evaluated (rulexp), the context of evaluation is inspectedtop-down (dispatch mechanism). When a layer in the context matches one of theLi, the correspondingexpressionei is evaluated. If no layer matches then the computation gets stuck.Type system We introduce a monomorphic type system for ContextML which ensures that the dispatchmechanism always succeeds at run-time for well-typed expressions.Our type system is characterised by typing judgements of theform 〈Γ;C〉 ⊢ e : τ . This means that in“in the type environmentΓ and in the contextC expressione has typeτ”.Types are integers, layers and functions.τ ,τ1,τ ′ ::= int | lyφ | τ1ψ−→ τ2 φ ,ψ ∈℘(LayerNames)We annotate types with sets of layer namesφ ,ψ for analysis reason. Inlyφ , φ over-approximates thelayers that an expression can be reduced to at run-time. Inτ1ψ−→ τ2, ψ over-approximates the layers thatmust be active in the context during the application of the function (precondition of the function).Back to our example, the type of the functiongetBatteryProfile will be the following:unit/0−→ ly{PowerSavingMode,PerformanceMode}.The intuition is that the function returns a layer in the set{PowerSavingMode,PerformanceMode}.The function has no preconditions, i.e. it can be applied in any context.Our typing rules are in Figure 2. Since types are annotated, the type system contains rules dealingwith the subtyping. The rules (Sint), (Sly), (Sfun) have judgements of the formτ1 ≤ τ2 (τ1 is a subtypeof τ2). Furthermore, we assume that annotations are ordered by set-inclusion and that|C| is the set ofactive layers in a contextC.By rule (Sly) a layer typetyφ is a subtypetyφ ′ if and only if the annotationφ is a subset ofφ ′. Rule(Sfun) is subtyping rule for functional types. As usualτ1ψ−→ τ2 is contravariant inτ1 but covariant inφandτ2.Rule (Tly) asserts that the type of a layerL is ly annotated with the singleton set{L}. In rule (Tfun)we guess a type for the bound variable, for the functionf and determine the type of the body under theseadditional assumptions and in a guessed contextC′. Implicitly, we require that the guess of a type forfmatches that of the resulting function. Additionally we require that the resulting type is annotated with aprecondition that includes the layers inC′.Degano, Ferrari, Galletta and Mezzetti 31(Sint)int ≤ int(Sly)φ ⊆ φ ′lyφ ≤ lyφ ′(Sfun)τ ′1 ≤ τ1 τ2 ≤ τ ′2 ψ ⊆ ψ ′τ1ψ−→ τ2 ≤ τ ′1ψ ′−→ τ ′2(Tint)〈Γ;C〉 ⊢ n : int(Tly)〈Γ;C〉 ⊢ L : ly{L}(Tsub)〈Γ;C〉 ⊢ e : τ ′ τ ′ ≤ τ〈Γ;C〉 ⊢ e : τ(TVar)Γ(x) = τ if x ∈ dom(Γ)〈Γ;C〉 ⊢ x : τ(Tfun)〈Γ,x : τ1, f : τ1|C′|−−→ τ2;C′〉 ⊢ e : τ2〈Γ;C〉 ⊢ λ f x ⇒ e : τ1|C′|−−→ τ2(Top)〈Γ;C〉 ⊢ e1 : int 〈Γ;C〉 ⊢ e2 : int〈Γ;C〉 ⊢ e1 op e2 : int(Tlet)〈Γ;C〉 ⊢ e1 : τ1 〈Γ,x : τ1,C〉 ⊢ e2 : τ2〈Γ;C〉 ⊢ let x = e1 in e2 : τ2(Tif)〈Γ;C〉 ⊢ e0 : int 〈Γ;C〉 ⊢ e1 : τ 〈Γ;C〉 ⊢ e2 : τ〈Γ;C〉 ⊢ if e0 then e1 else e2 : τ(Twith)〈Γ;C〉 ⊢: e1 : lyφ ∀L′ ∈ φ .〈Γ;L′ :: C〉 ⊢ e2 : τ〈Γ;C〉 ⊢ with(e1) in e2 : τ(Tlexp)∀i.〈Γ;C〉 ⊢ ei : τ L1 ∈ |C| ∨ · · ·∨Ln ∈ |C|〈Γ;C〉 ⊢ L1.e1, . . . ,Ln.en : τ(Tapp)〈Γ;C〉 ⊢ e1 : τ1φ−→ τ2 〈Γ;C〉 ⊢ e2 : τ1 φ ⊆ |C|〈Γ;C〉 ⊢ e1e2 : τ2Figure 2: ContextML type systemRule (Twith) establishes that an expressionwith has typeτ , provided the type fore1 is lyφ (recallthat φ is a set of layers) ande2 has typeτ in the contextC extended by the layers inφ . By (Tlexp)the type of a layered expression isτ , provided that each sub-expressionei has typeτ and that at leastone among the layersL1, . . .Ln is active in the contextC. This requirement is the key to ensure that thedispatch mechanism always succeeds at run-time. Notably, when evaluating a layered expression one ofthe mentioned layers will be active in the current context.Back to our example, the expression provided is well-typed as witnessed in Figure 3. The type ofgetBatteryProfile ensures that one of the two layersPowerSavingMode or PerformanceMode isreturned. One among them is required to be active so to evaluate the layered expression. Hence, the(Twith) rule can guarantee that the whole expression is never stuck at run-time.Rule (Tapp) is almost standard and reveals the mechanism of function precondition. The applicationgets a type if only if the layers in the preconditionφ are active in the current contextC. To better explainhow preconditions work, consider the example in Figure 4. There the functionλ f x ⇒ L1.0 is shownhaving typeint{L1}−−→ int. This means thatL1 must be active in the context of activation of the function.The remaining rules are standard and we do not comment on themfor brevity.Our type system guarantees not only that functional types arcorrectly used, but also that the eval-uation of a layered expression never gets stuck. The following lemmata prove that our type system issound with respect to the operational semantics:32 Typing Context-Dependent Behavioural Variations〈Γ;C〉 ⊢: getBatteryProfile() : lyφ(Tlexp)〈Γ;C′〉 ⊢ doSomeThing() : τ 〈Γ;C′〉 ⊢ doSomeThingElse() : τPowerSavingMode ∈ |C′|∨PerformanceMode ∈ |C′|〈Γ;C′〉 ⊢ PowerSavingMode.doSomeThing(),PerformanceMode.doSomeThingElse(): τ (Tlexp) · · ·〈Γ;C′′〉 ⊢ . . .〈Γ;C〉 ⊢ with(getBatteryProfile()) in PowerSavingMode.doSomeThing(),PerformanceMode.doSomeThingElse(): τFigure 3: The typing derivation of the running example. We assumedoSomeThing,doSomeThingElse :unit → τ. We denoteφ = {PowerSavingMode,PerformanceMode};C′ = PowerSavingMode :: C;C′′ =PerformanceMode :: C. The last rule used is (Twith).〈Γ,x : τ, f : τ → τ;C′〉 ⊢ 0 : τ L1 ∈C′〈Γ,x : τ, f : τ|C′|−−→ τ;C′〉 ⊢ L1.0 : τ〈Γ;C〉 ⊢ λ f x ⇒ L1.0 : τ|C′|−−→ τ〈Γ,g : τ|C′|−−→ τ;C〉 ⊢ g : τ → τ〈Γ,g : τ|C′|−−→ τ;C〉 ⊢ 3 : τ |C′| ⊆ |C|〈Γ,g : τ|C′|−−→ τ;C〉 ⊢ g3 : τ〈Γ;C〉 ⊢ let g = λ f x ⇒ L1.0 in g3 : τFigure 4: Derivation of a function with precondition. We assume thatC′ = [L1], L1 is active inC and, fortypesetting convenience, we also denoteτ = int.Lemma 2.1 (Progress). Let e be a closed expression such that for some C 〈Γ;C〉 ⊢ e : τ . Then either e isa value or C ⊢ e → e′.Lemma 2.2 (Subject reduction). Let e be a closed expression, if 〈Γ;C〉 ⊢ e : τ and C ⊢ e → e′ then〈Γ,C〉 ⊢ e′ : τ3 DiscussionRelated work Several COP programming languages have been proposed (see e.g.ContextL [5] andContextJ [1]). Usually COP features are introduced within the objectoriented paradigm so providingbehavioural variations at object level.Most of the research efforts have mainly tackled implementation issues. To the best of our knowledgeonly few papers provide a precise semantic description.In [7] an extension ofFeatherweight Java [10] has been proposed. This calculus includeslayers(de)activation, but layers are not expressible values. Furthermore, a static type system ensures that thereexists a binding for each dispatched method call. This fact is based on the strong assumption that layersdo not introduce new methods but only refine existent ones. Our type system relaxes this assumption.Our approach is much similar to the one of Clarke et al. [4] andthe main difference is that we considera functional language while [4] considers an object oriented language, Featherweight Java.Conclusions and further work We started investigating the foundational issues of the COPparadigmwith a calculus endowing COP primitives. We have defined a dynamic semantics that formalises theoperational mechanisms behind these constructs. A distinguished element of our semantics is the dis-patching procedure, that selects the behavioural variation depending on the active context. We have alsospecified a type system guaranteeing that the dispatching mechanism always succeeds at run-time forwell-typed expressions.In our current proposals, activation of layers is driven according to the flow of program execution. Amore general approach would instead consider the asynchronous evolution of the environment. We planDegano, Ferrari, Galletta and Mezzetti 33to investigate this issue and to formalise event-driven changes of context.We also intend to refine the type system by introducing effects to represent an over-approximation ofthe evolution pattern of context shape. In doing that, techniques similar to session-types [9] might suggestus useful mechanisms. Types and effects will enhance our static analysis of programs, following the linesof [2, 3]. In particular we would like to accept or reject progams at compile time, also depending onnon-functional requirements on the context evolution, e.g. when security policies are to be enforced uponcontext usages (for a recent proposal see [6]).Acknowledgement The authors would like to thank the anonymous referees for thei comments thatpointed us an inaccuracy, and guided us to improve the quality of our paper.This work has been partially supported by IST-FP7-FET open-IP project ASCENS and RegioneAutonoma Sardegna, L.R. 7/2007, project TESLA.References[1] M. Appeltauer, R. Hirschfeld, M. Haupt & H. Masuhara (2011): ContextJ: Context-oriented Programmingwith Java. Computer Software28(1).[2] Massimo Bartoletti, Pierpaolo Degano & Gian-Luigi Ferrari (2009):Planning and verifying service compo-sition. Journal of Computer Security17(5), pp. 799–837, doi:10.3233/JCS-2009-0357.[3] Massimo Bartoletti, Pierpaolo Degano, Gian Luigi Ferrari & Roberto Zunino (2009):Local policies forresource usage analysis. ACM Trans. Program. Lang. Syst.31(6), doi:10.1145/1552309.1552313.[4] Dave Clarke & Ilya Sergey (2009):A semantics for context-oriented programming with layers. In: Interna-tional Workshop on Context-Oriented Programming, COP ’09, ACM, New York, NY, USA, pp. 10:1–10:6,doi:10.1145/1562112.1562122.[5] Pascal Costanza (2005):Language constructs for context-oriented programming. In: In Proceedings of theDynamic Languages Symposium, ACM Press, pp. 1–10, doi:10.1145/1146841.1146842.[6] Pierpaolo Degano, Gian-Luigi Ferrari, Letterio Galletta & Gianluca Mezzetti (2012):Typing for coordinatingSecure Behavioural Variations. In: Coordination Models and Languages, Lecture Notes in Computer Science7274, Springer, pp. 261 – 276, doi:10.1007/978-3-642-30829-1_18.[7] R. Hirschfeld, A. Igarashi & H. Masuhara (2011):ContextFJ: a minimal core calculus for context-orientedprogramming. In: Proceedings of the 10th international workshop on Foundations of aspect-oriented lan-guages, ACM, pp. 19–23, doi:10.1145/1960510.1960515.[8] Robert Hirschfeld, Pascal Costanza & Oscar Nierstrasz (2008):Context-Oriented Programming. Journal ofObject Technology, March-April 2008, ETH Zurich7(3), pp. 125–151, doi:10.5381/jot.2008.7.3.a4.[9] Kohei Honda, Vasco Thudichum Vasconcelos & Makoto Kubo (1998):Language Primitives and Type Dis-cipline for Structured Communication-Based Programming. In: Proceedings of the 7th European Sympo-sium on Programming: Programming Languages and Systems, Springer-Verlag, London, UK, pp. 122–138,doi:10.1007/BFb0053567.[10] Atsushi Igarashi, Benjamin C. Pierce & Philip Wadler (2001):Featherweight Java: a minimal core calculusfor Java and GJ. ACM Trans. Program. Lang. Syst.23, pp. 396–450, doi:10.1145/503502.503505.

Typing context-dependent behavioural variations

http://doaj.org/search?source=%7B%22query%22%3A%7B%22bool%22%3A%7B%22must%22%3A%5B%7B%22term%22%3A%7B%22id%22%3A%22e26838dd01f0430785bd104160891418%22%7D%7D%5D%7D%7D%7D

Typing Context-Dependent Behavioural Variation

Abstract

Similar works

Full text

Available Versions

Crossref

Archivio della ricerca della Scuola IMT Alti Studi Lucca

Directory of Open Access Journals

Archivio della ricerca della Scuola IMT Alti Studi Lucca