Try to improve information flow down through 'branching' constructs #5984
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds some cases to
checkWantedthat try to improve the flow of type information down through some constructs that could be thought of as branches. The primary one isifexpressions. Previously the checking ofwould just be handled like
ifFun b t f, whereifFun : Boolean -> a -> a -> a. But this means thattandfare synthesized, even in checking mode. Instead, now checking an if statement againstTwill checktandfagainstT.Similarly, list literals are now checked against
Tby determining an element type and checking each element against that type. IfTis of the formList E, then the element type is of courseE. IfTis a variable, then we make up a new variable, unifyTwithList e, then check againste.This allows type information from annotations to successfully flow down through more varieties of expressions, which helps annotations to resolve duplicate ability variable problems in more situations. Previously, annotations on these expressions wouldn't do any good, because they flip over into synthesis mode, which gathers up multiple ability variables and then gets stuck, even if the annotation would prune away most of those variables when pushed through.
One thing to note is that the new
ifchecking mode will sometimes reject things that happened to work before. For instance, if you write:Then it used to work, and now doesn't. However, the way this used to work is almost an accident. If you instead tried to write:
then it wouldn't work in the past, because the order the expression gets inferred in causes the problem. Now both fail, and can be resolved by annotating the
if.There are a couple other tweaks to try to maintain error message output. One message changed slightly, but it's essentially the same (just focusing on a subexpression).