diff options
| author | Alasdair | 2019-02-02 01:22:39 +0000 |
|---|---|---|
| committer | Alasdair | 2019-02-02 01:31:20 +0000 |
| commit | ebfed17b57993f034d1a334014a8b9c9a542c0d5 (patch) | |
| tree | b8c39cd5783af6828867a0d8c33930bee374e011 /language/bytecode.ott | |
| parent | 4eed419ed4999a1e092b14c5e81154c97d1ec89c (diff) | |
Avoid unification on ambiguous return types
Usually we want to unify on return types, but in the case of
constraint unification (especially during rewriting) we can find
ourselves in the situation where unifying too eagerly on a return
type like bool('p & 'q) can cause us to instantiate 'p and 'q in the
wrong order (as & should really respect commutativity and
associativity during typechecking to avoid being overly brittle).
Originally I simply avoided adding cases for unify on NC_and/NC_or
and similar to avoid these cases, but this lead to the undesirable
situation where identical types wouldn't unify with each other for
an empty set of goals, which should be a trivial property of the
unification functions.
The solution is therefore to identify type variables in ambiguous
positions, and remove them from the list of goals during
unification. All type variables still have to be resolved by the
time we finish checking each application, but this has the added
bonus of making order much less important when it comes to
instantiating type variables.
Currently I am overly conservative about what qualifies as
ambigious, but this set should be expanded
Diffstat (limited to 'language/bytecode.ott')
0 files changed, 0 insertions, 0 deletions
