Hacker News Reader

Comment by qznc | Hacker News Reader

Is "fatal flaw" the right term? I do not see any way to fix this. Even including a full C parser and preprocessor into the D/Nimrod compiler would not solve the problem.

View on HN

Since I've written a C compiler, I know how to read C source files. The problem with automated conversion is you can do 90% of the job without any trouble, but there's that darned last 10% that doesn't map to D without some human decision making.

For example, there are the preprocessor macros. Most are straightforward, but it seems most C .h files succumb to the temptation at some point to do something wacky with them.

This is very true; however c2nim distinguishes between #def and #define for this reason and this helps a lot. #def means c2nim needs to expand the macro, #define means it's some macro that should be translated into a Nimrod template. Coming up with heuristics to do this #def vs #define distinction automatically seems to be quite easy and might be implemented in a later version of c2nim.

#def, according to https://github.com/Araq/Nimrod/blob/master/doc/c2nim.txt, requires modification of the C header files. I don't think this is a practical option, for example, they might be system .h files.

Obviously, I have no perfect solution. I was initially harboring the vague hope that Nimrod would be able to avoid this problem by virtue of compiling to C.

But I do still assert that this is a "fatal flaw" for a systems programming language. When I wrap a C library in, say, Python, I am already forced to write a wrapper layer, so there's no discomfort or surprise in declaring a few additional structs or function prototypes.

For a novel systems programming language, however, whose raison d'être is to save me keystrokes over C/C++, it feels like two steps forward and one step back to have a more concise main program but lots of auxillary handwritten header translations that have to be manually maintained.

I believe that the primary reason for the success of C++ is its easy compatibility with C, and any creators of would-be C++ replacements who fail to understand this are doomed to failure.

> I believe that the primary reason for the success of C++ is its easy compatibility with C, and any creators of would-be C++ replacements who fail to understand this are doomed to failure.

The main reason were actually

- Most C compiler vendors bundled C++ compilers in the begining

- The C and C++ compiler vendors that matter are OS vendors

Any language can replace C or C++, if an OS vendor decides that it is the way to go.

Lets say Apple decides to have Objective-C as their systems language, or Microsoft decides to have C# as their systems language.

Once upon a time, Apple's system programming language was a Pascal dialect, just as an example.

Developers are always at the mercy what languages are the official ones in a given platform.

This is how Microsoft is deprecating C on Windows nowadays, by leaving their C compiler at C90 level and stating C++ is the official systems language for Windows on their tooling.

> This is how Microsoft is deprecating C on Windows nowadays, by leaving their C compiler at C90 level

Actually they've recently gone back on that and are implementing c99 language[1] and standard library[2] features in an apparent sudden realization that the rest of the C world has moved on (since they cite FFmpeg as a reason, my pet theory is that they were just that embarrassed by Ron Bultje's c99 to c89 translator[3])

[1] http://blogs.msdn.com/b/somasegar/archive/2013/06/28/cpp-con...

[2] http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar...

[3] http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-s...

Those C99 features are only at library level and are partially required by C++11 and C++14, there is no change of mind going on, at least for the moment.

Reply on news.ycombinator.com