The Ins and Outs of Gradual Type Inference

Transcription

1 The Ins and Outs of Gradual Type Inference Aseem Rastog Stony Brook Unversty Avk Chaudhur Basl Hosmer Advanced Technology Labs, Adobe Systems Abstract Gradual typng lets programmers evolve ther dynamcally typed programs by gradually addng explct type annotatons, whch confer benefts lke mproved performance and fewer run-tme falures. However, we argue that such evoluton often requres a gant leap, and that type nference can offer a crucal mssng step. If omtted type annotatons are nterpreted as unknown types, rather than the dynamc type, then statc types can often be nferred, thereby removng unnecessary assumptons of the dynamc type. The remanng assumptons of the dynamc type may then be removed by ether reasonng outsde the statc type system, or restructurng the code. We present a type nference algorthm that can mprove the performance of exstng gradually typed programs wthout ntroducng any new run-tme falures. To account for dynamc typng, types that flow n to an unknown type are treated n a fundamentally dfferent manner than types that flow out. Furthermore, n the nterests of backward-compatblty, an escape analyss s conducted to decde whch types are safe to nfer. We have mplemented our algorthm for ActonScrpt, and evaluated t on the SunSpder and V8 benchmark sutes. We demonstrate that our algorthm can mprove the performance of unannotated programs as well as recover most of the type annotatons n annotated programs. Categores and Subect Descrptors D.3.4 [Programmng Languages]: Processors Optmzaton; F.3.2 [Logcs and Meanng of Programs]: Semantcs of Programmng Languages Program analyss; F.3.3 [Logcs and Meanng of Programs]: Studes of Program Constructs Type structure General Terms Algorthms, Languages, Performance, Theory Keywords Gradual typng, Type nference, ActonScrpt 1. Introducton Gradual Typng and Evolutonary Programmng Gradual typng [12, 17] ams to combne the benefts of statc typng and dynamc typng n a language. In a gradually typed program, dynamcally typed code can be mxed wth statcally typed code. Whle the dynamcally typed fragments are not constraned to follow the structure enforced by a statc type system, the statcally typed fragments enoy not only some statc safety guarantees ( well-typed programs cannot be blamed the blame theorem [24]) but also Permsson to make dgtal or hard copes of all or part of ths work for personal or classroom use s granted wthout fee provded that copes are not made or dstrbuted for proft or commercal advantage and that copes bear ths notce and the full ctaton on the frst page. To copy otherwse, to republsh, to post on servers or to redstrbute to lsts, requres pror specfc permsson and/or a fee. POPL 12, January 25 27, 2012, Phladelpha, PA, USA. Copyrght c 2012 ACM /12/01... $10.00 admt performance optmzatons that the dynamcally typed fragments do not. Gradual typng envsons a style of programmng where dynamcally typed programs can be evolved nto statcally typed programs by gradually tradng off lbertes n code structure for assurances of safety and performance. Although there has been much recent progress on masterng the recpe of gradual typng, a key ngredent has been largely mssng type nference. The only prevous work on type nference for gradually typed languages s based on unfcaton [18], whch s unsutable for use n obect-orented languages wth subtypng. Unfortunately, as we argue below, the lack of type nference may be the most sgnfcant obstacle towards adoptng the style of evolutonary programmng envsoned by gradual typng. The Key Mssng Ingredent: Type Inference In a gradually typed language, a program may be partally annotated wth types. Any mssng types are unformly assumed to be the dynamc type. Ths means that the fragments of the program that have mssng type annotatons do not enoy any of the benefts of statc typng. In partcular, ther performance s hndered by dynamc casts, even f they mplctly satsfy the constrants of statc typng (.e., even f the dynamc casts never fal). To mprove performance, the mssng types have to be declared. However, n our experence wth a manstream gradually typed language, ActonScrpt [13], the task of evolvng dynamcally typed programs to statcally typed programs by declarng mssng types can be qute onerous. The annotaton burden s often ntmdatng: n the lmt, types must be declared for every varable n the evolvng fragment, and the programmer may need to uggle several annotatons to satsfy the constrants of the statc type system. Furthermore, the programmer may eventually be forced to declare dynamc types for some varables: t may not be possble to satsfy the constrants of the statc type system wthout restructurng the code. Ths s because the programmer may be relyng on an nvarant that cannot be expressed va statc types n the language,.e., the proof of safety may rely on a form of reasonng (typcally, path-senstve) that s outsde the scope of the statc type system. Unfortunately, due to these dffcultes, gradually typed programs often contnue to mss out on mportant benefts of statc typng, such as performance optmzatons. Consequently, evolutonary programmng remans a fantasy. The crux of the problem s that a mssng type s msnterpreted as the dynamc type, whereas the ntended nterpretaton s that of an unknown type. Often, an unknown type can be nferred to be a statc type. In contrast, the dynamc type s a fallback to encode mprecson: a varable must be of the dynamc type when the set of values that the varable may denote cannot be expressed as a statc type n the language, thereby forcng mprecson n the type abstracton. Therefore, we envson an teratve process for evoluton of dynamcally typed programs to statcally typed programs, that alternates between two states. In one state, type nference removes un-

2 nfer types annotate / restructure Fgure 1. Iteratve Evoluton of Scrpts to Programs necessary assumptons of the dynamc type, so that elmnaton of any remanng dynamc types n the code requres ether reasonng outsde the statc type system, or restructurng the code. In the other state, the programmer ether ntroduces further type annotatons or restructures parts of the program to conform to the statc type dscplne. Furthermore, at any state, the programmer may decde to pause the evoluton process, deploy the program, and take advantage of the mproved precson of statc types that have already replaced dynamc types n the program. At a later pont, the programmer should be free to resume the evoluton process. Ths process s depcted n Fgure 1. Snce the programmer may choose to evolve an exstng, deployed program, type nference must ensure that the program remans backward-compatble: t should have exactly the same runtme behavor after type nference as t would have before type nference. In partcular, f the program was safe (dd not fal at run tme) then t should contnue to be safe, and any other programs that ran safely wth the program should contnue to run safely. Retrofttng Type Inference on Gradually Typed Programs In ths paper we study the problem of retrofttng type nference n an exstng gradually typed language. The practcal motvaton for our work s to mprove the performance of exstng ActonScrpt programs under the hood. Our am s to let exstng programs reap the benefts of type-drected performance optmzatons as much as possble, whle remanng backward-compatble. On the other hand, our am s not to elmnate run-tme falures n exstng programs: ndeed, any run-tme falures need to be preserved as well. Thus, the statc types we nfer may not satsfy some statc safety guarantees, such as the blame theorem [24]. Nevertheless, the statc types we nfer can mprove performance, snce they soundly approxmate precse sets of run-tme values. Thus, we prefer to nfer statc types where possble rather than fallng back on the (mprecse) dynamc type. Of course, t remans possble to recover statc safety guarantees by forgong some opportuntes for optmzaton we can fall back on the dynamc type whenever the nferred statc type may be cast to an ncompatble type. Desgn Challenges The am of our type nference algorthm s to reduce the mprecson assocated wth dynamc types, so that programs wth mssng type annotatons can beneft from varous performance optmzatons. We try to nfer, for each varable, a precse type abstracton of the set of values that flow nto t. The settng of a gradually typed language and the requrement of backwardcompatblty present several unque challenges, as outlned next. In a purely statc type system, the defntons of a varable determne a lower bound on ts type, snce the type must admt every value flowng nto the varable; dually, the uses of a varable determne an upper bound on ts type, snce the type must admt only those values that are admtted by the type of every context to whch the varable flows out. Thus, for a type that satsfes both sets of constrants, t s possble to prove statcally that every use of thevarablessafeforeverydefnton of that varable. In contrast, n a gradual type system, every use of a varable need not be safe for every defnton of that varable: nstead, run-tme falures may be avoded f each use s safe for some defnton. Thus, the type of a varable must be nferred by consderng only ts defntons, deferrng type checks on ts uses untl run tme. Furthermore, the type of a varable may only be nferred f t s local,.e., f all of ts defntons are vsble durng complaton. In the absence of ths guarantee, we cannot exclude the possblty that values of an unexpected type may flow nto the varable at run tme: for example, consder a parameter of a global functon, whch can be defned by arbtrary arguments through calls that are not vsble durng complaton. In such cases, replacng the varable s assumed dynamc type wth an nferred statc type may break the program n some unknown run-tme envronment. Based on these observatons, we nfer types of only those varables for whch we can nfer the types of all values flowng n,.e., ther nflows; and we derve the solutons by computng the least upper bounds of those types, wthout checkng that the solutons satsfy the greatest lower bounds of the types of the contexts to whch they flow out,.e., ther outflows. Hgher-order values, such as functons and obects, present some nterestng subtletes. There s an mmedate problem f we take the standard least upper bounds of ther (hgher-order) types, snce we wll then be takng the greatest lower bounds of the nput (negatve) parts of these types whch volates the prncple we motvated above, gvng us prescrptve safe types rather than descrptve precse types for the nput parts of the hgherorder soluton. Another possblty mght be to take the least upper bounds of both nput and output parts, followng naïve subtypng [24] 1. However ths also s not qute rght, snce we are stll neglectng to observe the types of the actual nputs, e.g., the types of arguments n calls to a functon; rather, as wth standard subtypng, we are stll consderng the types of values that such a functon consders safe to nput,.e., the functon s parameter types. The key nsght s that f we are to obey the prncple of solvng based on nflows alone, we must recursvely deconstruct hgher-order types down to ther frst-order parts, solve for those based on nflows (e.g., the nflow of arguments to the parameter of a functon-typed varable), and then reconstruct the hgher-order parts n such a way as to preserve the desred asymmetry. We devse an elegant way of nferrng such hgher-order solutons, va a noton of knds; ths requres us to treat hgher-order nflows n a fundamentally dfferent manner than hgher-order outflows (Secton 2.3). Another complcaton arses when local functons and obects escape. In ths case we cannot nfer the parts of ther types n negatve ( nput ) postons, snce values may then flow nto them from some code that cannot be analyzed at comple tme. Therefore, t seems that we need some knd of escape analyss to fgure out f some local functon or obect escapes. Perhaps surprsngly, the escape analyss we requre s carred out for free by our algorthm: t suffces to assume that n the enclosng program s type, the parts n negatve postons are ether explctly annotated, or are the dynamc type (Secton 2.5). Guarantees Our man guarantee s that the type nference algorthm s sound: f a program fals at run tme wth our nferred types, t would have faled at exactly the same pont wth the dynamc type. The soundness guarantee s compostonal, n the sense that t holds even when the program s placed n an arbtrary run-tme envronment. Furthermore, we show how to recover solutons from our nferred types that satsfy the blame theorem [24]. We also prove that the tme complexty of our type nference algorthm s quadratc n the sze of the nput program. Implementaton and Evaluaton We have mplemented our typenference algorthm for ActonScrpt, and evaluated t on the Sun- Spder [20] and V8 [23] benchmark sutes. Overall, we are able to 1 Naïve subtypng s covarant n both negatve and postve postons, unlke standard subtypng (whch s contravarant n negatve postons).

3 acheve 1.6x performance mprovement on average over partally typed benchmarks (wth type annotatons only on requred parts of the nterfaces), wth a maxmum performance mprovement of 5.6x (Secton 5). Contrbutons To summarze, we make the followng man contrbutons n ths paper: We argue that the evoluton of gradually typed programs s essentally an teratve process, wth type nference beng a key mssng component. We desgn a type nference algorthm for gradually typed languages wth the goal of mprovng the performance of programs as much as possble, whle preservng the run-tme behavors of unannotated programs. Our desgn nvolves new deas that are specfc to the settng of a gradual type system and the requrement of backward-compatblty, such as the need to treat defntons and uses asymmetrcally, and the need for escape analyss to decde what types are safe to nfer. We formalze our type nference algorthm n a core calculus of functons and obects, and prove soundness and complexty theorems for the algorthm. Techncal noveltes n our algorthm nclude a noton of knds to compute precse hgher-order solutons, and the encodng of escape analyss as a syntactc condton on the program s type. We mplement our algorthm for ActonScrpt, a manstream gradually typed language, and evaluate ts effectveness, wth encouragng results. Overall, we beleve that the technques and nsghts developed n ths paper wll elucdate the ntrcaces of type nference for gradually typed languages, and spur further research n ths area. 2. Overvew 2.1 Algorthm Whle exstng complers for gradually typed languages such as ActonScrpt [13] consder mssng type annotatons to be the dynamc type, our am s to nfer precse statc types where possble, and fall back on the dynamc type only where necessary. As usual, our type nference algorthm begns by replacng mssng type annotatons n the program wth fresh type varables. Then we comple the program, usng type annotatons to generate coercons between types. A coercon s of the form S T,whereS and T are types; such a coercon wtnesses the flow of a term of type S nto a context of type T. In partcular, coercons nvolvng type varables are nterpreted as flows for those type varables: for example, f X s a type varable, then T X s an nflow for X, whereas X T where T s not a type varable s an outflow for X. Startng from the orgnal set of coercons collected durng complaton, we now terate, generatng new coercons from exstng ones usng carefully desgned rules whch treat the mplcatons of nflows and outflows dfferently. At each step, new coercons represent flows that are mpled by, but are not drectly expressed by, extant coercons. Iteraton contnues untl our rules can produce no new coercons, at whch pont we have a closure of the flows mpled by the type annotatons n the program. For each type varable X, we can now derve a soluton, namely the least upper bound of all types T that can flow nto X va nflows expressed by coercons of the form T X. A formal treatment of the algorthm s presented n Secton 3. We now demonstrate the fne ponts of the algorthm, vz. the computaton of closures and the dervaton of solutons, usng examples n ActonScrpt [13]; ActonScrpt s an extenson of JavaScrpt wth a gradual type system, and s the programmng language underlyng Flash applcatons. We show type varables as part of programs below, although they are not part of ActonScrpt. In actual programs, these type varables are ust mssng annotatons. We follow the conventon that type varables (n talcs) have smlar names as correspondng unannotated varables, wth the frst letter captalzed. For example, the type varable for an unannotated varable foo n the program s wrtten as Foo. If foo s an unannotated functon, Foo? represents the type varable for the parameter type of foo and Foo! represents the type varable for the return type of foo. The dynamc type s denoted by. Number and Boolean are base types. We also use to denote the bottom type, although t s not part of ActonScrpt. For the purpose of our examples, operators are typed as follows: + : (Number, Number) -> Number < : (Number, Number) -> Boolean 2.2 Local Varables havng Base Types We start wth a smple example to show how our algorthm nfers prmtve types for local varables n a functon, and how t mproves performance. 1 functon foo(n:number):foo! { 2 var ndex:index = 0; 3 var sum:sum = ndex; 4 whle(ndex < n) 5 { ndex = ndex + 1; sum = sum + ndex } 6 return sum 7 } In the absence of type nference, ndex and sum wll be gven type. Snce the + operator has type (Number, Number) Number, evaluaton of ndex + 1 and sum + ndex wll cause n run-tme conversons Number for ndex and sum. Tostore the results back to ndex and sum, further run-tme conversons Number wll happen. As we show later n our experments, such run-tme conversons can hurt the performance of programs. We now show how our nference algorthm works. After addng type varables for mssng types, as shown, we comple the program and collect coercons. The ntalzatons of ndex and sum on lnes 2 and 3 generate Number Index and Index Sum. The operatons ndex < n, ndex = ndex + 1, andsum = sum + ndex on lnes 4 and 5 generate Index Number, Number Index, Sum Number, Index Number,andNumber Sum. To solve these flows, we note that the only type flowng nto Index s Number. So, we nfer Index = Number. Next,wesee that types flowng nto Sum are Number and Index. Therefore, the soluton for Sum s the unon of Number and Index, whchs Number. And fnally, the only type flowng nto Foo! s Sum. So, Foo! = Number as well. Annotatng ndex and sum wth Number rather than mproves run-tme performance by elmnatng unnecessary run-tme conversons between Number and n the loop body. Note that we also generated Sum Number and Index Number but dd not use them for nference. A typcal type checker wll check that the solutons of Sum and Index satsfy these outflows, but we skp ths step. We say more about why we do so n Secton Local Varables havng Functon Types Unons of Functon Types are Problematc When a base type (lke Number or Boolean) flows nto a type varable, the soluton of the type varable s smply that type; and f several base types flow n, the soluton s the unon of those

4 base types. Unfortunately, the obvous ways of generalzng ths approach to hgher-order types (lke functon types) do not work. For example, consder the followng program: 8 var x:x = functon(a:*):number {... }; 9 x(1) On lne 8, we generate Number X. Thus, we may nfer the soluton of X to be the type flowng nto t, Number.However, a more precse soluton s Number Number, based on the fact that the only values flowng nto the parameter of the functon stored n x are of type Number (lne 9). Furthermore, when several functon types flow nto a type varable, we cannot combne those nflows by takng the unon of all such types. Consder the followng example: 10 var x:x; 11 f(b) { x = functon(y:number):number {... }; x(1) } 12 else { x = functon(y:boolean):number {... }; x(true) } We generate Number Number X from lne 11 and Boolean Number X from lne 12. Snce the unon of two functon types s a type S T where S s the ntersecton of ther parameter types and T s the unon of ther return types, we would nfer X to be Number usng the standard approach. Ths would mean that n the runnng program, any applcaton of x to a Number or a Boolean value would result n an error. Ths s clearly unsound as the programmer apples x to anumber at lne 11,and to aboolean at lne 12, both of whch are safe Knds as Hgher-Order Solutons To deal wth hgher-order types, we ntroduce a noton of knds. A knd can be thought of as a vew of a type varable: t descrbes a structure, and ntroduces type varables for the types of parts wthn that structure. Coercons between type varables and knds are generated durng complaton and closure computaton, n ether drecton: a coercon from a type varable T to a knd K wtnesses the flow of T -typed values nto a context whose hgher-order type s exemplfed by K; conversely, a coercon from K to T wtnesses the flow of hgher-order values of knd K nto a T -typed context. For example, on lne 9, the functon call x(1) nduces a vew of X as a functon type. To realze ths vew, we generate the coercon X X? X!, wherex? X! s a knd for X correspondng to functon types; ths wtnesses values of type X flowngtoacontext n whch they are used as functons. We also generate Number X?, whch wtnesses the flow of arguments of type Number nto the parameters of those functons. Combnng Number X and X X? X!, weget Number X? X!. Deconstructng ths flow usng contravarance for the parameter type and covarance for the return type, we get X? and Number X!. Intutvely, these coercons wtness the flows nto and out of the concrete functon value assgned to x on lne 8, resultng from the call to x on lne 9. Solvng these flows, we obtan X? = Number,andX! = Number. But what should X s soluton be? We clam t should be X s functon knd,.e. X? X!, whch after substtutng for X? and X!, becomes Number Number. Our closure rules ntroduce the necessary ntermedate step, the coercon X? X! X, as a consequence of the assgnment on lne 8. Thus, a knd not only gves a vew of a type varable as a hgher-order type, but also encodes the correspondng hgher-order soluton of the type varable. In other programs, there may be no occason to generate a coercon from a type varable X to a knd at all, due to an absence of contexts n whch X-typed values are used n a syntactcally hgher-order way, such as the functon applcaton term x(1) n the prevous example. Consder the followng varaton: 13 var x:x = functon(a:*):number {... }; 14 functon f(y:number -> Number):Number { y(1) } 15 f(x) We generate Number X and X Number Number on lnes 13 and 15 respectvely. Here we don t need the vew of X as a functon type snce x s not appled drectly, but we stll need to represent the soluton for X. Ths s accomplshed by the coercons ntroduced by our closure rules as a result of the assgnment on lne 13, namely Number X? X!,andX? X! X. Combnng X? X! X and X Number Number gves us X? X! Number Number. Solvng the flows gves us X? = Number and X! = Number. As before, snce only functon types flow nto X, ts soluton s ts functon knd X? X!, whch after substtutng for X? and X! gves us Number Number. Fnally, decomposton usng knds enables us to take unons of knds, not types, gvng us types nferred from nflows alone. For example, the decomposton of X nto X? X! lets us capture the flow of argument types to X? n the calls to x on lnes 11 and 12, yeldng Number X? and Boolean X?, respectvely. These frst-order flows may then be combned by takng the least upper bound n the usual way, after whch reconstructon of X proceeds as descrbed above. 2.4 Functon Parameters Functons Callable by Exstng Code Are Problematc Snce we cannot assume that all exstng ActonScrpt programs wll be avalable for our analyss, a key goal of our algorthm s to ensure that our nferred types are backward-compatble.e., programs compled usng nferred types are able to nteroperate wth programs compled under the assumpton that mssng type annotatons are the dynamc type, wthout ntroducng any new runtme falures. We now show an example n whch we try to extend our algorthm to nfer the parameter type of a functon that can be called by other programs that are not avalable for analyss. 16 functon foo(x:foo?):foo! 17 { f(b) { return x + 1 } else { return 0 } } 18 foo(1) The functon call foo(1) on lne 18 generates Number Foo?. Furthermore, as before we generate Foo? Number and Number Foo! on lne 17. Solvng for type varables, we get Foo? = Number and Foo! = Number. (As before, we do not use Foo? Number for nference.) Suppose that the functon foo s part of the nterface of some lbrary, and clents of foo have been compled under the assumpton that Foo? and Foo! are. Then the soluton for Foo! s sound, because t can be used n any context of type : n partcular, t wll not throw an error unless t flows to a context whose type s ncompatble wth Number, n whch case t would already throw an error wthout type nference. Unfortunately, the soluton for Foo? s not sound. For example, suppose a caller sets the global varable b = false and then calls foo wth x = true. In the absence of type nference, the true argument wll be successfully converted at run tme from type Boolean to type after whch t wll go unused, snce b = false, avodng a run-tme error. In contrast, f we add the annotaton x:number after type nference, ths wll have the effect of requrng a run-tme converson of thetrue argument from Boolean to Number at the pont of the call to foo, and ths converson wll always fal. Thus nferrng Foo? = Number can break exstng programs. In general, we conclude that we cannot safely nfer the parameter types of functons that are part of the nterface of the program

5 wth exstng code, because our analyss cannot be guaranteed to nclude every call to such functons Local Functons On the other hand, t s safe to nfer the parameter types of local functons.e., functons defned wthn other functons and obects whenever all ther calls are avalable for analyss. Consder the local functon foo n the followng example: 19 functon bar(y:number):bar! { 20 functon foo(x:foo?):foo! 21 { f(b) { return x + 1 } else { return 0 } } 22 return foo(y) 23 } As before, we get the solutons Foo? = Number and Foo! = Number. (Here, we also get Bar! = Number.) Snce foo s a local functon that does not escape bar, we know t cannot be called from outsde bar, meanng that all calls to foo are avalable for analyss. In ths case t s safe to nfer Foo? = Number, evenfthe functon bar s callable by exstng code Local Functons that Escape Are Problematc However, f a local functon escapes e.g. by beng returned as a hgher-order value from a functon that s callable by exstng code then t becomes avalable to callers n the wld. Ths agan makes t unsafe to nfer the local functon s parameter type, snce not every call to the functon s avalable for analyss. 24 functon bar(y:number):bar! { 25 functon foo(x:foo?):foo! 26 { f(b) { return x + 1 } else { return 0 } } 27 foo(y); 28 return foo 29 } In ths example, nferrng Foo? = Number based on functon call foo(y) on lne 27 would agan be unsound, assumng the functon bar s callable by exstng code. Snce foo s returned by bar, clents can set b = false and call foo wth any x value. Thus, as n Secton 2.4.1, annotatng x as Number could ntroduce run-tme errors n exstng programs. 2.5 What Types are Safe To Infer? To summarze, the examples above llustrate that whle t may be safe to nfer the types of local varables n a functon, the return types of functons, and the parameter types of local functons that do not escape, t s defntely not safe to nfer parameter types of functons that are callable by exstng code, and those of local functons that do escape. Furthermore, f values from such parameters flow nto other varables, then nferrng the types of those varables s clearly also unsafe. So what s the prncple that lets us decde whch types are safe to nfer? Seeng All Inflows s Necessary We observe that n a gradually typed language, we must see the types of all the values that may flow nto a varable before we can nfer the varable s type. Suppose that at comple tme we see only a proper subset of the types of values that may flow nto a varable x.e., some of the types of values that may flow nto x are unknown at comple tme, because they flow nto x from a run-tme envronment that cannot be analyzed durng complaton. Next, suppose that the compled program s executed n such a run-tme envronment. In the absence of type nference, x has type, whch means that the run-tme envronment could wrte any type of value nto x. Furthermore, the programmer could reason outsde the type system to ensure that once such a value reaches x, tsthenused correctly under approprate condtons. Thus, f the nferred type of x s based only on the subset of types that are seen, then we could end up breakng the program n ths run-tme envronment, by causng a run-tme error to be thrown upon the wrte to x: not only would ths error not have occurred n the absence of type nference, but as descrbed n the prevous paragraph, t s qute possble that no error would have occurred at all Flows Encode Escape Analyss For a functon that s callable by exstng code, we requre the programmer to explctly annotate the parts of the functon s type that have negatve polarty (n partcular, the parameter type), f those parts have statc types. In the absence of annotatons, we must assume they have the dynamc type. For a local functon, our ablty to nfer the parts of ts type wth negatve polarty depends on whether the functon escapes nto an unknown run-tme envronment. There are many ways a local functon can escape: t can be returned as a value, t can be assgned to a global varable, t can be assgned to some obect property and that obect could be returned, and so on. At frst glance, t seems that ether we need a sophstcated escape analyss to fgure out f a local functon escapes, or we need the programmer to annotate parameter types for local functons as well. Fortunately, we observe that the flows already encode an escape analyss. If we requre that types wth negatve polartes n the nterface of the program wth exstng code be explctly annotated f statc.e., f we assume that they are the dynamc type when unannotated then our closure computaton ensures that escape nformaton s properly propagated to all type varables. Let us consder the example from Secton wth dfferent possbltes for Bar!. Frst, suppose that the programmer has annotated the return type of bar as Number Number. In ths case, the programmer has annotated the types wth negatve polarty n bar explctly. Now, t s safe to nfer Foo? = Number, snce the programmer has told us that foo wll always be called wth x as Number (otherwse there wll be a run-tme error). On the other hand, f the programmer had not explctly annotated the return type of bar, wewouldhaveassumedttobesome type varable Bar!. As before, we generate Foo? Foo! Bar! from return foo on lne 28. We ntroduce functon knd (Secton 2.3.2) for Bar! and add Foo? Foo! Bar!? Bar!! and Bar!? Bar!! Bar!. Now, we observe that Bar!? has negatve polarty. Snce the functon bar s callable by exstng code, we assgn Bar!? =. Thus,wehaveFoo? Foo! Bar!!. Deconstructng the flow, we get Foo?. Andfnally, we nfer Foo? =, whch s always safe. In ths way, escape analyss s manfested through our closure computaton. Thus, we requre explct type annotatons only for types that have negatve polartes n the nterface of the program wth exstng code; all the remanng types we can nfer. 2.6 Outflows So far we have mantaned that we are lookng at nflows, of the form T X, to solve for type varable X. But we have not sad anythng about outflows, of the form X T,whereT s not a type varable. Such outflows correspond to dynamc consstency checks Outflows Need Not Contrbute to Solutons We observe that outflows, of the form X T, need not contrbute to the soluton for X although n general, such outflows do play

6 a role n propagatng flows between parts of hgher-order types, as we have seen n Secton If we can analyze all wrtes to X, we know precsely the types of all values that X wll need to hold at run tme and so, by ust lookng at nflows, of the form T X, we can nfer a more precse soluton for X Outflows Need Not be Valdated Statcally We also do not need to valdate the outflows at comple tme, as the runtme does t anyway. As we show n the followng example, f we try to valdate outflows statcally, we could end up beng too conservatve and nfer less precse types than we could. 30 functon foo(f:foo?):number { 31 f(b) { return f(true) } else { return 0 } 32 } 33 f(b) { foo(functon (x:boolean):number {... }) } 34 else { foo(functon (x:number):number {... }) } Frst we note that ths program s safe f Foo? =, whch s the case when there s no type nference. When b s false, foo doesn t use ts argument and returns 0. In our nference algorthm, we generate the flows: Boolean Number Foo?? Foo?! (lne 33), Number Number Foo?? Foo?! (lne 34), and Boolean Foo?? (from functon call g(true) on lne 31). Deconstructng the frst two flows gves us Foo?? Boolean, Foo?? Number, andnumber Foo?!. Therefore, we nfer Foo?? = Boolean and Foo?! = Number, and our soluton s Foo? = Boolean Number. Wth these nferred types, the program s stll safe. There s no change n the run-tme semantcs of the program. But note that our soluton Foo?? = Boolean turns the outflow Foo?? Number to the dynamc consstency check Boolean Number, whch wll fal, f executed at run tme. So, f we were to valdate outflows statcally, we would have promoted Foo?? to, whch means we would have nferred a less precse type that we could. In ths example, the programmer encodes path senstve reasonng about correctness of hs program and ensures that the dynamc consstency check Boolean Number never happens at run tme (when the functon n lne 34 s passed to foo, foo doesn t nvoke t). Snce t s not possble to statcally determne whether dynamc consstency checks wll fre at run tme, we do not valdate outflows. But, we mantan that our nference doesn t ntroduce any new run-tme errors. Our soundness theorem proves that f a program fals at run tme wth our nferred types, t would have faled even f those types were, and vce versa Valdatng Outflows for Blame Guarantees Tradtonally, type nference algorthms n statcally typed languages ensure that the soluton of X s a subtype of the greatest lower bound of all the types T that flow out of X. Ths mples that all dynamc consstency checks always succeed. In our system we do not valdate outflows because ths may unnecessarly constran our nferred types, as we saw n the prevous example. But ths comes wth a trade-off. Type nference for statcally typed languages guarantees that nferred types wll not generate any run-tme type errors. Whle we clearly cannot hope for such guarantees, gradually typed languages often provde weaker blame guarantees [24] the statcally typed parts of a program cannot be blamed for any run-tme type errors. On the other hand, by default, we do not gve any such guarantee: dynamc consstency checks may throw errors at run tme. Instead, our nferred types can be thought of as drectves to a runtme to optmze memory, run-tme conversons, property lookups, and so on; we only guarantee that they do not ntroduce any new run-tme errors n the program. If, on the other hand, the programmer wants some blame guarantees from our system, we can run an addtonal step wheren we valdate outflows. If some outflow may cause an error, we ether promote the type varable that may cause the error to the type, or f there s no type varable nvolved, fal the complaton. In the example of prevous secton, once we fnd that nferrng Foo?? = Boolean wll fal the consstency check Foo?? Number, we can promote the type varable Foo?? =, and recover blame guarantees for our system. 2.7 Obects The treatment of obects n our system follows that of functons, n that we use polartes to model obect propertes wth varous access controls. For example, prvate propertes of obects have no polarty, so we nfer types of prvate propertes. Read-only propertes, lke publc functons, have postve polarty and so, we nfer postve parts of the types of those functons and we requre programmers to annotate the negatve parts. On the other hand, publc varables n an obect are read-wrte, so they have both negatve and postve polartes, and we requre programmers to annotate the types of publc varables. As before, we do not need escape analyss to fgure out f some prvate functon escapes the scope of an obect, or f a prvate obect escapes the scope of a functon. Escape analyss s manfested n the closure computaton. We show an example n ActonScrpt where obect templates are defned usng classes. 35 class A { 36 prvate var b:b = true; 37 prvate functon foo(var x:foo?):foo! 38 { f(b) { return x + 1; } else { return 0; } } 39 publc functon bar():bar! { return foo; } 40 } In ths example, our soluton wll be: B = Boolean, Foo? =, Foo! = Number, Bar! = Number. Note that as before, we nfer Foo? = because t s returned from a publc functon bar. Summary Our key observatons can be summarzed as follows. 1. Unlke type nference n statcally typed languages, we treat nflows, whch represent defntons, n a fundamentally dfferent manner than outflows, whch represent uses. The nflows for a type varable determne ts soluton. The outflows for a type varable represent dynamc consstency checks that happen at the runtme. 2. When the nflows for a type varable nvolve hgher-order types, ts soluton s encoded by a knd, whch deconstructs the the type varable nto parts, recursvely solves for those parts, and reconstructs the solutons to determne the soluton of the type varable. In partcular, the negatve parts of such a soluton are determned by the negatve parts of hgher-order types n the outflows for the type varable. 3. We need to see all the types of all values flowngntoavarable before we can nfer ts type. Ths means that we can only nfer postve parts of the type that serves as the program s nterface wth exstng code. The negatve parts of that nterface can be defned by some unknown run-tme envronment, so we ether need the programmer to annotate those parts explctly, or we assume them to be the dynamc type. 4. We do not need a separate escape analyss to fnd whch types escape ther scope. Once we have put suffcent type annotatons n the nterface of the program wth exstng code, our flows encode the escape analyss. 5. Our framework extends naturally to obects (and classes). We use polartes to model obect propertes wth varous access controls: prvate, read-only, wrte-only, and publc.

7 complaton computaton of closure type nference dervaton of solutons blame recovery ry Fgure 2. Overall Archtecture for Type Inference 3. Formal Development In ths secton, we formally develop our type nference algorthm for a core gradually typed calculus of functons and obects. Unknown types are modeled as type varables n the language. We formalze the statc semantcs of the language by a complaton udgment that translates a program annotated wth types to a program wth coercons (Secton 3.2). We then descrbe a type nference algorthm that analyzes the coercons to compute a flow relaton over types, and derves a soluton map for the type varables basedonthsflow relaton (Secton 3.3). We also descrbe how the soluton map may be weakened to recover standard blame guarantees (Secton 3.4). Fgure 2 depcts the overall archtecture for type nference. We prove complexty theorems for the type nference algorthm (Secton 3.5). Next, we formalze the dynamc semantcs of the language by an evaluaton udgment that, under a soluton map for the type varables, reduces programs wth coercons to values (Secton 3.6). Based on ths dynamc semantcs, we prove soundness theorems for the type nference algorthm, by comparng the behavors of programs under the soluton map nferred by our algorthm wth those under the default soluton map that nterprets every type varable as the dynamc type (Secton 3.7). 3.1 Syntax The syntax of the language s shown below. We model functon parameters and obect propertes as varables x. In contrast to standard obect calcul, we dstngush readablty and wrtablty of obect propertes: we model access capabltes κ for obect propertes as subsets of {+, }, where + denotes readablty and denotes wrtablty. We express obects and ther types as ndexed collectons of obect propertes and ther types; for any non-negatve nteger m the notaton [m] means the set of ndces {1,...,m}, and for any syntactc entty φ the notaton {φ } [m] means the collecton {φ 1,...,φ m} ndexed by [m]. term t ::= null fun (x:t ) t:t {x κ :T = t } [m] x x = t t(t ) t.x t.x = t T T t f t then t else t type varable X ::= α X? X! X.x type T ::= T T {x κ : T } [m] X Terms nclude functons (of the form fun (x : T ) t : T ), obects (of the form {x κ : T = t } [m] ), and the null value (null), as well as applcatons of functons (of the form t(t )), reads and wrtes of obect propertes (of the form t.x and t.x = t ), and null checks (of the form f t then t else t ). They also nclude reads and wrtes of varables (of the form x and x = t). Furthermore, they nclude coercons between types (of the form T T ). Coercons may be nterpreted syntactcally as flows, and semantcally as representaton-converson operatons. We assume that n source code, there are no coercons. Types nclude functon types (of the form T T ), obects types (of the form {x κ : T } [m] ), the null type ( ), and the dynamc type ( ). Furthermore, they nclude type varables X. Some type varables may be derved by others: X.x denotes the type of the property x of obects of type X, whle X? and X! denote the type of the nput and output of functons of type X. We assume that n source code, type varables are dstnct and are of the form α. Recursve functons, self references, and loops can be readly encoded n the language; so can blocks wth local varables. Thus, we do not nclude those constructs n the language. Furthermore, we do not model classes: ther treatment s smlar to that of obects, and we dscuss them further n Secton Complaton We now descrbe the complaton semantcs of our language. The goal of complaton s to compute types and embed coercons n source programs, thereby preparng them for type nference (Secton 3.3) and evaluaton (Secton 3.6). Complaton proceeds under a type envronment. A type envronment Γ s a fnte map from varables to types. Complaton udgments are of the form Γ t t :: T, meanng that t comples to t of type T under Γ. Fgure 3 lsts the rules for dervng complaton udgments. The complaton rules are farly straghtforward: the type of a term s computed n a syntax-drected manner, and whenever a term of type T appears n a context that s annotated wth type T, the coercon T T s attached to the term. We elaborate on the rules for deconstructng functons and obects, namely (C-APP) for functon applcatons and (C-PROPR) and (C-PROPW) for obect property accesses: they rely on a partal relaton between types, defned below. Intutvely, ths relaton captures the condton under whch a term of a certan type can be deconstructed, by vewng the type ether as the type of a functon that can be appled or as the type of an obect for whch a property can be read or wrtten. Defnton 3.1 (Vew). AtypeT canbevewedasatypet f T T can be derved by any of the followng rules. X X? X! T T T T X {x κ : X.x} for κ = {+} or κ = { } {x κ : } for κ = {+} or κ = { } {x κ : T } [m] {x κ : T } such that [m] and κ κ, for κ = {+} or κ = { } Complaton may fal due to the partalty of the vew relaton: essentally, whenever a term of some type s deconstructed n a context that s annotated wth an ncompatble type. In partcular, a functon cannot be vewed as an obect, an obect cannot be vewed as a functon, and an obect wthout a partcular access capablty for a property cannot be vewed as an obect wth that access capablty for that property. Further restrctons can be mposed statcally. In partcular, a standard gradual type system would detect other unsafe coercons, by nterpretng all type varables as the dynamc type and ensurng that coercons are between statcally consstent types (cf. consstency and consstent-subtypng [16, 17]). Statc consstency s defned n Secton 3.4, where we dscuss how to carry over blame guarantees offered by such systems to our settng. How-

8 Complaton udgment Γ t t :: T (C-NULL) Γ null null :: (C-FUN) Γ[x T 1] t 2 t 2 :: T 2 t 2 = T 2 T 2 t 2 Γ fun (x:t 1) t 2 :T 2 fun (x:t 1)(t 2 ):T 2 :: T 1 T 2 (C-OBJ) Γ =Γ[x 1 T 1,...,x m T m] [m]. Γ t t :: T t = T T t Γ {x κ :T = t } [m] {x κ :T = t } [m] :: {x κ :T } [m] (C-PROPR) (C-PROPW) Γ t t :: T T {x {+} : T } Γ t.x ( T {x {+} : T } t ).x :: T Γ t t :: T T {x { } : T } Γ t t :: T t = T T t Γ t.x = t ( T {x { } : T } t ).x = t :: T (C-APP) (C-VARR) (C-VARW) Γ t t :: T T T 1 T 2 Γ t 1 t 1 :: T 1 t 1 = T 1 T 1 t 1 Γ t (t 1) ( T T 1 T 2 t )(t 1 )::T 2 Γ(x) =T Γ x x :: T Γ(x) =T Γ t t :: T Γ x = t x = T T t :: T (C-IF) Γ t t :: T α fresh {1, 2}. Γ t t :: T t = T α t Γ f t then t 1 else t 2 f t then t 1 else t 2 :: α Fgure 3. Complaton ever, we emphasze that we do not requre those restrctons for our soundness theorem: we can tolerate exstng run-tme falures as long as we do not ntroduce any new run-tme falures. 3.3 Type Inference Followng complaton, the coercons embedded n a program say what types of terms appear n what types of contexts. Other coercons are mplct n the type of the compled program, whch serves as the nterface wth exstng code: these are coercons between the dynamc type and type varables n the type of the compled program (whch contnue to be nterpreted as the dynamc type by exstng code). Based on ths set of coercons, we conduct type nference as follows: 1. We apply some carefully desgned closure rules on ths set of coercons, to compute a flow relaton between types (Secton 3.3.1). The flow relaton overapproxmates the set of all possble flows of terms to contexts at run tme. 2. We then derve a soluton map for type varables based on that flow relaton (Secton 3.3.2). In partcular, f some context s Flow udgment T T (F-BASE) T T s a coercon n the compled program T T (F-COMP) T s the type of the compled program C {X X s postve n T } { X X s negatve n T } C (F-PULL) (F-FACTOR) K X X K X Y X Y T X T X = K X C {T K X, K X X} C (F-TRAN) (F-EXPFUNL) (F-EXPOBJL) (F-EXPFUNR) (F-EXPOBJR) K X X X T K X T {x κ {x κ K X T T 1 T 2 T 1 T 2 {x κ : T } [m] : } [m] {x κ : T } [m] T 1 T 2 T 1 T 2 {x κ : T } [m] : T } [m] {x κ : } [m] (F-SPLITFUN) T 1 T 2 T 1 T 2 C {T 1 T 1,T 2 T 2} C (F-SPLITOBJ) {x κ : T } [m] {x κ : T } [n] n m [n] :κ κ [n] C {T T + κ } {T T κ } C Fgure 4. Computaton of Closure annotated by a type varable, the soluton for that type varable s an overapproxmaton of the types of terms that may flow to that context at run tme Computaton of Closure Gven a compled program and ts type, we compute a flow relaton between types by ntalzng and growng a set of coercons untl fxpont. Flow udgments are of the form T T, meanng that flows from type T to type T are possble,.e., terms of type T may flow to contexts annotated wth type T at run tme. Fgure 4lsts the rules for dervngflow udgments. Those rules are explaned below.

9 Unlke usual flow relatons for statcally typed languages wth subtypng, our flow relaton s not merely a transtve closure of the coercons n a compled program, nterpreted as subtypng constrants. Instead, t s desgned carefully to account for gradual typng, and s tuned for effcency. Rules (F-BASE) and (F-COMP) generate the ntal facts. In partcular, (F-COMP) reles on a standard noton of polarty for type varables, defned below, to ensure that any type varable that appears n the type of the compled program s (or becomes, by other rules) tanted wth the dynamc type n the contravarant parts. Defnton 3.2 (Polarty of a type varable n a type). The set of postve varables and the set of negatve varables n a type T are P + (T ) and P (T ), respectvely, defned as follows. Let s range over {+, }; lets be when s s +, and + when s s. P + (X) ={X}, P (X) ={} P s ( ) =P s ( ) ={} P s (T 1 T 2)=P s (T 1) P s (T 2) P s ({x κ : T } [m] ) = {P s (T ) [m], κ } {P s (T ) [m], + κ } For example, f the nterface of the compled program wth exstng code s X 1 X 2,then(F-COMP) reflects the followng assumptons: We assume that there s a flow from to X 1. We also assume that there s a flow from X 2 to,sothatf(say) there s a local functon that escapes through X 2, then (by other rules) we can derve a flow from to the parameter type of the escapng functon. Smlar consderatons apply f the nterface s an obect type: f a wrtable property s annotated wth a type varable, there s a flow from to that type varable, and f a readable property s annotated wth a type varable, there s a flow from that type varable to. (If a property s both, we assume both flows; f a property s nether, we assume nether.) Other rules, namely (F-PULL), (F-FACTOR), and (F-TRAN), rely on a noton of kndng for type varables, defned below. Intutvely, a type varable has, for every type constructor that may form a soluton for the type varable, a knd that encodes that soluton. Defnton 3.3 (Knds for a type varable). Knds for a type varable X, ranged over by K X, are types of the form, X? X!, : X.x } [m],or. {x κ Eventually, the soluton of a type varable s derved by the knds that flow nto t, ether drectly or ndrectly through other type varables. Thus, the rule (F-PULL) pulls any knd on the left of a type varable to any other type varable on ts rght. The rule (F-FACTOR) factors a coercon from a type to a type varable nto ntermedate coercons through a correspondng knd for that type varable, computed as shown below. Ths factorng ensures that flows from types to a type varable are approprately captured n solutons for that type varable. Defnton 3.4 (Knd of a type for a type varable). The knd T X of a type T,whereT s not a type varable, for a type varable X s defned as follows: X = X = T 1 T 2 X = X? X! {x κ : T } [m] X = {x κ : X.x } [m] The rule (F-TRAN) lmts transtve flows through a type varable n two ways: t only consders a knd on the left, and t only consders a type on the rght such that the knd on the left s dynamcally consstent wth the type on ts rght. Dynamc consstency s a partal relaton between types that are not type varables, defned as follows; t models coercons that never fal at run tme. Defnton 3.5 (Dynamc Consstency). AtypeT s dynamcally consstent wth another type T f T and T are not type varables, and T T can be derved by any of the followng rules. T T, T T 1 T 2 T 1 T 2 {x κ : T } [m] {x κ : T } [n] f n m, and for all [n], we have κ κ In combnaton wth (F-FACTOR), the rule (F-TRAN) ensures that flows from types on the left of a type varable to types on the rght of the type varable are taken nto account, wthout computng a standard transtve closure. (In Secton 4, we dscuss why computng a standard transtve closure s undesrable.) The remanng rules are farly straghtforward. (F-EXPFUNL), (F-EXPFUNR), (F-EXPOBJL), and (F-EXPOBJR) expand on the left or rght of a hgher-order type to the approprate shape. Fnally, (F-SPLITFUN) and (F-SPLITOBJ) splt flows between hgher-order types nto flows between ther parts, respectng covarance and contravarance. Note that snce we dstngush access capabltes for readng and wrtng obect propertes, the types of obect propertes are not necessarly nvarant: they may be covarant (read-only), contravarant (wrte-only), nvarant (read-wrte), or even abstract (no access) Dervaton of Solutons Based on the flow udgment, we derve a soluton map I that assocates each type varable X to a type wthout type varables. We also extend I to a functon Î from types to types wthout type varables, such that Î(T ) s the type obtaned by substtutng each type varable X n type T by I(X). To solve for X, lett + (X) be the set of types T such that T s not a type varable, and T X ; we compute the least upper bound of the knds of types for X n T + (X), asdefned below. Defnton 3.6 (Least upper bound of knds). The least upper bound K X 1 K X 2 of two knds K X 1 and K X 2 for X s defned as follows: K X = K X, K X = K X K X =, K X = (X? X!) (X? X!) = X? X! {x κ : X.x } [m] {y κ : X.y } [n] = {z κ k k : X.z k } k [p], where {z k } k [p] = {x } [m] {y } [n] and for all [m], [n], and k [p], fx = y = z k then κ k = κ κ. (X? X!) {x κ : X.x } [m] = {x κ : X.x } [m] (X? X!) = The soluton I(X) for X s then defned as Î( T T + (X) T X). Such solutons are always well-founded, snce knds do not have cyclc dependences. 3.4 Blame Recovery Standard gradual type systems enforce that the coercons n a compled program satsfy statc consstency, whch s a partal relaton between types that are not type varables, defned as follows: Defnton 3.7 (Statc Consstency). AtypeT s statcally consstent wth another type T f T and T are not type varables, and T T can be derved by any of the followng rules.