|
|
|
|
|
by mrkeen
740 days ago
|
|
> 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. |
|
Trying it locally for example:
Which is roughly the in line with the numbers in the original post.