5 ms·

The problem, by the way, is that the use of nested literals (string and dictionary, here) causes the compiler to do a very large search to resolve the types. A

The problem, by the way, is that the use of nested literals (string and dictionary, here) causes the compiler to do a very large search to resolve the types. A quoted string, e.g. "foo", could be any type that conforms to StringLiteralConvertible. It's evaluating all permutations of potential type assignments to each literal that appears. I thought they fixed this, though. I filed it for Array<Array<Int>> long ago, and they patched that case. https://twitter.com/kongtomorrow/status/565844856690339841 https://twitter.com/kongtomorrow/status/565844856690339841

draw_down 10y ago
Jeez. Is there some sort of hint to indicate that a string is just a string? Otherwise that seems like it will always be slow.
- rsfinn 10y ago
  Well, yes; it's called type annotation (as noted in comments both here and at the original article). Telling the compiler it's "just a String" (or more precisely a dictionary containing strings) cuts the compile time to 100ms. Yes, the type inference in this case could use some improvement -- maybe guess the simplest possible interpretation first, and search the space of alternatives in the background, assuming there's a mechanism to go back for a do-over if any are eventually found...?
  - outworlder 10y ago
    The background check would still take 12 hours in this case.
    - goldenkey 10y ago
      Unless you solve the [1] Entscheidungsproblem, taking two symbolic expressions (ie. two complex types) and finding if they are equal is unsolved and thought to be equivalent to solving the halting problem. [2] SAT style solvers are the best we have at the moment. Heuristics can be improved, of course. But we are really just shooting for common use cases in a turing complete language. Which really means...in a universe of infinite code and types that can be created - we are choosing to speed up our compiler for certain ones at the dismay of others. Overall though, since Swift is going to be used for making mostly trivial mobile apps, I don't really hold the academic high hat over it, let it take all the assumptions it wants. [1] https://en.wikipedia.org/wiki/Entscheidungsproblem https://en.wikipedia.org/wiki/Entscheidungsproblem [2] https://en.wikipedia.org/wiki/Boolean_satisfiability_problem https://en.wikipedia.org/wiki/Boolean_satisfiability_problem

draw_down 10y ago

Jeez. Is there some sort of hint to indicate that a string is just a string? Otherwise that seems like it will always be slow.

rsfinn 10y ago
Well, yes; it's called type annotation (as noted in comments both here and at the original article). Telling the compiler it's "just a String" (or more precisely a dictionary containing strings) cuts the compile time to 100ms. Yes, the type inference in this case could use some improvement -- maybe guess the simplest possible interpretation first, and search the space of alternatives in the background, assuming there's a mechanism to go back for a do-over if any are eventually found...?
- outworlder 10y ago
  The background check would still take 12 hours in this case.
  - goldenkey 10y ago
    Unless you solve the [1] Entscheidungsproblem, taking two symbolic expressions (ie. two complex types) and finding if they are equal is unsolved and thought to be equivalent to solving the halting problem. [2] SAT style solvers are the best we have at the moment. Heuristics can be improved, of course. But we are really just shooting for common use cases in a turing complete language. Which really means...in a universe of infinite code and types that can be created - we are choosing to speed up our compiler for certain ones at the dismay of others. Overall though, since Swift is going to be used for making mostly trivial mobile apps, I don't really hold the academic high hat over it, let it take all the assumptions it wants. [1] https://en.wikipedia.org/wiki/Entscheidungsproblem https://en.wikipedia.org/wiki/Entscheidungsproblem [2] https://en.wikipedia.org/wiki/Boolean_satisfiability_problem https://en.wikipedia.org/wiki/Boolean_satisfiability_problem