The solution for inferring the type of a closure parameter using
auxiliary typeScheme/2 constraint and processing all "inference sites"
doesn't work for some situations, such as closure returning a closure with
untyped (var) parameter.
The new solution uses regular typeOf/2 constraint and calculates the
closure type assuming a variable as the return type. This must not be inferred from the context.
Avoid assigning a type to the closure the 2nd time, which
causes a cascade of typeOf/2 activations.
Replace the ad-hoc solution with typeScheme/2 cint to be used
on par with type/2. Type inference sites to be extended
with rules to process typeScheme.
Introduce hasTarget and resolveVar constraints for delayed resolving
of inference variables. In invocation context variables are not
inferred eagerly, but wait for the end of all conversions, and then
resolved via resolveVar.
On looking up the default functional classifier corresponding to a
function type, the classifier's type parameters are to be appropriately
populated from the function type.
Drop node-ptr in node features, macro calls.
Drop node-ptr types in rule templates and recover closures,
fix BiConsumer params
Drop node-ptr// refs where appropriate.
Drop pointer operations from macro calls and term ctor's; add resolve to FunctionTypeLookup static table.
Drop node pointer operations from constraints, add require statements in SModel types macro table.
When inferencing the type of a closure within a method call context,
it's important to strip occasional contravariant indicator from the
closure's input variable.
A method may declare its argument to be an SMI with the type(s) of
its functional method's arguments as ? super T to facilitate subtyping.
This must not affect the inferred type of the closure's input variable.
These unused in bodies constraints were for tracking certain
cases of incremental dependencies. Now it's handled by minor
algorithm extension introduced in several previous commits.
Add 'genDecl' constraint in heads of toFunctionalCls* rules
to handle incremental changes to respective classifier.
Also fail instead of just reporting error to break execution and
report on correct node according to calling rule.
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)
Fedor Isakov