Types are pushed into operators incorrectly about gradualizer HOT 6 CLOSED

Forgot to tag any of the commits with a "fix" message.

from gradualizer.

A problem is that inferring the type using type_check_expr is likely to return any() for non-trivial arguments, which will make the whole thing vacuously true.

from gradualizer.

More type inference can be done using type_check_expr(Env#env{infer = true}, Expr). Do you see any problem in doing inference in this case with respect to the graduality property AKA gradual guarrantee from the papers?

from gradualizer.

Thanks for the thorough analysis. I suspect that there are a few similar problems lurking in the code.

The solution might be to compute the greatest lower bound of the result type and number() (in the case of addition). Something like this:

L = glb(number, R)
check(A, L)
check(B, L)
------------------
check(A + B, R)

Note that the glb-operator would be a partial operation and if it doesn't find a lower bound it would result in a type error.

Your thoughts on this solution, @UlfNorell?

EDIT: The glb-operator would technically not be partial, as it can always return none(); the bottom of the subtyping hierarchy. But if glb returns none() we should report a type error because it better matches programmer expectation.

from gradualizer.

I think this makes sense, although you can construct examples where one could argue that the "right" thing to do is not failing on none():

-spec much_type_very_code(none()) -> none().
much_type_very_code(X) -> X + X.

from gradualizer.

Yes, there would have to be a special case for when the result is expected to be none().

from gradualizer.