Expand macro prototype: "virtual macro".
Expand macro template: "override".
Override macro displays parameters declared in the prototype as R/O.
Introduce "usages" of prototype parameters to serve as local anchors;
this avoids problems with generation.
The existing code is going to work as before, but marked as erroneous
until migrated.
The deisgn decision to have only one instance of QueryTemplate
leads to the necessity to keep AspectClique separated for
every "typesystem". Whereas QueryTemplate are really perfectly
composable, and thus only one AspectClique is neeeded.
Also drop a rudimentary unused feature.
Instead of the hack that that uses session parameters to pass
parameters to expandMacro, use directly `withParams` method
on macro token. All parameters are mapped to corresponding fields.
Introduce CustomSessionParameter to access parameters in
TemplateApplicationSession.
Expand macro passes the rule's input to nested macro calls.
This adds the macro input as the dependency of the rule's input.
As a result, incremental processing starts working in some cases.
Enable recording the dependencies while expanding macro.
Rename/refactor operations in UpdatesRecorder to reflect the intent
of adding the dependencies.
Fix rule basetag generation to coincide with templateName
Needed for PrincipalStore (occurrence cache) which uses
info about occurrence source rule template name.
A query may be invoked without the input node, thus dispatching
macros by the specified concept. The concept must be taken into
account when calculating the "diff", so that the old (stale)
rules don't override the updated ones.
Specifically treat convertsTo of LogicalType to ClassifierType, support
convertsTo classifier type w/o specified classifier.
Fix typeOf LogicalItemValueExpression by to rely on logical's type.
Accept LogicalItem in LogicalItemValueExpression's logical slot to enable
replacement of it with an expression at generation time.
Also process expand macro input for rule hash,
so that changed query rules (like one in testlang) get into
RulesDiff and could be updated with Preamble processing.
Ensure the order of rules in the resulting plan follows the priorities
set forward by extends relationship b/w languages. So that even if
rule template tables are unrelated, they are still ordered according to
language extension graph.
Ensure the order of rule lists in the resulting plan is stable b/w invocations of
RulesPlanHandler.allPlans().
Ensure the order of aspects in AspectClique is stable b/w invocations
of buildClique().
Associate RuleTemplatesTable with Manifest, and Manifest with CoderulesAspect.
Tentatively rename RulesList (the runtime object) to RulesPlan,
RulesListTable to RulesPlanHandler.
Fedor Isakov