[bitc-dev] Polymorphism by polyinstantiation -- take 3
swaroop.sridhar at gmail.com
Fri Jul 28 01:25:29 EDT 2006
> 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
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.
More information about the bitc-dev