[bitc-dev] Polymorphism by polyinstantiation -- take 3

[Swaroop Sridhar]

> Swaroop Sridhar wrote:

> So, the conclusion is that even though the unified-AST 
> can be formed on demand, R&Ting the new definitions 
> must be done in a totally-rich environment similar to the 
> take-1-big-AST's environment.


How do we build the full environment? Of course, for the first time, we 
must build it by iterating over all the environments of all interfaces 
and source modules and build a new environment based on their FQNs. 
However, we don't want to do it every time we enter the instantiator. 
Since here is that the interface-list and the source-module list are 
append-only -- they are append-only in the case of an interactive 
interpreter; in the case of static compiler, these lists are frozen -- 
we can note the previously last processed indices into these lists, and 
only processes additions each time.

In the case of a compiler, interfaces and source module environments are 
immutable once the entire module is processed. Therefore, the index into 
the module list will suffice. However, in the case of an interactive 
interpreter, there is exactly one unit of compilation that is ever 
expanding, and the instantiator must cope with this. There are two ways 
in which we can think about the interactive loop.

i) Some units of compilation are "dynamic" and the instantiator must 
process them every-time (as an optimization, we can remember their last 
processed environment index, and process only the new ones).

ii) The interactive loop is not one unit of compilation, but it is an 
arrangement of nested interfaces, each of which is by itself frozen. 
That is, _every_ new definition has its own interface, and will import 
the interface introduced in the previous step, and `use' all the forms 
in it.

Option (i) is probably better from an implementation standpoint.

After we have the grand-environment built, we make a small modification 
to the instantiation algorithm.

> 6) R&T the new definition in the *original* environment -- that was
>    saved as a pointer in its AST -- so that the types in the body of 
>    the definition get clamped aiding further instantiation. After 
>    successful R&T, throw away any changes to the environment.

Step 6 must now be changed to:

6) R&T the new definition in the grand-environment so that the types in
    the body of the definition get clamped aiding further instantiation.
    After successful R&T, throw away any changes to the environment.

This story does not quite work directly for let-polyinstantiation, and 
needs some adjustment, but that is the topic of next discussion.

Swaroop.