Apple's Module proposal to replace headers for C-based languages [pdf]

Post by rossjudson » Mon, Nov 26, 2012, 9:56 PM UTC

coliveira wrote: post #72

zach wrote: post #58

Earlier quoted context omitted.

Definitely seems like Go has led the way here. Not that there wasn't a lot of pain before, but Go's lightning compilation seems to be an impetus for the "let's finally do this" change. I have to think that this is a minor repartee between Apple and Google language groups. Google did something clever that breaks with tradition, and now Apple is doing something similarly clever yet backwards-compatible. I like this dyn…

Object Pascal did the exact same thing 20 years ago, and it was a language much more influential than Go at its time. So, I don't think Apple programmers had even to look at Go to design this feature.

Post by dpark » Mon, Nov 26, 2012, 10:03 PM UTC

  module ClangAST {
    umbrella header “AST/AST.h”
    module * { }
    link “-lclangAST”
  }

Post by pmr_ » Mon, Nov 26, 2012, 10:09 PM UTC

bla2 wrote: post #63

haberman wrote: post #46

Overall I like it. I like how they are treating both C and C++ as first-class citizens of this new feature (instead of, for example, inextricably tying its design to classes and namespaces). I like that they have a plausible migration story for how to interoperate with existing header files. And the overall design really looks like something that would fit into all of the C and C++ work that I do without getting in t…

> Sure it's non-standard Doug chairs the study group that's evaluating a module system for c++ ("""Sutter announces there is a Study Group for modules and Doug Gregor is the chair.""" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n338... ) Doug happens to be employed by Apple, but calling this "Apple's proposal" is somewhat misleading I think.

Post by meaty » Mon, Nov 26, 2012, 10:11 PM UTC

MaysonL wrote: post #120

meaty wrote: post #65

Earlier quoted context omitted.

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've used Oberon, which has a module system quite similar to this, quite heavily, and the way to diminish link time is to not link, instead use dynamic loading: leaf modules are loadable and unloadable, nonleaf modules can be made leaf by unloading all their descendants. Gives you the possibility for immediacy/flow, that a good REPL does. For many cases, you get edit/compile/run cycles measured in (often single-digit…

Post by msbarnett » Mon, Nov 26, 2012, 11:09 PM UTC

mtdev wrote: post #101

mbrubeck wrote: post #79

Earlier quoted context omitted.

No, the issue is not just poor implementation. Problems like O(M*N) bloat and scope pollution are fundamental design flaws with the preprocessor header system. Almost every widespread modern language (all except JavaScript? [1]) has a built-in module system. Adding modules to C is not just some sort of hack to work around preprocessor limitations. Instead I'd say that the C preprocessor is a hack to work around lack…

You can add some functionality to limit scope and implement a caching system (which is also proposed here) to deal with M*N issues with a focus on keeping backwards compatibility. E.g. the caching is done automatically, the scope spamming control is a best effort solution based on static analysis (for example). Moving from headers to modules is a fundamental change in how the language operates and is guaranteed to fu…