Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 PROPERTIES OF A TYPE ABSTRACT INTERPRETATER. 2 MOTIVATION OF THE EXPERIMENT § a well understood case l type inference in functional programming à la.

Similar presentations


Presentation on theme: "1 PROPERTIES OF A TYPE ABSTRACT INTERPRETATER. 2 MOTIVATION OF THE EXPERIMENT § a well understood case l type inference in functional programming à la."— Presentation transcript:

1 1 PROPERTIES OF A TYPE ABSTRACT INTERPRETATER

2 2 MOTIVATION OF THE EXPERIMENT § a well understood case l type inference in functional programming à la ML § getting a better understanding of the relation between the l type systems l abstract interpretation approaches to property inference

3 3 THE STARTING POINT § abstract interpretation l Monsuez’s reconstruction [FSTTCS 92, SAS 93] as computation of an abstract semantics l Cousot’s systematic derivation by abstract interpretation [POPL 97] of a hierarchy of type systems and type inference algorithms § type systems l Hindley’s monomorhic types l let-polymorphic types à la ML, with monomorphic recursion Damas-Milner’s algorithm (DM) for type inference l polymorphic recursion

4 4 THE FOUNDATIONS OF OUR EXPERIMENT 1 § most of the technical results are taken from Cousot 97 the concrete semantics is the collecting version of the denotational semantics of eager untyped -calculus, without let and with (mutual) recursion the abstract domain is the one defined for monomorphic types terms (monotypes with variables)  idempotent substitutions the abstract partial order is based on the instantiation relation on terms – t 1  t 2, if t 2 is an instance of t 1 the abstract domain is non-Noetherian

5 5 THE FOUNDATIONS OF OUR EXPERIMENT 2  the abstract semantics corresponding to the Damas-Milner type inference algorithm l which is the same as Hindley’s monomorphic types in a language with no “let” construct is obtained in Cousot 97 by abstracting a polymorphic recursion semantics (à la Mycroft)  the last abstraction removes the fixpoint computation (which would be needed in the case of recursive functions) since there is no fixpoint computation in the DM algorithm  why? the fixpoint computation might diverge since the abstract domain is non- noetherian § the DM algorithm can be understood (Monsuez 1992) as the application of a widening operator (based on unification) after the first iteration

6 6 OUR CONTRIBUTION: THE ALGORITHM  the Hindley and ML inference algorithms handle recursive definitions by means of a mechanism which can be explained in terms of a widening operator consisting of 1 abstract fixpoint computation step a unification  our algorithm handles recursion by performing k abstract fixpoint computation steps the unification, only if we have not reached the fixpoint as done by Monsuez in the case of polymorphic types

7 7 OUR CONTRIBUTION: THE RESULTS 1  if we perform just one fixpoint computation step (k = 1), we get exactly the ML result  for every k > 1, either we reach the least fixpoint which is in general more precise than the ML result or we get exactly the same result as ML  we get an improvement in precision only if we reach the least fixpoint in k steps different from what claimed by Monsuez

8 8 OUR CONTRIBUTION: THE RESULTS 2  the resulting abstract semantics lies between the Damas- Milner semantics and the Mycroft semantics in the Cousot’s hierarchy  the corresponding type system turns out to lie between monomorphic types and polymorphic recursion  the algorithm is much simpler than the one for polymorphic recursion no need for quantification in type terms no type generalization in the fixpoint computation, hence no polymorphic recursion  it succeeds in typing all the programs used to show the power of polymorphic recursion

9 9 PLAN OF THE LECTURE § the type abstract interpreter l the abstract semantics described by rules l the widenings l discussion and examples  which type system? between monomorphic and polymorphic recursion looking at the interpreter a new simple and powerful type system? § conclusion l the type system approach to static analysis can profitably import techniques from abstract interpretation

10 10 LANGUAGE AND MONOTYPES  untyped eager -calculus x, f, …  X: program variables e, e 1, …  E: program expressions  e::= id x | x.e | e 1 + e 2 | if e 1 then e 2 else e 3 | int n | e 1 (e 2 ) |  f. x. e  in the Church/Curry monotype semantics the type of an expression e is a set of typings stating that the standard evaluation of e in an environment where the global variables x have type H(x) given by the type environment H returns a value of type m (monotype)

11 11 MONOTYPES WITH VARIABLES  Hindley’s algorithm finds the principal typing for the Church/Curry monotype system an exact representation for all possible typings  Hindley’s algorithm uses the domain of Herbrand terms monotypes with variables  reconstructed as an abstract interpreter by Cousot [POPL 97]  is the same as the ML and Damas-Milner algorithms on the fragment without let polymorphism

12 12 THE TYPE INFERENCE ABSTRACT INTERPRETER 1 § our implementation (in OCaML) of the abstract semantics, http://www.di.unipi.it/~levi/typesav/pagina2.html apart from the case of recursion, is essentially the DM algorithm implementation in Cousineau-Mauny 98 § mutual recursion in the examples only § ML’s notation for concrete syntax and types

13 13 THE TYPE INFERENCE ABSTRACT INTERPRETER 2  the abstract semantics of an expression e in a given type environment H produces the type  of the expression e together with some constraint  on the type variables in H the intuition is that the constraint  is how H should be instantiated in order for e to have the type   the rules of the abstract type interpreter use apply( , t)=  (t)  unify(a=b,  1,  2 ) computes the solved form of the set of equations { a=b, x 1 i = t 1 i, x 2 i = t 2 i } with x 1 i / t 1 i   1 and x 2 i / t 2 i   2

14 14 THE RULES 1 H |- int n  (int,  ) H |- id x  H(x) H |- e 1  (  1,  1 ) H |- e 2  (  2,  2 )  = unify({  1 =int,  2 =int,  1,  2 }) ---------------------------------------- H |- e 1 + e 2  (apply( ,  1 ),  )

15 15 THE RULES 2 H |- e 1  (  1,  1 ) H |- e 2  (  2,  2 ) H |- e 3  (  3,  3 )  = unify({  1 =int,  2 =  3,  1,  2,  3 }) ----------------------------------------------------- H |- if e 1 then e 2 else e 3  (apply( ,  2 ),  ) H |- e 1  (  1,  1 ) H |- e 2  (  2,  2 )  = unify({  1 = f 1  f 2,  2 = f 1,  1,  2 }) ---------------------------------------- H |- e 1 e 2  (apply( ,f 2 ),  ) H [x  (f 1,  )] |- e  ( ,  )  1 = apply( ,f 1 ) ----------------------------------------------- H |- x.e  (  1 ,  )

16 16 THE RULES FOR RECURSION if we abstract systematically the concrete semantics, the abstract semantics of recursion should be an abstract fixpoint computation H |-  f. x.e  T n-1 (  1,  1 ) H |-  f. x.e  T n (  2,  2 ) (  1,  1 ) = (  2,  2 ) ----------------------------------------------------- H |-  f. x.e  (  2,  2 ) H |-  f. x.e  T n-1 (  1,  1 ) H |- (  f. x.e,(  1,  1 ))  f  ( ,  ) ------------------------------------------------------------ H |-  f. x.e  T n ( ,  ) H |-  f. x.e  T 0 (f 1,  ) H[f  ( ,  )] |- x.e  (  1,  1 ) ----------------------------------------------- H |- (  f. x.e,( ,  ))  f (  1,  1 )

17 17 RECURSION AND WIDENING  we have infinite ascending chains we are not guaranteed to be able to find a solution in a finite number of steps the abstract computation for the expression  f. x.f does not terminate  we introduce a family of widening operators obtained by generalizing the operator introduced by the Hindley’s inference algorithm used also in ML # let rec f x = f;; This expression has type 'a -> 'b but is here used with type 'b.

18 18 THE FAMILY OF WIDENINGS H |-  f. x.e  wid k ( ,  ) -------------------------- H |-  f. x.e  ( ,  ) H |-  f. x.e  wid k-1 (  1,  1 ) H |- (  f. x.e,(  1,  1 ))  f  ( ,  ) (  1,  1 ) = ( ,  ) ------------------------------------------------------------ H |-  f. x.e  wid k ( ,  ) H |-  f. x.e  wid k-1 (  1,  1 ) H |- (  f. x.e,(  1,  1 ))  f  ( ,  ) not((  1,  1 ) = ( ,  ))  = unify({  1  = ,  }) ------------------------------------------------------------ H |-  f. x.e  wid k (apply( ,  1 ),  H |-  f. x.e  wid 0 (f 1,  ) H[f  ( ,  )] |- x.e  (  1,  1 ) ----------------------------------------------- H |- (  f. x.e,( ,  ))  f (  1,  1 )

19 19 PROPERTIES OF OUR ABSTRACT SEMANTICS 1 Theorem 1 the Hindley’s algorithm is equivalent to our abstract semantics, with the choice of k = 1 Theorem 2 the relation  wid k defines a family of widening operators which return a correct approximation of the abstract least fixpoint

20 20 PROPERTIES OF OUR ABSTRACT SEMANTICS 2 widenings with more iterations might lead to more precise results as claimed by Monsuez false! Theorem 3 if H |-  f. x.e  wid h (  1,  1 ) and H |-  f. x.e  wid k (  2,  2 ) then (  1,  1 )  (  2,  2 ) unless one of the two is the least fixpoint

21 21 EXAMPLE 1 # let rec f f1 g n x = if n=0 then g(x) else f(f1)(function x -> (function h -> g(h(x)))) (n-1) x f1;; This expression has type ('a -> 'a) -> 'b but is here used with type 'b.  we succeed in typing it with two more iterations, obtaining the type val f:('a-> 'a) -> ('a-> 'b) -> int-> 'a-> 'b = the inferred type is the least fixpoint Cousot computes the same type using a polytype system á la Church-Curry § a function which cannot be typed by ML, from Cousot 97 f f1 g n x = g(f1 n (x))

22 22 TRACE OF THE COMPUTATION 1 step 0  0 ='a1  0 =  step 1  1 ='a5->('a4->'a2)->int->'a4->'a2  1 = {'a1='a5->('a3->(('a3->'a4)->'a2))->int->'a4 ->('a5->'a2)} unification in widening fails {'a4='a3, 'a2=('a3->'a3)->'a2, …} This expression has type ('a -> 'a) -> 'b but is here used with type 'b.

23 23 TRACE OF THE COMPUTATION 2 step 1  1 ='a5->('a4->'a2)->int->'a4->'a2  1 = {'a1='a5->('a3->(('a3->'a4)->'a2))->int->'a4 ->('a5->'a2)} step 2  2 = ('a7->'a7)->('a7->'a6)->int->'a7->'a6  2 = {'a2=('a7->'a7)->'a6} unification in widening fails {'a5='a7->'a7, 'a4='a7, 'a6=('a7->'a7)->'a6, …}

24 24 TRACE OF THE COMPUTATION 3 step 2  2 = ('a7->'a7)->('a7->'a6)->int->'a7->'a6  2 = {'a2=('a7->'a7)->'a6} step 3 (fixpoint!)  3 =('a->'a)->('a->’b)->int->’a->’b  3 = {'a6=('a->'a)->'b, 'a7='a }

25 25 EXAMPLE 2 [Monsuez 92]  ML’s typing # let rec f x = (function x -> function y -> x) 0 (f 0);; val f: int -> int =  we succeed in getting a more precise type with two more iterations val f: 'a -> int =  Monsuez gets the same type by polymorphic recursion

26 26 EXAMPLE 3: mutual recursion [Monsuez 93]  ML’s typing # let rec p x = if q x = q 1 then p x else p x and q x = p 1;; val p: int -> 'a = val q: int -> 'a =  we succeed in getting a more precise type with two more iterations val p: 'a -> ’b = val q: 'a -> ’b =  Monsuez gets the same type by polymorphic recursion

27 27 WHICH TYPE SYSTEM  the main difference between Hindley’s algorithm and our abstract type interpreter lies in the way we deal with recursive definitions  the examples show that we are more precise  why?

28 28 MONOMORPHIC TYPE SYSTEMS  each function application needs to have the same type  such a type is exactly the type of the recursive function  in the Hindley’s algorithm each instantiation of the type of a recursive function produced by a function application has a direct effect in “guessing” the type of the recursive function  the instantiation produced by a function application has to produce the same instantiation on the type of the recursive function itself

29 29 POLYMORPHIC TYPE SYSTEMS  each function application can have any type which is an instance of the recursive function type  the instantiation of the type of a recursive function in a function application does not produce the same instantiation on the type of the recursive function itself  different function applications of a recursive function can lead to different (possibly incompatible) instantiations of the recursive function type

30 30 OUR TYPE SYSTEM  a form of recursion which lies between monomorphism and polymorphic recursion  each function application can have any type which is an instance of the recursive function type as long as all these different instances are compatible  different function applications of a recursive function can lead to different (but compatible) instantiations of the recursive function type

31 31 Inside The Fixpoint Computation  we collect all the constraints produced by the different function applications in each abstract fixpoint computation step  the instantiations must be compatible, i.e., they must produce a satisfiable constraint  we never apply the constraint to the type of the recursive function  the instantiation of the type of a recursive function in a function application does not produce the same instantiation on the type of the recursive function itself

32 32 In The Middle for all the types checked by the Church/Curry monotype system there exists a principal type computed by our abstract type interpreter there are types which can be inferred by our abstract type interpreter which can not be checked by the Church/Curry monotype system any type that can be inferred with our abstract type interpreter can indeed be checked by the Damas-Milner-Mycroft polytype system

33 33 POLYMOPHIC RECURSION À LA Damas-Milner-Mycroft  universally quantified types are inserted in the environment after having been generalized  all the free type variables are universally quantified  any instance by renaming and instantiating universally quantified variables whenever needed in a function application

34 34 OUR POLYMOPHIC RECURSION  our abstract domain is much simpler it is the standard monomorphic types with variables domain without quantification no type generalization  the Damas-Milner-Mycroft polytype system could check an expression where the recursive function is called with two incomparable instances this case seems not to arise in meaningful programs  all the examples introduced as a motivation for polymorphic recursion can indeed be typed by our abstract interpreter

35 35 WHAT DO WE LEARN FROM THE EXAMPLES? § by computing better approximations of the fixpoints (bounded iteration + possible widening) in the abstract semantics of recursive functions l we succeed in inferring more precise types l we solve some problems of the ML type inference algorithm without resorting to more complex type systems § example 1 is typed by Cousot using a polytype system à la Church- Curry (and a fixpoint computation) § example 2 is typed by Monsuez (and Mycroft) using polymorphic recursion (and a fixpoint computation)

36 36 FROM TYPE SYSTEMS TO TYPE INFERENCE  type systems are very important to handle a large class of properties functional and object-oriented programming calculi for concurrency and mobility  the type system directly reflects the property we are interested in  typing rules are easy to understand  it is often hard to move from the typing rules to the type inference algorithm systematic techniques are needed abstract interpretation provides some of these techniques

37 37 FROM TYPE SYSTEMS TO TYPE INFERENCE  which information needs to be added to types in order to perform an accurate inference? the DM algorithm adds idempotent substitutions a kind of relational information [Monsuez 92], very often used in abstract domains, to achieve a better precision in the abstract computation the theory of abstract interpretation provides techniques for the systematic refinement of domains, which can be very useful to systematically transform the property of interest into a good (possibly complete) abstract domain  how to cope with fixpoint approximation abstract interpretation tells us when we can safely compute abstract fixpoints and when and how we should use widening operators

38 38 REFERENCES  R. Gori and G. Levi. An Experiment in Type Inference and Verification by Abstract Interpretation Verification, Model Checking and Abstract Interpretation, Third Int’l Workshop, VMCAI 2002, Venice A. Cortesi, Ed., LNCS 2294, 225-239, 2002  R. Gori and G. Levi. Properties of a Type Abstract Interpreter Verification, Model Checking and Abstract Interpretation, Fourth Int’l Workshop, VMCAI 2003, New York L. Zuck et al., Eds., LNCS 2575, 132-145, 2003


Download ppt "1 PROPERTIES OF A TYPE ABSTRACT INTERPRETATER. 2 MOTIVATION OF THE EXPERIMENT § a well understood case l type inference in functional programming à la."

Similar presentations


Ads by Google