> The reason this causes issues with the type checker is it has to consider all the possible combinations of the `+` operator against all the possible types that can be represented by an inferred integer literal.
Can you please go back and read what I wrote and come up with any plausible alternative explanation for why I wrote the code that I wrote, if not to overload the HM with too many possible types to infer.
> If any of the types in the expression had an explicit type then it would be type checked basically instantly.
Did you try this?
> Its the fact that none of the values in the expression have explicit types that is causing the type checker to consider so many different combinations.
That's what I wrote in my first version. No explicit types. Then I got some comment about it needing to be an Int.
> That combination produces 59k+ permutations without even looking at non-standard library types.
Mine should reject 26439622160640 invalid typings to land on one of 31 possible well-typed readings of this program. (31 ^ 9) - 31.
Can you please go back and read what I wrote and come up with any plausible alternative explanation for why I wrote the code that I wrote, if not to overload the HM with too many possible types to infer.
> If any of the types in the expression had an explicit type then it would be type checked basically instantly.
Did you try this?
> Its the fact that none of the values in the expression have explicit types that is causing the type checker to consider so many different combinations.
That's what I wrote in my first version. No explicit types. Then I got some comment about it needing to be an Int.
> That combination produces 59k+ permutations without even looking at non-standard library types.
Mine should reject 26439622160640 invalid typings to land on one of 31 possible well-typed readings of this program. (31 ^ 9) - 31.