We have presented a type system for analysing the heap-space consump- tion of FJEU programs and we have proved its soundness. However, the declarative system presented here cannot be implemented for the following reasons: first, the typing rules are not syntax directed; second, for checking the polymorphic types of methods we need to check all their (possibly in- finite) instances, which is infeasible. Hence we need an algorithmic version of the system that is more suitable for a practical implementation. More- over, the analysis would not be practical if the programmers would need to provide the views and potential annotations by hand. Therefore a type inference algorithm is vital.
Algorithmic typechecking
Given: A RAJA program R= (C,main,M). Wanted: Is R a well-typed RAJA program?
Type inference
Given: An FJEU programP = (C,main).
Wanted: A well-typed RAJA program R= (C,main,M).
Heap-space analysis
Given: An FJEU programP = (C,main).
Wanted: Number of heap cells required for executingmain as a func- tion ofmain’s arguments.
Figure 3.5: Algorithmic problems regarding the type system RAJA.
In the remaining of this thesis we attempt to solve those two problems: algorithmic type checking and type inference, which we define formally in Fig. 3.5. Notice that, by Corollary 3.3.12, solving the type inference problem for a particular programP implies solving the heap-space analysis problem forP.
Chapter 4
Type Checking RAJA
Programs
4.1
Overview
The main goal of this chapter is to define a typing system that is equivalent to the system described in the previous chapter, but that is more suitable for algorithmic tasks like type checking and type inference than the declarative system.
Some of the typing rules from the previous chapter are not syntax- directed. One of them is the rule(♦W aste).
n≥u n+u0 ≥n0+u Γ<: Θ Ds<:Cr Θ uu0 e:Ds
Γ nn0 e:Cr
(♦W aste) To create syntax-directed typing rules, subtyping and weakening of potential annotations can be integrated in the other rules and so (♦W aste) can be removed from the system. Another non-syntax-directed rule is(♦Share).
.(s|s1, . . . , sj) Γ, y1:D s1, . . . , y j:Dsj n n0 e:Cr Γ, x:Ds n n0 e[x/y1, . . . , x/yj] :Cr (♦Share) Unlike with (♦W aste), integrating (♦Share) in the remaining rules is not so simple: the system gives no information about how to find the views s1, . . . , sj.
Another rule that is difficult to implement, although it is syntax-directed, is the rule(♦Let).
Γ1 n n0 e1 :Ds Γ2, x:Ds n0 n00 e2 :Cr Γ1,Γ2 n n00 let D x=e1 in e2:Cr (♦Let)
When type checking a let expression, even if we know the potential anno- tationsn, n00, there is no way of knowing the annotationn0.
Finally, the rule for method typing(♦M Body) is also problematic: know- ing the polymorphic type here is not enough for type checking the method. Similarly to the rule(♦Share), this rule gives no information about how to find the viewsr1, r2.
m∈Meth(C) φ=M(C, m) ∀T = (Cs0;E~~sn/n 0 −−→Hsn+1) instanceof φ .(s0|r1, r2) this:Cr1, x 1:E1s1, . . . , xn:Ensn n+♦(Cr2) n0 Mbody(C, m) :Hsn+1 (♦M Body) `m:φ ok
For solving all those difficulties when type checking RAJA programs, we need to annotate the programs with more information than only the poly- morphic RAJA types. We need view and potential annotations inside the body of methods as well. In particular, we need to annotate all the variable occurrences with views, and the let expressions with potentials. Moreover, the annotations depend on the particular instance of the polymorphic type. Thus, we would need a map from monomorphic types to annotated expres- sions. You could think that these are just too many annotations, and that it would be definitely infeasible to write them all by hand. That is true, but we aim at describing type inference for the system. You can regard the system described in this chapter as an intermediate step towards type inference: only when we know how much information we actually need, we can infer it.
This chapter is organised as follows. In Section 4.2 we describe RAJA programs with explicit types, which are RAJA programs with more anno- tations and that contain sets of instances of the polymorphic RAJA types. In Section 4.3 we describe algorithmic views that will be useful for describ- ing an algorithmic rule for typing method bodies. Then, we describe the algorithmic typing rules in Section 4.4 and prove them sound and complete with respect to the declarative rules from Chapter 3. We conclude with a discussion about efficiency of algorithmic typing of RAJA programs, given that they are finite, in Section 4.5.
Notation. In this chapter we use the letters r, s, p, q for referring to views and the letters n, m, u, w when referring to elements of D. Notice than in
other chapters we use p, q for referring to arithmetic variables and u, w for referring to view variables. Since in this chapter we do not speak about variables or constraints, there should be no room for confusion.