CAL: A Language for Aggregating Functional and Extrafunctional Constraints in Streaming Networks

CAL: A Language for Aggregating Functiona l and Extrafunc tional Constrai nts in Strea ming Networks ∗ Alex Shaf arenko, Raimund Kirner Department of Computer Science Univ ersity of Hertfordshire College Lane, Hatfie ld AL10 9AB United Kingdom {r .kirner , a.shafa renko}@herts.ac.uk November 21, 2018 Abstract In this article we present the Constraint Aggre gatio n Language (CAL), a declarative lang uage for describing prope rties of stateless pro gram com - ponen ts th at inte ract b y exchanging m essages. CAL allows o ne to describe function al as well as e xtra- function al behaviours, such as computation la- tency . The CAL language intention is to be able to describe the behaviour of so-called boxes in the co ntext o f S- Net. Howe ver , th e langu age would find application in other coordina tion models based on stateless compon ents. 1 Introd uction The concept of coordinatio n engendere d by the coordinati on language S-Net en- forces a strict separation of concerns [ 3 – 5 ]. T he program is represente d as a stream- ing network in which the nodes are specified as stateless black bo xes defined by their interfa ces. An i nterfa ce definitio n decla res the type of tup les th e bo x agr ees to recei ve. It names indi vidua l fields without defining the kind of content (e.g., num- bers, arrays, etc.) that those are expec ted to represent. The interface also defines the output tuples the box is permitted to produce , in exactly the same manner: as lists of field names. A b ox beha ves a s follows: it i s initialised, the n an input tu ple i s consu med, then output tuples (also called messages), if any , are produced in some order and the n the box ter minates. No input is possible other than via the input ∗ The research l eading to these results has received funding from the IST F P-7 research project "Asynchron ous and Dynamic V irtualization through perfo rmance ANalysis to su pport Concu rrency Engineering (AD V ANCE)" under con tract no IST -2010-248828. tuple an d no stat e of th e box co mputation is s hared with i ts en vironment other th an by produc ing output tuples. In this report we present the Constrai nt Aggr e gation Langua ge (CAL), which is a lan guage for specifyi ng constraint s about the program behav iour of bo xes. The CAL in terface defini tion for box es is p resented in the form of signature. Here i s an exa mple: box boxna me ((a ,b,n) -> (d,e), (f,g,q,r), ... ): This box tak es as i nput a tuple (a,b,n) and pro duces tup les of the types ( d,e) , (f,g, q,r) , . . . . Any propert ies of the objects co mmunicated in and out of a box are con sid- ered dynamic and unkno wn to the coordin ating infrastru cture. In reality , so me of them may be static albeit defined in terms of a box languag e and thus una v ailable to S-Net. The properties are classified into two lar ge cat egorie s: functi onal and ext rafunction al. Functional properties are concerne d with the value of the object: its shape (e.g., array dimensio ns), e lement type, and conten t. The extrafu nctional proper ties in clude, b ut are not limited to, computatio nal late ncy of output tuples, electri c power required for their producti on, the amount of auxiliary memory that the algori thm n eeds, etc. Generally , extrafun ctional p roperties are those not af- fecting the v alue of the res ult tuples, b ut only the ef ficienc y and “cost” of their produ ction. The purpose of CAL is to enable the progra mmer to declare cause-a nd-ef fect relatio ns between the inpu t and output and to define constraint s on the se. It is typica lly the case that fu nctional pr operties in fluence th e e xtrafu nctional ones, e.g.: the length N of a 1d array affe cts the time required to sort it in a giv en order and the size of the auxiliary memory required for the sorting. It is also true that w hile ext rafunction al properties are loca l and tend to be independ ent from each other , functi onal propertie s hav e the tenden cy to spread out as m essage s are sent and recei ved across a distrib uted system. 2 The Constraint Aggregation Language (CAL) The constr aint ag gr e gation langua ge (CAL) describes prop erties of S-Net and box es and boxe s that share the S-Net interf ace conce pt. The modular unit of CAL is called a declaration . A CAL declara tion ap plies to a specific box and is based on the bo x signa ture. The top-le vel gra mmar of C AL is giv en in Figure 1 . The declar ation c onsists of clauses. A clause is the statement that the input conditio n implies the output co ndition. The input c ondition of a bo x is the co njunction of predic ates on terms that include o bject vari ables that ref er to the b ox input. The outpu t assertion of a box is the conjunctio n of predicates on terms that include object v ariables that ref er to t he box output. Both kin ds of terms may incl ude en vi- ronment v ariables that refer to the state of the en vironment or the effec t of the box on the en vironment. The term structure is giv en in figure 2 . 2 Declar ation ⇒ Header [ Decl ; ] * Header ⇒ box BoxName ( BoxSignatur e ) : BoxSigna tur e ⇒ [ T upleT yp e ] -> [ T upleT ype [ , Tu pleT yp e ] * ] T upleT yp e ⇒ ( [ Object [ , Object ] * ] ) Decl ⇒ [ Clause ] | provided C onds use Decl end Clause ⇒ Cond => Assert Cond ⇒ Predicate [ , Predicate ] * Assert ⇒ Predicate [ , Predicate ] * Figure 1: T op-Le vel Grammar of CAL 2.1 V ariables and T erms A v ariable is le xically a sequence of letters, underscores and di gits precede d by one or two do llar signs, with the first charact er after the dollar(s) being a letter or undescore . A vari able can be associat ed with a value . There are two types of v alues: a number and a term, the former being disting uished from the latter lex ically . A varia ble may not be assoc iated with anythi ng; in that case it is ca lled a fr ee varia ble. A ll free v ariables are exist entially quantified by CAL. Three cate gories of variab les are av ailable to a CAL clause . 1. Object variab les. They are le xically identical to the members of the tuple type in the header except that they are preceded by the dollar sign. Each of these v ariabl es is asso ciated with a term that reflects the prope rties of the corres ponding data object. M ore precise ly , the objects on the left-hand side of the signature are assumed to be pre-ass ociated with the property expres- sions, and those on the righ-han d side will hav e properti es asserte d by the out-co ndition, but oth erwise all object va riables behav e in the same way . 2. En viron ment v ariabl es, for exampl e $$ nthr eads , the number of th reads a vai lable to the box . They are a ssociated by the en viron ment with v alues accord ing to the m eaning . They are lexica lly differe ntiated from the object v ariables by the double dollar prefix. Note that en vironmen t varia bles hav e v alues at run-time, which may change from one activ ation of the box to the nex t, just as objec t vari ables. 3. The rest of the va riables are local ; they are free and therefore exist entially quanti fied. T heir purpose is to faci litate specificati on of comp lex con ditions. There exist a special varia ble $ _ , which denotes a fresh local var iable with a compiler -generated name. It c an be associated with a valu e via unification b ut cannot be referred to by name to fetch that va lue, a kind of unification “black hole”. 3 T erm ⇒ Evalu able | Gener al Evaluabl e ⇒ Basic | EvT uple | EvHeadT uple Basic ⇒ V ariable | Constan t | Symbol EvT uple ⇒ ( Evalu able [ , E v aluable ] * ) EvHeadT uple ⇒ Symbol EvT uple Infix-Exp ⇒ Prod | add-o p Pr od | Infix-Exp add -op Pr od Pr od ⇒ Basic | Pr od times-op Primary | Pr od ˆ Primary Primary ⇒ Basic | ( Infix-Exp ) add-o p ⇒ + | - times-op ⇒ * | / Gener al ⇒ Evalu able | Set Set ⇒ { Evalu able [ , E v aluable ] * } | V ariab le | Set ∨ Set Figure 2: T erm structure in CAL 4 Pr edicate ⇒ [ Relati on | E qui v alence ] Relation ⇒ [ V aria ble | Constant ] RelOp Expr RelOp ⇒ [ = | > | < | >= | <= | != ] Equivale nce ⇒ Expr :=: Expr Figure 3: Predicates in CAL T erms are composed from the basic terms, which are variab les, numbers and symbols , using a fe w constr uctors. N umbers are r ational numbers in the form n/d where both the numerator and the denominato r are unsigned intege rs. n/ 1 can be abbre viated to n and an optional minus may precede any number . The va riety of symbols includ es id entifiers and infix signs. Identifiers are, as usual, composed of letters, nu mbers and underscor es, and the infix signs include +, -, * , /, ^, \/ . Infix signs are treated as syntacti c sugar for special in- dentifiers \plus , \m inus , \times , \s lash , \hat , \union , which start w ith a bac kslash (otherwise not a va ilable to the pro grammer), but which a re, otherwis e, similar to ordi nary identifiers. T wo constr uctors are used for term constructio n: set and tuple. A set is a comma-sep arated li st enclosed in braces , for exa mple: {$A, 12, shape } . S ets contai n m embers, which a re general terms e xcept an y kind of s et nesti ng is forb id- den. Unions of sets are allo wed, and a v ariable may range ov er sets, ev en though that is not a type judgemen t and is not enforced by the compiler . Ill-formed sets, which contain sets as members or w hich are united with members rather than sets cause the predi cate that uses such a set to fail. A tuple is a comma-separat ed list en closed in parenthe sis. A s a sy ntactic su gar , the fi rst member of a tuple, provid ed th at it is a symbol, c an be extracte d fro m it and placed in front of the ope ning parenthesis . The r esulting term is fu lly equi val ent to the orig inal one, for exampl e, a(b,c ) is ef fecti vel y equiv alent to (a,b ,c) . Infix s igns implicitly cau se tupling. Any term in th e form e1 ⊕ e2 , where e1,e2 are terms and ⊕ is an infix sign, is con ver ted by the CAL compiler to ⊕ ( e1 , e2 ) . Any ambiguity res ulting fro m more than one infix sign binding the same term is resolv ed on the basis of priority in a con ve ntional way . CAL varia bles hav e no explicit type, but terms do. Since set nesting is forbid- den, the re are tw o m utually incoercible term types: a set and an indi vidual. A n indi vidua l can be a number , a symbol or a tuple. 2.2 Pred icates T erms in CAL are used in formulating conditi ons and assertions , which are con- juncti ons of pr edicate s . Those hav e the grammar displ ayed in Fig 3 . There a re two syntac tic classes of predicat e: relat ions and equi va lences. 5 Relations. Those compare a variab le (or a consta nt) w ith a term on the basis of numerica l v alue. The term on the right hand sid e is ev aluated in the arithmetic sense as follo w s • O nly tuples ar e allowed ; sets are forbidden ; if a set construc tor is encoun - tered, the predic ate fails. • T he top lev el of the term structure is thus a basic term or a tuple; If the former , – if the basic term is a constant, the constant va lue becomes the valu e of the term – if the basic term is a symbol, it is one of the Standard C onstan ts (e x- amples are: maximum integer , infinity , etc), otherwise the predicate fail s – if the basic term is a variab le, the va riable must be associa ted with an e val uable term, otherwise the pre dicate f ails; if it succeeds , then that term’ s numerical valu e becomes the v alue of the va riable. If the top le vel of the term structure is a tuple, the tuple head is interprete d as the identifier of a numerical function, such as \plu s ; the rest of the members of the tuple are consi dered the ar guments and ar e e va luated; the functi on is applied to the valu es of its argu ments and the result becomes the v alue of the term. If the identifier of the function is unkno w n, the predicate fail s, as it does in the e vent of any of the ar guments f ailing. Note that the tuple head cannot be a v ariable 1 . Note that since all free varia bles are existe ntially quantified, the clause will ef fec- ti vely define a cons traint in v olving ev ery free vari able participa ting in it. Equival ence is an application of the most genera l unifier to the two terms. The unifier su cceeds if ther e exist unifying assoc iations for all fr ee v ariables part ici- pating in the terms. If it succeeds, the associ ations will be the most genera l ones possib le, and they may in v olve furt her free v ariable s generated by th e compiler . The unificati on rules are completely symmetrical with respect to both operands : • A t the top lev el ground terms, tuples and sets are all possible . T uples and sets are mutually un-unifiable , unles s the tuple head is \uni on . U nion- headed tuples are consid ered sets in the context of unification . It is checke d that terms under a union are (syntactical ly) sets. That ex cludes, as members of a union, terms such as a tuple hea ded by anythin g other than \ union , consta nts and symbo ls, bu t it does not e xclude v ariables, as t hose ca n, and i n this case must, be associate d w ith sets , bu t that is not a syntacti c restrictio n. 1 This restriction is required for the tractability of numerical express ions. 6 • Sets are unified by assigning the free v ariables occurring in them with most genera l terms (i.e. constraini ng the m) that make the two sets identica l. By the m ost general assign ment w e mean an assignme nt such that any other unifyi ng assignmen t can be produce d from it by furthe r constra ining any free varia bles that remain after the unification . When sets ar e unified, the most gene ral form of set term is, obviou sly , { t 1 , t 2 , . . . , t n } ∨ v 1 ∨ v 2 ∨ . . . ∨ v q , where t 1 , t 2 , . . . , t n are (non-set) terms, i.e. basic terms or tuples of tuples and/or basic terms, and v 1 , v 2 , . . . , v q are v ariables rangin g over sets (since sets and indi viduals are mutually incoercib le) 2 • A n on-v ariable basic term can on ly be u nified with an iden tical basic t erm or a v ariable. • An un-asso ciated v ariable becomes associat ed with the other operand ; if the v ariable is asso ciated, the other ope rand is unified with the associate d terms. 2.3 A note on logic/constraint pr ogramming machinery It is easy to see that the presen t synta x of CAL clauses makes them reducibl e to Horn clauses. Indeed, due to the static nature of S -Net routing, the assertion s can be matche d with conditio ns using the type-infe rred version of the S-Net graph. As a result, aft er a suitab le (full y mechani cal) tran sformation, a single unstructure d set of CA L clauses can be gleaned from the whole network . The only de viation from the stan dard Horn format: P 1 ∨ ¯ P 2 ∨ ¯ P 3 . . . is the conju ncti ve head made up from all assertio ns A 1 , A 2 , etc. in the clause ( A 1 ∧ A 2 ∧ A 3 . . . ) ∨ ¯ C 1 ∨ ¯ C 2 . . . , with the conditio ns C 1 , C 2 , etc. partici pating in the disjunction. Howe ver , this is equi valent to a set of Horn clauses: A 1 ∨ ¯ P 1 ∨ ¯ P 2 . . . A 2 ∨ ¯ P 1 ∨ ¯ P 2 . . . A 3 ∨ ¯ P 1 ∨ ¯ P 2 . . . . . . The ce ntral issue there fore is whether or not the ass ertions require a di sjuncti ve form, which would make CAL clauses non-Horn. T he present syntax exclu des it 2 Unification of such terms is kno wn as the flat ( q ) unification problem [ 1 ] and it is the most complex se t unification problem that admits a po lynomial complexity solution . It is kno wn that e ven the solution to a system of flat ( q ) unificati on equations, as opposed to a single equation, is already NP-complete, to say nothing o f a more comple x set algebra. This ex plains ou r choice of set operators av ai lable in CAL. 7 in anticipatio n th at the input information should be suffici ent to assert constra ints (ho wev er loosely) on a definite collection of terms, each member of the collection thus being c onstraine d conjuncti vely . It may be the case, ho wev er , that an input to a box produces, for instan ce, two possible output messages ; then depend ing on which message is produced , a di ffer ent con straint is asserted on the same ob ject v ariable. Such situatio ns would necessitate a disjun cti ve assertion, for which the curren t CAL syntax is insuf ficient. Thought s should be gi ven to non-Horn CSPs, in our case SMT modulo linear arithmeti c, which would in volv e a solve r such as Y ices [ 2 ] as a means of aggrega - tion. 2.4 Aggregation and V ocab ularies The idea behind constraint specificat ion of CAL is that both functio nal and extra- functi onal co nstraints can be express ed as relation s on terms. The diff erence be- tween them is in the aggre gation method. For fun ctional constrai nts terms are uni- fied acc ording to the corres ponding box connectio ns. For instanc e, two box es con- nected in series: A..B with the signatures, r especti vely , (x)->(y) and (p) ->(q) would impel CAL to unify object variab les y and p , which will ef fecti vely trans- form any assertion s on y into conditio ns on p . All kinds of connection s between box es will be type-res olved by the coordina tion language compiler to estab lish the interf ace type; then CA L will unify corresp onding object variab les. N aturall y , due to the prese nce of arithmetic relation s in CAL clauses, the connec tion between the input and the output of a box might be quite complex and the corresp onding ag- gre gation might in volv e heuristicall y dri ven symbolic computati ons, but such sce- narios are exp ected to be uncommon. At any rate, if constraint s fail to aggreg ate, this lea ves the whole-sy stem constra int only set less t ight, but s till sound. W arning messages could be generated for the benefit of the system designer in such a case, and impro vements could inclu de redesign of some box es in order to expos e es- sentia l parameters in a more straigh tforward fash ion in data before any properties and property associat ions may be formulated. For instance , instead of defining a comple x relation between input and output shapes, a box could compute an extra inte ger paramet er that define s the ou tput shap es directly . The o utput con straints would thus become disconne cted from the input constr aints, but the former could then be declared precisely and simply . It is clear from this exampl e that there may well be a trade-of f between aggre gability and accurac y gi ven a limited amount of deduc tiv e power in the con straint aggregati on logic. In contrast to function al constraint aggre gation, the extrafu nctional constrain ts are aggre gated by means other than unificatio n. Unification can still play a role if aggre gation rules are formulated in inference- rule form, but that is an implemen- tation issue. What is certain in any implementatio n is that the aggreg ate constra int set is produced from the assertions of indi vidual boxe s by non-logica l means. For exa mple, aggr egatin g laten cy ov er a pipelin e in v olv es not only the knowledg e o f latenc y prope rties of the pipe line stage s, bu t also the communication cost of th e 8 pipeli ne itself, an d al l tho se are combined st atisticall y as pro bability dis trib ution functi os w ith tuneable parameters. The machinery that should be used here is one of queuing theory; also in v olved in these calculatio ns are the virtual hard- ware model and variou s system parameters. A t this point it is en visaged that any compone nt-wise information about late ncy is fe d into a special aggre gation library that contai ns an aggregat ing function for eve ry network combinato r per extra func- tional prope rty to be aggre gated. It is important to understand that here virtual hardw are plays a dual role: it provid es an ex ecution platform and also some sym- bolic rules that describe the process of statistic al aggre gation relev ant to that plat- form. For exampl e, the abo ve mentioned pip eline exa mple A..B would exhibit dif ferent temporal behav iours (ev en statisti cally) if the nature of the serial combi- nator is networ k communication between processors rather than shared memory for c ores. T his d iffe rence may be qu alitati ve rather tha n quantita tiv e: in the former case the message size negati vely impa cts on the co mbinator la tency while in the latter it may not. By contras t, the combin ator jitter may beh av e in the opp osite manner: communica tion tends to reduce jitter due to b uffer ing while direc t sharing exa cerbates it by allowin g the box jitters to combine. In both functi onal and extr afunction al cases the recursi ve structure of the net- work w ould call for a reflexi ve aggre gation techniqu e: sub networks should exp ose the same nature collections of symbolic expre ssions as boxes, and the aggreg ation proces s should not care whether what is being aggregat ed is atomic or not. There are two ways of achie ving this. One is to see CAL as a packag e operati ng on top of a generic inferen ce system, such as P rolog, or e ven an appropria te SMT solver such as Y ices. This would enable the dev elopmen t of all aggre gation code in that frame work. The secon d alternati ve is to use CAL sp ecifications as source data to a custom analysis tool, which is hardwired for all forms of aggre gation. The choice remains open at prese nt time. Either form of aggre gation requires a definition of the property terms with which the ag gregat ion proces s must deal. CAL terms are generally tuples or sets of tuples , and those in v olve consta nts and identifiers . T he latter m ust carry m eaning for each indi vidual property class. T he structure of the terms and the assortment and meaning of the identifiers used in them form the substan ce of a vocab ulary definit ion for a property . V ocab ularies for extr afunction al properties are external to CAL and should be defined as part of the contract between the statistica l model, coordi nation infrastruc ture and virtual hardware. The last one has its own v ocab u- lary that defines the system parameters repeatedly mentioned abov e. V ocab ularies for functional properti es are also exter nal to CAL , and are part of a contract, too. Ho wev er , the contract is no w between modules written in a box language. Constrai nt aggreg ation may deli ver informatio n to each of the modules that standa rd type systems are unable to guarantee and, because of that, fail to gather . CAL prope rties can be used to tune the back end of the compiler for program specia lisation, either statically or using just-in- time compilation techni ques, if the CAL process is u se dynamically , trigger ed by a c hange of value for an en viro nment v ariable. This would enable quasistati c properti es, i.e. properties that are dynamic 9 b ut w hich change infrequen tly , to be treated as configuratio n para meters, and the compilat ion proc ess as one of reconfigu ration under the influence of nonlocal infor - mation. In c ontrast to types , failure to gath er the necessary information would only delay or cancel such reconfiguratio n but not jeopardi se the v alidity of code, hence more liberal aggre gation methods, includin g heurist ic and constr aint-satis faction modulo generall y undecida ble theorie s could be tried. V ocab ulary-wise, the v ocab- ulary for the function al propert ies will closel y reflect (but not necessar ily coinci de with, up to isomorphis m) the type system of the box language. The clauses would analys e the propertie s and synthesi se assertions that link up types. Importan tly , type s can be depend ent on inte gers communicat ed at run time, since those can be aggreg ated and constrained by the CAL inference machinery . As a side eff ect of the aggre gation, certain en vironmen t varia bles may recei ve as- sertion s, and those can be used by the box -languag e compiler in its conditi onal compilat ion facilitie s, such as C’ s #defi ne . This wo uld require a con venti on on such en vironment-v ariables’ names, for instanc e they could start with $$_ . It would also require a template for the #define -like statements fo r th e bo x lan- guage into which the v ariables will be substituted before box (re-)co mpilation. In- teresti ngly , this approach erodes the bounda ry between the static and the dynamic in box compilatio n. Belo w we will present some example v ocab ularies. The exampl es are mean t to be illustra tiv e rather than definiti ve and are not prescrip tiv e in any way . 2.4.1 Functional V ocabular y It would be s ensible to ensure that any object v ariable is associated w ith a set of terms. This way speci fic properties can be expresse d as one or more terms and the input co ndition can ex tract speci fic terms by s et unification , while no t caring abo ut what other term structur es may be present in the set. The functio nal v ocab ulary in a simple Fortran-l ike programming language with arrays may includ e the follo wing term: T y pe(arra y, element($eltype), rank($r), shape($s0,($s1,($s2,nil))) ) Here the term head Ty pe indicates that the term defines the object’ s type. Symbol arr ay indicates that the type is an array type. The eleme nt subterm defines the element ty pe of the arr ay as $e ltype , the ra nk subterm define s th e rank of the array as $ r and the shape list is contained in the term sh ape . N ote that the elemen t type can be a sy mbol that serves as a reference to another type declar ation. For example, the following pair of terms define a vecto r of vect ors of inte gers, the inner ve ctor being of v ariable length: 10 T y pe(this, eleme nt(vector), rank(1), shape(100,nil) ) type(vector, el ement(int), rank(1), shape(unknown, nil ) ) The se cond term uses the tuple head type rath er than Type to in dicate an additi onal type definition. Also note the symbol for unkno wn integ er number unkno wn . T he ac tion of arithmetic opera tors in rela tional conte xts is e xtended to inclu de the standard response to unkno w n numbers 3 . It should be clear by now that, for instanc e, all non-po inter C types can be en- coded as CA L terms. Records and union s ca n be dealt with by using tuples of label- type pairs, both labels and types represente d by CAL symbol s. S elf-refe rencing types are possible by reusing the type name symbol (second member of the type tuple at t he top lev el) in th e component terms of the ty pe. Here is a li st of inte gers: T y pe(int_list, union( record((head, int),tail(in t_list)), nil ) ) Another kind of functional constraint that CAL may deal with is a constrai nt associ ated with a valu e. V alues of compoun d objects are box-lan guage dependent and conseque ntly intracta ble in CAL , but intege r scalars should be quite tractable and do usually carry important informatio n that af fects functional propertie s of object s (such as their dimensions ). T o this end, the term val ue($v ) should be includ ed in the v ocab ulary , where $v is a n intege r constant. Here is an ex ample of full terms asso ciated with an input interf ace of ( A,K)- > ... $A :=: {T ype(array, element(real), rank(2), shape(7,(7,nil)) ), pack ed(row_major)} $K :=: {T ype(int), value(100)} Here the first line associat es a term that declares a real 7 × 7 array packed in a ro w major order , and the second line a term that declares the integ er scalar 100 . 2.4.2 Extrafunctio nal V ocabulary : Latency The latenc y v ocab ulary describes the st atistical m odel of message production by a box. The en viro nment provides a series of v ariables in its v ocabu lary: $$T0 , $$T1 , $$T2 , etc. These v ariables are provid ed separately fo r each box, just as all other double -dollared v ariables. T hey are part of the en vironme nt inpu t; con- sequen tly they are unassoc iated. Their number correspon ds to the number of type 3 details to follow 11 alterna tiv es on the right hand side of the box type signatu re. For e very output type τ n , the v ariable $$ T n shou ld be unified with the time-comp lexity model of the corres ponding output, for example, the asser tion $$T0 :=: $N * log($N) will tell the en vironment that the time complexity of produ cing one output of the fi rst output type is N log N , where N is a local v ariable (enc oded as $N ) constr ained someho w by the input conditi on. N could , for instance , be unified with one of the object’ s array dimensions , or the v alue of a scalar integer supplied throug h the input interf ace of a box. It is also possible that N has an arithmetic conne ction with the input data, suc h as N = M + 1 , where M comes from the input object set 4 . The comple xity language used for defining latency models should include sym- bols for multiplicatio n, \ti mes , expo nentiatio n \h at , di vision \ slash and log- arithm log . There can be more than one form of complexi ty . For instanc e, the latenc y of a type ch annel could be p robabilis tic: the n umber of mess ages produce d within time t is descri bed by the Poisson distrib ution P t ( λ ) w ith some parameter λ . This, for exa mple, could be represen ted by $$T0 :=: P oisson(1/$N) where 1 / N is the λ -parameter and N , as before, an input-relate d scalar . Natu - rally , an assertion such as $$T0 :=: P oisson(unknown) should also be possib le. Finally , it should be said th at the number of messages p roduced by the box into each of the output type channe ls should be constrained whene ver possible and the constr aints should be communicated to CAL. That can be done in a way s imilar to the latency constrain ts, by employi ng en vironment varia bles $ $M0 , $$M 1 , $$M2 , etc. They should be asso ciated with eithe r intege r numbers that i ndicate ho w man y messages of each type will be produc ed, or a term such as $$M0 :=: limits(5,15) 4 This is also true of functional constraints, they may in volve arit hmetic relations, which is why CAL i ntroduces the machinery of rational numbers. T he hope at this point is that for most practical purposes linear arithmetic is suf ficient. 12 indica ting the limits of v ariation, or indeed could be unkno wn or unbounded (either tak en as the defa ult in the absenc e of an assertion). Here are some examp les illustratin g the use of CAL bo x MYBO X: (a,k) => (b) , (c,d) provided $a := : {T ype(arra y, element($t), rank(2), shape($n,($m,ni l)) ) } \/ $_ , $k:=: {val ue($kv) , T ype(int)} \/ $_ use => $n1=$n+1, $base :=: {T ype(arra y, element($t), shape ($n1,($m,nil )) )}; -- Clause 1 => $b :=: $base \/ {rank(2)}, $d = $base \/ {rank(3)}; -- Clause 2 $kv > $$nthreads * 100 => $$T0 :=: $m * log($m)/$$nthreads, $$T1 :=: 1; -- Clause 3 $kv <= $$nthreads* 100 => $$T1 :=: $m^(3/2); $$M1 :=: 0; -- Clause 4 end Four clauses are declared here, all in put-depen dent on the pr ovi ded condition. The latter unifies the object vari ables from the input tuple w ith sets of terms, thus associ ating local vari ables. The object vari able $a is examin ed to ef fecti vely de- termine whether the correspondi ng object has rank 2, shape n × m and e lement type t . If any part o f this informat ion is not a va ilable, no assertion will be mad e by MYBO X. Next, Clauses 1 and 2 ha ve null input con ditions. They assert the ran ks and shapes o f outpu t objects b and d . Object b is a t wo-dimensi onal object ( n + 1) × m of th e same type a s a . Object d is three-dimensio nal, b ut the th ird dimension is n ot constr ained by MYBOX a priori. Clauses 3 and 4 constrain the en vironment v ariables $$T n . For the first tuple type, the r esult will be compute d in O ( m log m/n th ) time, and f or the secon d out- put t uple the exp ected computati onal time is O (1) . B oth con straints are predic ated on a suf ficiently lar ge val ue of the integer scalar parameter k : k > 100 n th . The en vironment va riable $$n threa ds is associated w ith the va lue n th , which is the number of indepen dent hard ware threads av ailable to the box in questio n. When k ≤ 100 n th , the expec ted computa tion time changes (this could be due to the box using a dif ferent algorithm): now it is , for the first tuple type, O ( m 3 / 2 ) and it does not depend on the number of threads (for instance, because the box uses a sequen - tial algorithm for small objec t sizes). Under such conditions, the second message type is not produced at all, which is indicated by constrain ing the en vironment 13 v ariable $$M1 to the value 0. 3 Conclusion This article describes the basic concepts of the Constra int A ggr e gation Langua ge (CAL), a nov el program-be hav iour descripti on language to be used to describe the functiona l and extra-fu nctional behav iour of software compone nts as terms in a ter m algebra , to serv e as data for a constra int solver . While C AL m ay ev olve ov er time to exte nd its e xpressi veness to furt her patterns of program beha viour , the initial versio n presented in this article already shows the core langua ge feature s of CAL and the basic declara tion mechanisms provied by CAL. Refer ences [1] Agostino Dovier , Enrico Pontelli, and Gianfranco Rossi. Set unification . TPLP , 6(6) :645–701 , 2006. [2] B. Du tertre and L. de Moura. The Y ices SMT s olver. T ool paper at http:// yices.csl.sri .com/tool-paper .pdf, August 2006. [3] Clemens Grelck, Sve n-Bodo S cholz, and Ale x Shafaren ko. A Gen tle I ntroduc- tion to S-Net: T ype d Stream Processi ng an d Declarati ve C oordin ation of Asyn- chrono us Components. P ara llel Pr ocessin g Letters , 18(2) :221–23 7, 2008. [4] Clemens Grelck and Alex Shafare nko. Report on S-Net: A T yped Stream Processin g Language, Part I: Founda tions, Record T yp es and Netw orks. T ech- nical report, Uni versit y of Hertfords hire, Department of Computer Science, Compiler T echnology an d Computer Architectur e Group, Hatfield, England , United Kingdom, 2006. [5] Alex Shafar enko, Sven-Bodo Scholz, and C lemens Grelck. S treaming net- works for coordin ating data-pa rallel pro grams. In Irina V irbitskaite and A n- drei V oronk ov , editors , P erspec tives of System Informatics, 6th Internat ional Andr ei Ershov Memorial Confe r ence (PSI’06), Novosibi rsk, Russia , v olume 4378 of L ectur e Notes in Computer Science , pages 441–445. S pringer -V erlag, Berlin, Heidel berg , New Y ork, 2007. 14