Looks like they are trying to rewrite Python.
Apple's Module proposal to replace headers for C-based languages [pdf]
81–90 of 187 posts
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#82Earlier quoted context omitted.
> Wouldn't adding a preprocessor directive like "#include_once " solve this? No -- the point is still that you recompile each header for each source file that uses it. Running the compiler N times (once for each source file) costs M x N, not M + N. > Why is this? I agree with you here, I think this dismissal of precompiled headers needs a more thorough explanation (but perhaps it was given orally in the talk).
> Why is this? To get any benefit from the use of precompiled headers at all, you need to include practically every single header in your project in your precompiled header. Doing this is the opposite of modular.... it tightly couples each of your N compilation units with each of the M modules (changing any one of the modules bundled in the pch will force you to recompile all compilation units using the pch.)
This is an implementation detail that is fixable without language changes: it is often the case that two header files are semantically disjoint and the compiler (partly the preprocessor: you'd have to more incrementally update the compile after each include) could keep track of these relationships so it could safely merge results later; it is certainly no harder than a "merge" comparison of two sorted token lists. Their goals do go past this (their issues about "resiliency"), but it is seems disingenuous to include these performance issues when there are less drastic solutions.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#83Earlier quoted context omitted.
WRT compiler overhead, this is an asymptotic improvement, not just a constant factor. If this can get my 30-second to 20-minute compiles (depending on what's changed since the last make) down to the compile-duration range of Go (which uses this kind of dependency management for compiler performance reasons) that completely changes the workflows that are possible. But yeah - the standardisation issue is worrying, alth…
Compile time is usually fine if you build your code so that dependencies are simple as intermediate .o files are only built in dependency chains. Link time is much higher on larger projects, which this still fails to solve. Knowing your shit gets you further than language changes here. For ref, I've been writing c since 1986 and I've seen proposals like this come and go lots and every one doesn't end up with an impro…
I haven't used C++ recently, and never in truly large projects, but what I do remember is that that "build your code so that dependencies are simple" is not something you get for free, certainly not with C++.
I also think that Apple wants every compilation speed improvement it can find, so that it can improve syntax coloring and error highlighting in (almost) real time while you are editing.
Finally, I don't think this really is a proposal. Apple shows its intent earlier than they did with WebKit, but read that last slide: "clang implementation underway".
I expect they will listen to feedback and change this if people propose real improvements, but I think it is a given that this will be in clang soon, and also that it will be used in clang, LLVM, and WebKit. From there, chances are it will spread, either via tools that use WebKit or LLVM, or because of superior compilation speed.
How soon that 'soon' will be, I don't know. Implementation may not be as simple as it looks.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#84Anyone know where I can read more detail about this proposal? It looks really interesting, but there are a couple of things I'm not clear on from the pdf: How do you get away from creating a header file for a closed source module? Without a header, how would users of your module know what they can call? Can you perform reflection on a module to inspect it? Is there some kind of tool proposed, like javadoc or pydoc, t…
It looks like the old #include style will still be available where you can't use packages, and it seemed to me that you only needed the .h files for the generation of the modules, not the source .c files.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#85Earlier quoted context omitted.
I don't see why this is at cross purposes. The point of this is to do the following transformation to the Big O numbers M x N -> M + N With M being numbers of included headers and N being the number of files including that header. I think that would be solving that mangling of stuff not working at cross purposes. The point is to make it so you go over each file once, rather than multiplicatively many as you do now.
That's what the previous best practices (impl pointers and such) did with C++ before; the goal of some of those practices was to minimize the constant factors. I may be misreading how "modules" work, but they seem to accept that sprawling dependencies will get pulled in (if only once).
I think the submodule system will help address this issue. People will often import the entire standard library just for one small feature. If submodules are implemented correctly we can reduce that.
I'm a little wary at such a major change to C, though.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#86Maybe all the things they figured out in pascal aren't that bad.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#87Earlier quoted context omitted.
> On the other hand: if someone would do the equivalent to their browser, people would call it fragmentation. I haven’t seen many people calling Dart, Pepper, Native Client or the Chrome Web Store “fragmentation”.
With "the equivalent" I wasn't thinking about creating entirely new ecosystems; I was thinking of tweaking the existing ecosystem to favor one's own tool chain. The moment somebody writes the first module, the world sees the first 'best compiled with clang' code. Once that code uses #import to improve compilation speed, that could become 'must be compiled with clang'. That, IMO, is similar to adding an extra tag to y…
The ecosystem is the www, not Javascript and HTML, so those are all tweaking and extending the ecosystem.
The moment somebody writes the first Dart or NaCl based website or the first Pepper plugin, the world sees yet another (not the first) "must be viewed with Chrome".
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#88I thought one of the points of headers system was you could use the code without having to slog through all the source. Thinking about my trips to /usr/include, those headers weren't that useful for coding with but you could get constants and function names at least.
C# together with visual studio solves this in an amazing way. You can browse .NET DLL-files as if they were source files, with only public members being visible and without the function bodies. Good for finding function names and constants.
I can't believe nobody else is using the same system, using "go to definition" on a library function is just as natural as using it on one of your own functions. Only difference is in the second case you see the actual code of the function instead of just the function header.
(Replace .NET DLL-files with these new "modules" to make this applicable to C)
Ps. even if you do have the source, in most editors you can collapse the code to hide everything so you don't have to "slog through all the source".
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#89While LLVM authors probably know best, I don't understand some of his criticisms on the "Inherently Non-Scalable" slide. • M headers with N source files -> M x N build cost It's only MxN if there is no use of the "#ifndef _HEADER_H" workaround that he mentioned earlier. Wouldn't adding a preprocessor directive like "#include_once " solve this? Alternatively, these guards could be added to the headers themselves withou…
> Wouldn't adding a preprocessor directive like "#include_once " solve this? No -- the point is still that you recompile each header for each source file that uses it. Running the compiler N times (once for each source file) costs M x N, not M + N. > Why is this? I agree with you here, I think this dismissal of precompiled headers needs a more thorough explanation (but perhaps it was given orally in the talk).
No -- the point is still that you recompile each header for each source file that uses it.
You're right, I was thinking about this wrong. I was thinking that the main cost is not the direct includes (M x N), but that each header further includes other headers. (M x N^O). One-time includes prevent the exponential explosion, but you are still left with M x N. But I tend to use ccache to avoid unnecessary recompilations, so I rarely feel the brunt of this.
Re: Apple's Module proposal to replace headers for C-based languages [pdf]
#90I hear D is backwards compatible with C (and C++?). They already have modules: http://dlang.org/module.html . I should use D more often.