3 ms·

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

by qznc 13y ago

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.

WalterBright 13y ago
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.
- Araq 13y ago
  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.
  - WalterBright 13y ago
    #def, according to https://github.com/Araq/Nimrod/blob/master/doc/c2nim.txt 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.
xaa 13y ago
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.
- pjmlp 13y ago
  > 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.
  - 0x09 13y ago
    > 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-conformance-roadmap.aspx http://blogs.msdn.com/b/somasegar/archive/2013/06/28/cpp-con... [2] http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar... [3] http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-studio-support-in-ffmpeg-and-libav http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-s...
    - pjmlp 13y ago
      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.

by qznc 13y ago

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.

WalterBright 13y ago

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.

Araq 13y ago
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.
- WalterBright 13y ago
  #def, according to https://github.com/Araq/Nimrod/blob/master/doc/c2nim.txt 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.

xaa 13y ago

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.

pjmlp 13y ago
> 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.
- 0x09 13y ago
  > 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-conformance-roadmap.aspx http://blogs.msdn.com/b/somasegar/archive/2013/06/28/cpp-con... [2] http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-librar... [3] http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-studio-support-in-ffmpeg-and-libav http://blogs.gnome.org/rbultje/2012/09/27/microsoft-visual-s...
  - pjmlp 13y ago
    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.