ExpandMacroTemplate to be used for dispatching macro invocations
based on the concept of the specified node.
Prototype is an abstraction to be implemented by
specific templates.
Call macros are to be parameterized with logicals and other parameters.
To replace combined expand/call macros causing confusion.
Context parameters to be passed explicitly.
Problem lies in that journal doesn't track all justifications
for reactivated occurrences. For a parent of such occurrence
its original activating match is considered, while
justifications from the Reactivating match aren't tracked.
So, this information about immediate reactivating parent is lost.
lambdacalc lang typesystem heavily uses reactivation, so it fails.
Now Evidence isn't unique for each Chunk: Occurrence Chunks fully
share evidence and justifications with their activating match.
So, less collections of justifications are created, approx. 2 times less.
Relates to machinery introduced in MPSCR-47.
Previously parent match was maintained in Controller on Java call stack.
Now this stack of parent matches is maintained manually in MatchJournal.
So MatchJournal gains new invariant: parentChunk()
returns correct parent after each logMatch() call.
Several tests fail, also need to maintain this
invariant after logActivation() calls.
Modified TYPECHECK query to include "checkingScope" query parameter:
it is a root node for which program is generated (for local typechecking it's local node).
Rules additionally match on a constraint `checkDecls(node<>)` bearing this node,
so while rules will be generated for all scopes, only those in applicable scopes will run.
Also split rule for EnumConstantDeclaration on declration checking and just typing rule.
Now primitive types in conversion relation are handled before processing of free inference vars.
So primitive types first get boxed and only then these terms can be unified with inference vars.
Fixes typechecking tests.
Type var bounds are produced together with genDecls at program start.
Now bound of type var is captured only when needed --
inside convertsTo check, leaving typeVarBound intact.
Since it's no longer possible to have cyclic terms,
the term for type variable type has to be refactored:
the bound information is attached via typeVarBound constraint
on the type.
Processing a match may fail because of unification went wrong.
To avoid these transient failures to propagate to program trace,
context can optionally abort instead of fail, which is then
recovered from.
Scheduler in rxjava2-swing seems to cause a peculiar bug
that is difficult to reproduce.
Seems like AtomicReference or one of its subclasses
gets itself as the value, which triggers infinite recursion.
Fedor Isakov