Jesse Phillips Wrote: > This is what the "Open Scalable Language Toolchains" talk is about > http://vimeo.com/16069687 > > The idea is that the compile has the job of compiling the program and > providing information about the program to allow other tools to make use of > the information without their own lex/parser/analysis work. Meaning the > compile should not have an advantage.
Yes, I like that idea very much. I wouldn't mind having a D toolchain like that. Seems modular and nice. The point is not needing to manually write makefiles, or having different and conflicting ways to build source code. The D language itself is all that is needed for declaring dependencies by using import statements, and the compiler could very well traverse these files along the way. > Lastly Walter has completely different reasons for not wanting to have "auto > find" in the compiler. It will become yet another magic black box that will > still confuse people when it fails. I'm not talking about any magic at all. Just plain D semantics. Make use of it. > > 2) The compiler can do more optimisation, inlining, reduction and > > refactoring. The compiler also knows which code interacts with other code > > and can use that information for cache-specific optimisations. Vladimir > > suggested it would open the door to new language features (like virtual > > templated methods). Generally I think it would be good for templates, > > mixins and the like. In the TDPL book Andrei makes hints about future > > AST-introspection functionality. Surely access to the source would benefit > > from this. > > No, you do not get optimization benefits from how the files are stored on the > disk. What Vladimir was talking about was the restriction that compilation > unit was the module. DMD already provides many of these benefits if you just > list all the files you want compiled on the command line. I never claimed that file storage was an optimisation. The compiler can optimise better by seeing more source code (or a greater AST if you will) at compile time. Inlining, for example, can only occur within a compilation unit. I'm arguing that a file is not the optimal compilation unit. Computers today have enough memory to hold the entire program in memory while doing the compilation. It should be up to the compiler to make the best of it. If you need to manually list the files then, well, you do unnecessary labour. > > It would simplify error messages now caused by the linker. Names within a > > program wouldn't need to be mangled. More information about the caller / > > callee would also be available at the point of error. > > Nope, because the module you are looking for could be in a library somewhere, > and if you forget to point the linker to it, you'll still get linker errors. I didn't say "no linking errors". I said simpler errors messages, as in easier to understand. It could, for example, say where you tried to access a particular function: file and line number. A linker alone cannot say that. Also, you wouldn't have to tell the linker anything other than where your libraries resides. It would find the correct ones based on their modules' names. > > It would also be of great help to third-party developers. Static code > > analysers (for performance, correctness, bugs, documentation etc), packet > > managers... They could all benefit from the simpler structure. They > > wouldn't have to guess what code is used or built (by matching names > > themselves or trying to interpret makefiles). > > As I said, have all these tools assume such a structure. If people aren't > already using the layout, they will if they want to use these tools. I > believe that is how using the import path already works in dmd. Standards are better than assumptions. > No no no, having git installed on the system is completely different from > have a dev environment for Phobos. You'd have to download all the Phobos > files and Druntime into their proper location and any other > dependencies/issues you run into when you try and build it. Then you would > need a dmd installation which used your custom test build of Phobos. It seems I misunderstood you. Of course you have to download all dependencies before you build something. Otherwise it wouldn't be a dependency, would it? How many megabytes are these, 15? Frankly, I don't see the problem. What is it really that you don't like? I'm trying to argue for less manual dependency juggling by using the specification that is already there, your source code. The second thing, I guess, is not being overly restrictive to files as compilation units. It made sense long ago, but today it is arbitrary. Remember, C/C++ even compels you to declare your symbols in a particular order -- probably because of how the parsing algorithm was conceived at the time. It's unfortunate when it becomes language specification.
