| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Free symbols no longer carry signatures in their constructors.
Previously to reify a free symbol (i.e. to generate a ValDef that creates it)
one had to reify sym.info first. However reification of sym.info might lead to
unexpected side effects, including stack overflows, if reification of sym.info
recursively required reifying sym itself.
Now it's not a problem. First we reify a "header" of a free symbol
by emitting something like:
val free$Foo1 = build.newFreeTerm("Foo", Foo.this, NoFlags)`
Afterwards, when doing code generation for the reification symbol table, we
populate free symbols by inserting calls to `build.setTypeSignature($sym.info)`
This techniques transforms recursion into memoized iteration, because even if
reifying sym.info indirectly requires reification of sym itself, we remember
that we already reified sym and simply return things like Ident(free$Foo1).
2) Unfortunately I haven't been able to get rid of recursion completely.
Since some symbols (e.g. local classes) aren't pickled, we need to recreate
them during reification (this is necessary e.g. to reify RefinedTypes).
Reifier uses a special function, named `reifySymDef`, for that purpose.
Here's an example of how it works:
val symdef$_1 = build.newNestedSymbol(free$U1, newTypeName("_"),
NoPosition, DEFERRED | PARAM, false);
`reifySymDef` expands into a call to `newNestedSymbol`, which requires an owner
This essentially turns `reifySymDef` into a recursion of `reifySymDef` calls,
so that the entire owner chain get reified.
This is an implementation strategy that was employed in the first revision
of the reifier written by Martin, and personally I have no clue whether it's
really necessary to reify the parents. I leave this as a future work.
3) When working with free symbols, it's necessary to attach free symbols
to their reification. This is required in obscure nested reification scenarios,
when a symbol that was free for an inner reifee is no longer free for an outer
reifee. In that case we need to remove that free symbol from the symbol table
of the inner reification.
Back then we didn't have tree attachments, so I had to introduce a phantom
"value" parameter for `newFreeType` to keep track of the original symbols for
free types. Now when we have attachments, this is no longer necessary and
allowed me to clean up the code.
|
