5 ms·

This reminds me a lot of D. It's low-level, GCed, essentially intended as a nicer C/C++. But I think it suffers from the same fatal flaw that D does: you have

by xaa 13y ago

This reminds me a lot of D. It's low-level, GCed, essentially intended as a nicer C/C++. But I think it suffers from the same fatal flaw that D does: you have to semi-manually translate C headers that you want to use. Like D, it provides an automated tool to help, but the translated headers will inevitably lag their original counterparts. As another commenter below noted, the var and proc thing is also redundant and annoying. However, the ability to compile to C (and, as a result, to easily cross-compile) is really nice.

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...
dom96 13y ago
> But I think it suffers from the same fatal flaw that D does: you have to semi-manually translate C headers that you want to use. Like D, it provides an automated tool to help, but the translated headers will inevitably lag their original counterparts. I can't think of a better alternative. Can you suggest one? The fact that Nimrod compiles to C already is a huge plus, it makes wrapping C code very easy.
- deleted 13y ago
  [deleted]
- deleted 13y ago
  [deleted]
- stonemetal 13y ago
  If the language has "A real package system" why not allow for packages written in other languages? If a C build system can look at a .h and a .lib and figure out what symbols are exported and use them then I seen no reason why a compiler for xyz could not also do that. If you reused OSS projects like Clang it may not even be a monumental effort.
eru 13y ago
What's redundant about the `var' syntax? Python goes with `=' for both creation and mutation of variables, and that causes some problems. So a separation of these might be useful.
- deleted 13y ago
  [deleted]
- xaa 13y ago
  In Nimrod, when you are declaring a variable with an explicit type, the syntax is: var x, y: int as opposed to the more concise C family way of doing it: int x, y; In C, there is no keyword needed to signal that this is a variable declaration. Similarly, in Nimrod, if you declare the return type of a function, you write it in addition to the "proc" keyword. IMO, the C++0x/D way of declaring a type inferred variable/function, using the auto keyword, is superior, because it is an alternative to specifying the type, not in addition to specifying the type. The Python way, omitting the type entirely, is not really suitable for a statically typed language but at least has the advantage of brevity.
  - cma 13y ago
    http://en.wikipedia.org/wiki/Most_vexing_parse http://en.wikipedia.org/wiki/Most_vexing_parse
  - bjz_ 13y ago
    If you have type inference, this is usually not a problem. Also, it is much easier to parse, both for humans and compilers. Rust uses the former way, and it's extremely readable. Even Herb Sutter, of C++ fame agrees: > One of the things Go does that I would love C++ to do is a complete left-to-right declaration syntax. That is a good thing because the left-to-right makes you end up in a place where you have no ambiguities, you can read your code in a more strait-forward way, which also makes it more toolable. (6:00) http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Ques...
    - 13y ago

by xaa 13y ago

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...

dom96 13y ago

> But I think it suffers from the same fatal flaw that D does: you have to semi-manually translate C headers that you want to use. Like D, it provides an automated tool to help, but the translated headers will inevitably lag their original counterparts. I can't think of a better alternative. Can you suggest one? The fact that Nimrod compiles to C already is a huge plus, it makes wrapping C code very easy.

deleted 13y ago
[deleted]
deleted 13y ago
[deleted]
stonemetal 13y ago
If the language has "A real package system" why not allow for packages written in other languages? If a C build system can look at a .h and a .lib and figure out what symbols are exported and use them then I seen no reason why a compiler for xyz could not also do that. If you reused OSS projects like Clang it may not even be a monumental effort.

eru 13y ago

What's redundant about the `var' syntax? Python goes with `=' for both creation and mutation of variables, and that causes some problems. So a separation of these might be useful.

deleted 13y ago
[deleted]
xaa 13y ago
In Nimrod, when you are declaring a variable with an explicit type, the syntax is: var x, y: int as opposed to the more concise C family way of doing it: int x, y; In C, there is no keyword needed to signal that this is a variable declaration. Similarly, in Nimrod, if you declare the return type of a function, you write it in addition to the "proc" keyword. IMO, the C++0x/D way of declaring a type inferred variable/function, using the auto keyword, is superior, because it is an alternative to specifying the type, not in addition to specifying the type. The Python way, omitting the type entirely, is not really suitable for a statically typed language but at least has the advantage of brevity.
- cma 13y ago
  http://en.wikipedia.org/wiki/Most_vexing_parse http://en.wikipedia.org/wiki/Most_vexing_parse
- bjz_ 13y ago
  If you have type inference, this is usually not a problem. Also, it is much easier to parse, both for humans and compilers. Rust uses the former way, and it's extremely readable. Even Herb Sutter, of C++ fame agrees: > One of the things Go does that I would love C++ to do is a complete left-to-right declaration syntax. That is a good thing because the left-to-right makes you end up in a place where you have no ambiguities, you can read your code in a more strait-forward way, which also makes it more toolable. (6:00) http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Ques...
  - 13y ago