Recompilation vs Retyping

We have been vague in our terminology for the compiler action when some property assumptions fail their checks, using the terms recompilation and retyping somewhat loosely and interchange-ably. Now we will make a distinction between the two.

Arbitrary editing may involve not only correcting erring denitions but possibly redening some denitions altogether. We need to distinguish these cases of true recompilation of def-initions where no previous property of the redened top-level identier can be allowed to be retained by the compiler, from the cases of recompilation issued by the incremental type system itself when some assumer identier fails the assumption checks. The latter is a request to simply recompute the global properties of an unchanged assumer denition in order to incorporate the eects of the changes in the properties of its neighboring nodes. None of the local compilation properties change for that denition and can be retained from the previous compilation. We will call this recomputation as

retyping

as against the former situation which we will continue to call

recompilation

.

Note that retyping is properly subsumed by recompilation so an implementation may choose to process all requests for retyping as requests for recompilation. But the distinction is necessary for the benet of an implementation that signicantly improves performance by retaining all the unchanged properties of the top-level identiers and does retyping on the y when some assumptions fail.

The other signicant dierence between retyping and recompilation is that recompilation is usually user initiated while retyping is always requested by the inference system itself. Doing retyping is safe when it is guaranteed that the given program has not changed textually. This is true for the case when no editing is allowed as well as in the general case after the compiler has been invoked on a given set of denitions²⁸. Then, all internal requests for retyping, initiated due to the failure of some assumptions, can be processed automatically within the

compiler followed by a retry for the failed checks. If during the process of retyping a type-error is encountered, the compiler can then abort the process and request a recompilation because some user editing is necessary.

3.9.2 Optimizations

It is possible to further reduce the cost of an incremental change to the program, if it does not aect the properties of other nodes. In our current scheme, whenever a node is agged for recompilation, we recompile all the denitions in its latest SCC. This is necessary when the new SCC of the node is dierent from its old one. But this may be wasteful if the editing changes do not aect the SCC or the type properties of the node. Indeed, the only computation really necessary in such cases is the compilation of the edited node itself.

Even when the type of the edited node is dierent but its SCC is the same, it may not be necessary to recompile all the other denitions in its SCC. This is because type-checking a given denition does not use any information about other denitions in its SCC (apart from the fact that they are all in the same SCC) until the latter part of algorithm

W

¹ when we unify all the assumed types of the denitions with their computed types in a unication matrix (see gure 3.5). Therefore, if we save the types of SCC identiers assumed while typing a given denition, we can use them directly in the latter part of the

W

¹ algorithm when some other identier from the same SCC is being recompiled.

We show the updated algorithm

W

² in gure 3.15, where we have also incorporated the collection of the SCC and the lower bound type assumptions introduced in section 3.7. The algorithm now works in two phases.

The rst phase computes the SCC of the given denition and compares it with its earlier value. If the SCC has changed then we proceed as before, compiling each of the denitions belonging to the new SCC afresh and accumulating their properties. We also record the locally inferred type of each identier and its local type assumptions about other identiers in its SCC for future use. If the SCC has not changed from its earlier value, then it implies that only the current binding needs to be compiled and we can use previously saved local properties of the other identiers of that SCC in the second phase, instead of computing all of them afresh.

The second phase, as before, constructs a unication matrix using the freshly computed or previously saved local properties of all the identiers of the SCC and updates their type properties. It also records the upper and the lower bound type assumptions for the identiers

DefW²(TE^i,1,SE^i,1,B^x) = PHASE I:

LetB^x be the binding `x = e^x'.

Construct the current call graphGⁱ using the free identiers (FId) property.

SCC^xi =^fz¹;:::;x;:::;z^ngbe the current strongly connected component ofxin Gⁱ.

ifSCC^{xi 6}=SE^i,1(x)^then

SCC Environment: SEⁱ=SE^i,1nSCCxi +^fz^k7!SCC^{xig 8}z^{k 2}SCC^xi.

for eachtop-level identierz^k2SCC^{xi do}

Lete^k be the RHS expressions associated withz^k. Let^{k 1};:::;^{k n} be new type variables.

ifonly xwas type-checked in PHASE I^then

Upper Bound Type Assumptions:M^x= UⁱA^ixnSCCix.

compiled in the rst phase.

The local properties we need to save in the rst phase essentially correspond to all the type information necessary to reproduce the unication matrix in the second phase. These properties are local because they are independently computed for each identier in a SCC and do not use any information about other identiers from the same SCC. We need to maintain the following two local properties.

1. Local property Local Type = (Types

;

=). For each identier

x

, we record its local type

_ix computed in the call to

W

⁰. We save this property in a map from identiers to types called Local-Type-Environment WE.

WE ²Local-Type-Environments = Identiers^,,n!Types (3

:

31) 2. Local property Local Assumptions = (Local-Type-Environments

;

=). For each identier

x

, its local assumption set

A

^local_x is a map from the identiers in its SCC to their types as inferred from the call to

W

⁰. This is later used in the second phase for unication with similar local assumptions and actual inferred type of other identiers in the same SCC.

We collect this property in Local-Assumption-Environment AE.

AE ²Local-Assumption-Environments = Identiers^,,n!Local-Type-Environments (3

:

32) Our incremental algorithm is now complete. It type-checks a set of denitions incrementally, allowing intermediate editing. It also attempts to minimize the overhead of recompilations by saving as much local information as possible while making sure that the types inferred are both sound and complete.

Dans le document An Incremental Type Inference System for the Programming Language Id (Page 108-111)