Replace unification with the intent of capturing term feature
with match constraint.
Drop unused term feature from head pattern.
Provide better context for failed class inheritance test.
Term constructor creates all features with default values where
not overridden. The default values for "value" and "child"
features are wildcards for now (TBD), the default value for
list feature is an empty list.
The rationale is that a rule's head defining term pattern with
a logical variable capturing list feature will not be matched
with a free logical variable. Thus, to avoid having to always
explicitly specify all term features, a term constructor that
is not a pattern must use the default values for non-overridden
features.
Match constraint is provided for use cases where the intention
is to pattern-match a term capturing features into logical
variables.
A term constructor in the right-hand side of match constraint
is a pattern, and all its non-overridden features are
to be defined as wildcards.
Some time ago "mixed" matches (with both principal and non-principal heads)
were allowed and are handled by Journal. So now principal constraints
can lead to non-principal matches, which renders assert invalid.
(Relevant for MPSCR-62)
It's possible to activate constraints in macros, so they must be also handled.
Also restrict a bit principal rules analysis: consider only rules with template input.
DataProvider is an abstract way to associate any data with the
runtime object, such as Supervisor.
Predicate solvers that ought to be stateful may make use of
DataProvider to access the internal state.
Hierarchy graph vertex can represent LUB as a simple
collection of inheritance paths.
Abstract intefaces allow to model operations such as finding
the LUB in an abstract way.
Greatly simplify code.
It makes definition of principal constraint clearer:
principal constraint is a constraint that has at least one arg
of type node<> and passes to it ruleOrigin in at least one rule.
Such constraints are most likely meant to define relations
of nodes to terms, e.g. `typeOf` -- which is what we're interested in.
At the same time semantics of values inside terms is less defined.
TermFeatures are also untyped, and so complete analysis of
ValueFeatures would require full code traversal of coderules program
to find out whether a value feature is used to carry smth of `node` type.
Relevant to MPSCR-62.
Now rules concerned with generics handle type vars from enclosing scope.
Complete typechecking of BaseMethodCall: consider static/nonstatic cases.
Complete typechecking for class creators, handling type vars from cls & ctor.
Refactor rules for EnumConstantDeccl & ClassifierType.
Related to MPSCR-20 & MPSCR-29.
Motivation is that implicit (non-overriden) list features must unify
with list of any length. Consider an example:
`classifier(cls: node-ptr/A/) = classifier(cls: node-ptr/A/ param: [B,C])`
With previous approach it would fail, which seems counter-intuitive to me.
So, if empty list (e.g. of type parameters) is meant, then it must be
specified explicitly.
There's one thing to remember, though: such wildcard list features
won't match with MetaLogicalArrays in rule heads.
(e.g. see dpromote_* rules and consider what happens when
a classifier with unbound `parameter` feature comes in)
Introduce common 'parameterized(child typeParams)' term
to allow unifying processing of GenericDeclarations.
Collect type variables from enclosing GenericDeclaration.
Will be needed to simplify instantiation of nested generic decls
(e.g. generic method inside generic class) using `genDecl`
machinery instead of TypeVarSubstitution.
Avoides the need to exactly duplicate features of ancestors.
Opens possibility to match on super-terms
with partially provided (overriden) features.
For example, suppose there's `typeParameterized(child: param)`
term which is extended by `classifier` and `methodSignature`.
Then it becomes possible to write a common rule for both terms,
matching on `typeParameterized(param=[Smth])`.
Fedor Isakov