Temprorarily use classifier type String for internal string type.
Restore eq predicate in converts_ground_id body.
Remove origin{} block from var decl, doubtful idea.
Introduce SessionData, allow to keep arbitrary data with the session.
Extend RulesListTable with support for invalidation based on rule unique tags.
Introduce UpdatesRecorder to keep track of invalidated nodes.
Extend ApplyTemplatesStep with invalidate logic for typechecking.
Simplify design, drop unnecessary fields, minor refactorings.
Introduced a variation of conversion relation with a bit stricter boxing, needed for eq/neq.
e.g. suppose { (Number n, float f) => n == f } here f shouldn't be boxed.
Everywhere where we don't care whether it's <String> or <string> it will be handled just as String.
Where we need to discern between the cases (as in Recover), 'stringType()' dataform can be matched first.
Remove rules which handle capture+inference var case separately: it's already handled.
Remove rule with error on bound which shouldn't be triggered with new hasBound semantics.
Add symmetric rule for case value+inference var: types can be inferred nevermind relation direction.
Add rules for free vars without bounds (these ain't inference vars). Need in such vars arise when
e.g. params in classifierType terms must be somehow accessed. It's used in MethodCall rules.
During investigation a different issue has been found.
Currently, e.g. when checking args to a method call, if there's an error then inference variable remains free.
It allows to continue typechecking without spurious additional errors triggered by former ones,
but with this approach all relations must gracefully handle free vars, and it's more difficult to avoid "no type".
There's an alternative to always assign to inference var a type at hand, even it doesn't pass checks
-- but then there're more unneccessary errors. Both approaches seem valid, no action is taken now.
Enabling it with working reactivation causes spurious errors on method calls
because now it's impossible to specify feedback target for such errors fired
from reactivated rules.
The inferred type can be either capture or type variable.
This logic is covered by a new rule 'inferFromCapture'.
For examples see 'Bounds' test sample.
This inference is used in call arguments type inference.
It happens on cases when bounds arise from several places:
(a) bounds for inference variables from type vars declared in method signature (hasBound constraint)
(b) bounds of type vars used as arguments to call (typeVariableType term wiht bounds inside)
(c) bounds from captures on type variables from case (b), which come in the form of 'captureOf' term
Errors are now reported on ClassifierType instead of type argument, because some checks must be done
in captures and there's no proper way to specify origin of arg here.
Concerned with MPSCR-13 and MPSCR-16.
Previous decision that bounds on lowerBoundType must be "refined" (see 'capture' rulesList) proved to be wrong.
The source of typesystem errors is that capture isn't performed properly on arguments which has type variable type.
Fedor Isakov