Hacker News Reader

Comment by AlectronikLabs | Hacker News Reader

Why don't they start to support units instead of these ugly header files to finally stop duplicating code? I see this might break stuff but you could implement it side by side with the preprocessor so old code would continue to work.

View on HN

Walter Bright says he was able to implement modules in C with 10 lines of code. That probably works with C but it'd make C incompatible with C++. Most people think that's reason enough not to do it. I think breaking compatibility with C++ would be like cutting the ropes to a sinking ship to save your own.

> That probably works with C but it'd make C incompatible with C++.

C is not a subset of C++. The simplest example:

> int new = 1;

Perfectly valid C, but not valid C++.

Now, modules would obviously be a bigger break than a few keyword incompatibilies, but at that point you'd also massively increase complexity and basically start creating C++ again, which is probably the actual reason it hasn't happened yet.

Modula-2 had modules in 1978, and it was still a pretty simple language. They don't necessarily imply recreating C++.

If you listen to the C++ people it's obvious they think the incompatible changes are a terrible mistake. They can't undo them but they're adamant no other breaking changes be allowed. They don't want things to get worse for them. Meaning better for everyone else.

And no modules wouldn't make C more like C++. It's just make C a bit saner and faster to compile. Because modules are complete and don't depend on code compiled before the import. Which means you can compile your modules exactly once and only once. Well written C code bases you could probably just change #include to #import and reap the benefits.

TBF, C doesn't suffer from the "headers cause slow builds" problem of C++, because C headers usually only contain a handful of declarations (e.g. the C stdlib headers are a couple of hundred lines of function prototypes and struct declarations, not tens of thousands of lines of gnarly template code like C++ stdlib headers).

When I've looked at what's going on with gcc what I see is most of the code being compile is header files. It's probably 90% headers and 10% actual code. And then there is all the dependency files it's reading. Though to be fair I think a lot of that is not so much trying to make C compile fast but to make C++ compile fast.

Might not be a popular opinion, but I actually like that C headers only contain the public API declaration of a "module" while the implementation and private declarations live in a separate file. Makes it easy to figure out the public API just by reading the header and without having to sift through unimportant implementation code.

In other languages you need IDE support for extracting the public API of a module.

That's orthogonal to the module system. OCaml for example has `.ml` and `.mli` files for the same purpose, but `.mli` can be automatically generated from `.ml` if you want. And that's absolutely nothing to do with OCaml's great module system.

Does the .mli file preserve documentation comments? IMHO the header file should be written for human consumption first. Documenting the implementation isn't by far as important.

The main OCaml implementation doesn't, but I believe there are several third-party tools that automate this. And as you've mentioned, comments in `.ml` and `.mli` do tend to differ, so even the default auto-generation may be useful because it will do as many jobs as possible without a human intervention.

why not introduce an "import" keyword and keep the include keyword for old headers?

If you mean #import, it already exists as a keyword (though the meaning is different between GCC/Clang and MSVC).

Reply on news.ycombinator.com