undefined | Better HN

0 pointsash_gti1y ago0 comments

The type is an inferred integer literal in swift (in the swift standard this is the `ExpressibleByIntegerLiteral`, the string literals are `ExpressibleByStringLiteral` types).

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.

This is whats causing the type checker to try every possible combination of types implementing the `+` operator, types implementing `ExpressibleByIntegerLiteral` and `ExpressibleByStringLiteral` in the standard library. That combination produces 59k+ permutations without even looking at non-standard library types.

If any of the types in the expression had an explicit type then it would be type checked basically instantly. 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.

0 comments

mrkeen1y 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.

ash_gtiOP1y ago

The haskell source has `let channel = "11"` vs `let channel = 11`. The example from the post is an example that looks like it should be pretty straight forward but the swift compiler falls over when you try it.

Trying it locally for example:

  # Original example
  $ time swiftc -typecheck - <<-HERE
  let address = "127.0.0.1"
  let username = "steve"
  let password = "1234"
  let channel = 11
  
  let url = "http://" + username
              + ":" + password
              + "@" + address
              + "/api/" + channel        
              + "/picture"
  
  print(url)
  
  HERE
  <stdin>:6:5: error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
   4 | let channel = 11
   5 | 
   6 | let url = "http://" + username 
     |     `- error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions
   7 |             + ":" + password 
   8 |             + "@" + address 
  swiftc -typecheck - <<<''  36.38s user 1.40s system 96% cpu 39.154 total
  
  # Adding a type to one of the expression values
  $ time swiftc -typecheck - <<-HERE
  let address = "127.0.0.1"
  let username = "steve"
  let password = "1234"
  let channel = 11
  
  let url = "http://" + username
              + ":" + password
              + "@" + address
              + "/api/" + String(channel)
              + "/picture"

  print(url)
  
  HERE
  swiftc -typecheck - <<<''  0.11s user 0.03s system 74% cpu 0.192 total

Which is roughly the in line with the numbers in the original post.

Olreich1y ago

Type checking is horribly slow in Swift if 59k things to check causes 30 seconds of slowdown. That would mean that on a 4ghz processor it requites more than 2 billion operations per check. That’s insane no matter how you slice it.

j / k navigate · click thread line to collapse