Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

llvm.org

Post reply on HN
Print view View original

181–187 of 187 posts

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

#181

Post by Evbn »

msbarnett wrote: post #30
[deleted] wrote: post #27

[deleted]

> The article is disingenuous. Alongside its oh-so-sassy table of file sizes for helloworld, it needs a table of runtimes for helloworld. Turning stdio into an API instead of preprocessor soup is going to blow that up, unless the guy means something very unusual by "API". You seem to be deeply confused here. This is simply a proposal for persisting the AST for eg) stdio across compiler invocations instead of reparsin…

How is this new thing different from precompiled headers, which Apple has had for 10 years?

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

#182

Post by wladimir »

pjmlp wrote: post #158
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…

> 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. Except that this is pure marketing. Languages with modules were already compiling as fast as Go does, back in the 80's. Modula-2, Turbo Pascal, just to name two of many.

Yes, the idea of using modules is nothing new. It's old-school and well-proven. Many people have argued about adding pascal-like module support to C at some point or another at the coffee machine. But having enough (political) momentum to actually change C(++), and overcome extreme inertia and calcification is new. LLVM is the greatest thing to happen to compilers in a long time, it really opened up compiler development like GCC somehow never did (see http://www.drdobbs.com/architecture-and-design/the-design-of... for a likely explanation). And having a giant like Apple behind it helps, of course.

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

#183

Post by pjmlp »

wladimir wrote: post #182
pjmlp wrote: post #158

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. Except that this is pure marketing. Languages with modules were already compiling as fast as Go does, back in the 80's. Modula-2, Turbo Pascal, just to name two of many.

Yes, the idea of using modules is nothing new. It's old-school and well-proven. Many people have argued about adding pascal-like module support to C at some point or another at the coffee machine. But having enough (political) momentum to actually change C(++), and overcome extreme inertia and calcification is new. LLVM is the greatest thing to happen to compilers in a long time, it really opened up compiler developm…

Oh yes, I am all for having modules in C and C++.

I was just calling the attention that some Go devotees seem to think their compile times are something new.

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

#184

Post by dietrichepp »

fleitz wrote: post #153
dietrichepp wrote: post #139

Earlier quoted context omitted.

They're not ditching the processor, they're just making it so the preprocessor state is isolated for modules. You can still #define all you want, but it won't cross the boundary between your code and a module.

Which is pretty much how linking to a shared library works, your #defines and #includes have no effect.

Well, no. If you make a #define it will affect code in the #include. This is why you sees puts defined as

    extern int puts(__const char *__s);
The reason for the double underscore is so the definitions won't be affected if 's' is a macro.

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

#186

Post by aidenn0 »

vilya wrote: post #130
aidenn0 wrote: post #104

Earlier quoted context omitted.

I know nothing about this proposal, but I can make educated guesses on all of these: Creating header: the module needs only the public information for a closed source module. You could generate it from a .h file if you are a consumer of a closed source module, or if you are the producer of the module, you could potentially ship either pre-generated modules or all the information needed to generate a module. javadoc,…

Thanks, I think you're probably right - the modules would have to have enough information in their compiled form that your compiler could introspect them without needing the source. The proposal wouldn't be much use if that weren't true. Re: templates, I thought the expensive part of template processing was code generation rather than parsing. Would caching the AST really be that much of a saving? I admit I've never…

#include

You've just parsed ~6MB of code. You might instantiate 2 or 3 templates from it. The parsing truly is non-trivial.

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

#187

Post by dchichkov »

dangayle wrote: post #171
dchichkov wrote: post #152

It breaks "there should be one-- and preferably only one --obvious way to do it". And quite a few others. But as a stand-alone feature, stateless preprocessor includes could be a nice feature to have.

Is C bound by Zen?

Zen wisdom crosses all boundaries :)
Post reply on HN