4 ms·

Compiler can ignore unused dependencies and variables, since it detects them anyway and still guarantee that no extra code will be compiled when building the pr

by zzzcpan 13y ago

Compiler can ignore unused dependencies and variables, since it detects them anyway and still guarantee that no extra code will be compiled when building the program, which minimizes compilation time. So the argument itself is flawed and only gives a perception of rational decision, while not actually being rational.

scott_s 13y ago
The compiler cannot ignore an unused dependency. The compiler must first process the imported packages, then compile the current package. It only knows that an imported package was not used until after it has finished compiling the entire current package.
- zzzcpan 13y ago
  I don't know how Go compiler works, but I don't see a problem detecting unused dependencies very early just by walking an AST of current package, since in Go you have to specify package name explicitly in order to use something from it (well, not all the time, but almost all the time). And even this is probably unnecessary, you only have to process additional unused dependencies in your current package, other packages already did. Anyway, it's just a technical problem with a few simple solutions.
  - scott_s 13y ago
    Packages are processed before the current package is compiled. You can only establish that packages are unused after compiling the current package. So, you will still process unused packages. That is exactly the problem they want to avoid. Your solution is, I think, to scan the current package twice: once to establish which packages are used, then process the packages, then actually compile the current package. But now you're scanning through each package twice, which will significantly add to compilation times, and make the compilation process more convoluted. Their solution is, I think, far simpler. You're dismissing the problem, but I'm not sure you understand what the problem is.
    - zzzcpan 13y ago
      I just checked, they actually do it very early, similar to what I suggested, but instead of ignoring and producing warning they simply throw yyerror and they do that without even walking a tree, but during parsing. So I'm still correct. You can verify it by executing "go run .." multiple times with and without import error, you'll notice how fast it generates "imported but not used" error, compared to actual compilation. And the whole point of their solution has absolutely nothing to do with unused imports and variables. They are just reusing object files without recompiling and they can't have circular dependencies to do that. There is nothing more to it.
      - scott_s 13y ago
        Based on your statements, I am not confident that you understand the compilation process and the terminology we use to describe it. In particular, I don't how you can say they don't "walk a tree," but do it "during parsing." Nor is timing the compiler sufficient to determine this kind of behavior. In order to establish that a particular package was unused, they must: at least parse the header for that package, and parse the entirety of this package. Parsing the unnecessary package is the problem they want to avoid. Because that package could also have unnecessary packages, in large projects you could end up parsing more unnecessary packages than necessary packages. This isn't even considering the building process, which is what actually produces the headers that get parsed for packages. So, if you import a package and it has not been built yet, it will build it. If that was an unnecessary package, then there's even more wasted time.
        zzzcpan 13y ago
        What can possibly be so confusing about parsing and walking a tree? Scanner (lexer) and parser are the very first stages of compilation. Parser produces syntax tree and some other stuff, like symbol table, there is no alternative terminology. Walking a tree cannot have multiple meanings either. Most of the work is done after parsing. And timing a compiler is sufficient to understand exactly that, since you claimed, that detection of unused dependencies required package to be compiled, which is of course total bullshit. For most unused packages even parsing is not required, you can look at symbols during parsing and set "used" flag for every package, that was used and only parse it if it has this flag set. And parsing is not what they want to avoid. Parsing is cheap. They want to avoid full-blown compilation of unused packages.
deleted 13y ago
[deleted]

by zzzcpan 13y ago

scott_s 13y ago

The compiler cannot ignore an unused dependency. The compiler must first process the imported packages, then compile the current package. It only knows that an imported package was not used until after it has finished compiling the entire current package.

zzzcpan 13y ago
I don't know how Go compiler works, but I don't see a problem detecting unused dependencies very early just by walking an AST of current package, since in Go you have to specify package name explicitly in order to use something from it (well, not all the time, but almost all the time). And even this is probably unnecessary, you only have to process additional unused dependencies in your current package, other packages already did. Anyway, it's just a technical problem with a few simple solutions.
- scott_s 13y ago
  Packages are processed before the current package is compiled. You can only establish that packages are unused after compiling the current package. So, you will still process unused packages. That is exactly the problem they want to avoid. Your solution is, I think, to scan the current package twice: once to establish which packages are used, then process the packages, then actually compile the current package. But now you're scanning through each package twice, which will significantly add to compilation times, and make the compilation process more convoluted. Their solution is, I think, far simpler. You're dismissing the problem, but I'm not sure you understand what the problem is.
  - zzzcpan 13y ago
    I just checked, they actually do it very early, similar to what I suggested, but instead of ignoring and producing warning they simply throw yyerror and they do that without even walking a tree, but during parsing. So I'm still correct. You can verify it by executing "go run .." multiple times with and without import error, you'll notice how fast it generates "imported but not used" error, compared to actual compilation. And the whole point of their solution has absolutely nothing to do with unused imports and variables. They are just reusing object files without recompiling and they can't have circular dependencies to do that. There is nothing more to it.
    - scott_s 13y ago
      Based on your statements, I am not confident that you understand the compilation process and the terminology we use to describe it. In particular, I don't how you can say they don't "walk a tree," but do it "during parsing." Nor is timing the compiler sufficient to determine this kind of behavior. In order to establish that a particular package was unused, they must: at least parse the header for that package, and parse the entirety of this package. Parsing the unnecessary package is the problem they want to avoid. Because that package could also have unnecessary packages, in large projects you could end up parsing more unnecessary packages than necessary packages. This isn't even considering the building process, which is what actually produces the headers that get parsed for packages. So, if you import a package and it has not been built yet, it will build it. If that was an unnecessary package, then there's even more wasted time.
      - zzzcpan 13y ago
        What can possibly be so confusing about parsing and walking a tree? Scanner (lexer) and parser are the very first stages of compilation. Parser produces syntax tree and some other stuff, like symbol table, there is no alternative terminology. Walking a tree cannot have multiple meanings either. Most of the work is done after parsing. And timing a compiler is sufficient to understand exactly that, since you claimed, that detection of unused dependencies required package to be compiled, which is of course total bullshit. For most unused packages even parsing is not required, you can look at symbols during parsing and set "used" flag for every package, that was used and only parse it if it has this flag set. And parsing is not what they want to avoid. Parsing is cheap. They want to avoid full-blown compilation of unused packages.

deleted 13y ago

[deleted]