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.
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)
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])`.
Treat a language and its sidekick (if any) as a single vertex.
Add all extended languages to the pool before building the graph.
Drop dubious invariant check.
Fix the second pass in findAspectCliques ingnoring the fact
that there might be leafs without aspects.
Now algorithm for finding aspect cliques includes 3 stages:
1) topological sort (as before)
2) bottom-up pass with initial assignment of clique ids (as before)
3) top-down pass (i.e. in reverse topo sort order) (added stage)
The 3rd stage handles case when hierarchy of langs with
required aspect include branching point (with no join further down),
as in the case of closuresExt & collectionsExt both extending blExt,
but unrelated to each other (neither extends the other).
Consider a case when j.m.bl.closuresExt is added as a sidekick,
then extended by it langs (e.g. j.m.baseLanguageExt) must be added also,
because they can contain crucial parts of extended aspects.
Fedor Isakov