C and Objective-C Modules Proposal
Doug Gregor, who works on Clang at Apple (via Hacker News):
The C preprocessor has long been a source of problems for programmers and tools alike. Programmers must contend with widespread macro pollution and include-ordering problems due to ill-behaved headers. Developers habitually employ various preprocessor workarounds, such as LONG_MACRO_PREFIXES, include guards, and the occasional #undef of a library macro to mitigate these problems. Tools, on the other hand, must cope with the inherent scalability problems associated with parsing the same headers repeatedly, because each different preprocessing context could effect how a header is interpreted---even though the programmer rarely wants it. Modules seeks to solve this problem by isolating the interface of a particular library and compiling it (once) into an efficient, serialized representation that can be efficiently imported whenever that library is used, improving both the programmer's experience and the scalability of the compilation process.
There’s a PDF of his slides. This seems like a great idea that will improve compilation times while maintaining compatibility.
Update (2012-12-10): Here’s the thread on Lambda the Ultimate.
7 Comments RSS · Twitter
As always: If they want to make C (and Objective-C) programming (and compiling) better, laudable. If they imagine that they're getting close enough to "fix C", it's a step on the way in the same way that standing on a chair gets you closer to the moon.
Best scenario: they want to improve C now and level the playing field for what will come down the road.
That came off like I think this is something unimpressive that they shouldn't do, which is wrong. It's a great idea and will probably speed up compilers and open up IDEs to do better things.
But make C not C in the interest of growing a modern, unencumbered language that would complement today's C well, it will not; nor will probably ten of these sorts of ideas.
@Jesper I think they’re doing it incrementally in a slightly different sense. Objective-C will always be a “C”; they can’t fix that. But they can evolve it to the point that a file written using a well-behaved subset of Objective-C (for example using modules instead of #import, restrictions on pointer use) is also a subset of xlang.
Fair enough, but at some point, that'd have to include pointer elision for objects (or just porting `auto` variable inference). Otherwise xlang would start out with "NSArray *x" and there wouldn't really be a new language at all. My conception of xlang has been that it will not necessarily be beholden to anything that came before it because Objective-C will have its back for those cases; it'll be much more driven by the shape of the frameworks. xlang showing up with a pointer star is like everyone showing up to a constitutional convention with the confederate flag; a sign that while there may well be some changes happening, chances are it's not going to be progress.
“Objective-C will always be a “C”; they can’t fix that.”
Is there something to be fixed ? I always though it was a feature, not a design problem. Being fully compatible with C is something very very useful in Obj-C, and that probably one of the reason it was adopted in the first place.
About "pointer elision for objects", I read some discussion about removing the need to declare objects as pointer, but I think the conclusion was that it cannot be done without breaking compatibility with existing sources (I don't remember exactly why though).
How, and about this Module proposal, this is in fact an old C++ proposal that was not mature enough to be included in C++11, but that is in discussion for some times now ( see for example http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2073.pdf ).
Nice to see they plan to extend it to C / Obj-C.
@Jean-Daniel The C parts are what is holding back Objective-C. At the same time, compatibility with C is the main thing Objective-C has going for it. So we don’t need to fix Objective-C; it can’t fundamentally change without forfeiting its usefulness. We just need a more modern language that’s in some sense compatible so that we can drop down to Objective-C when we need the C stuff.
