Usually one uses Splice with LogicalItemExpression wrapping a logical variable.
Using LogicalDataForm wrapping same variable makes Splice unnecessary.
In order to keep code readable these are wrapped again in a cons list.
In general, one should avoid using bare LogicalDataForm, as these are
indistiguishable from normal LogicalVariable.
Expand macro supports dispatching by concept.
Logical variables declared on macro's body are init'ed in apply method.
Enable the hack to ensure dependencies on macro input are tracked.
Macro table can extend another macro table. All prototype template
declarations are imported automatically.
The editor now substitutes default values when entering new
expand macro/constraint filling the slots provided by the prototype.
Expand macro does not require name.
Minor editor improvements.
Expand macro template must have declaration of logicals matching
exactly the logical declarations in the prototype.
Can't refer to logicals declared directly in the prototype.
Parameters can be specified for call macro only.
Logicals can be specified for expand and call macro.
Expand macro params are treated exactly as "context"
parameters.
The old expand/call constructs are to be replaced by these.
Expand macro constraint refers to a named prototype, which
is specified in a macro table for matching concept.
Call macro constraint refers directly to a macro template.
Contex parameters are to be retired and explicit
parameters to expand macro constraint are to be used instead.
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.
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.
UnitTypecheckingCacheHolder now holds the data needed for ChangesTrackers.
This data is updated by UpdatesRecorder: different models and nodes from different roots are tracked.
ExpressionLogicalVariable is replaced with ExpressionItem wrapping
the same expression.
Fixes ensure correct application of transformations.
Late expression can't be used as "placeholder" logical item.
This expression is to be used in those rare cases
when a logical var is to be passed to an external method.
Not available within EvaluationSetting (new marker interface).
Normally logical variable (as an instance of LogicalItem)
is only to be used within a logical context.
Logical item value expr only to contain a logical variable.
SNode is supported now directly as an argument to constraint/predicate.
Pointer operation is no longer necessary, as is node-ptr<> type for logical vars.
Previously there were two independent ChangeTracker-s in UpdatesRecorder and UnitTypecheckingCacheHolder.
Now, given more elaborate logic for tracking changes to types (which includes changes in different roots)
this information must be propagated from UpdatesRecorder to cache holder,
so that if there're changes relevant for recomputing types then types cache is also invalidated.
To avoid confusion, a rule defines "target ref", which is supposed
to indicate the source code location for possible errors.
The origin node is to be referred as "origin" as before.
Temporarily rename OriginSpec's alias to "target" to reflect change
in semantics.
Sometimes UpdatesRecorder can log changes of SNodes which have same SNodeId, but different identity.
Thus reversedRequirements map returned nothing on such nodes and these require-dependencies were not handled.
Such case is described in MPSCR-42 ticket.
LogicalItemValueExpression is to play the same role as valueOf(logical)
within an instance of EvaluationSubject.
LogicalItemExpression is to represent the logical variable itself.
This is an important change in coderules syntax: all expressions to be evaluated from
constraints/predicates are to be wrapped in parentheses and preceded by dollar sign.
So, instead of eval/backticks the new syntax is to be used: $(<expression>).
Also the expressions to be passed to "feedback reporting" predicates are to be wrapped similarly.
Fedor Isakov