Hacker News Reader

Comment by xaa | Hacker News Reader

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.

View on HN

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.

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.

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

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.

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.

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.

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

I prefer Pascal-style type declaration as well, but playing Devil's advocate for a moment: There's nothing that says you can't have a left-to-right type declaration syntax and have the variable name appear on the right. So something like this:

  var ptr_to_array_of_ptr_to_int : *[](*int)

would become something like this:

  *[](*int) ptr_to_array_of_ptr_to_int

The former syntax is slightly easier for a program to parse, makes it easier to see variable names, and is more consistent with typical syntax for type inference during variable assignment:

  var something := some_function(whatever)
  auto something = some_function(whatever)

However, the latter does, as xaa said, eliminate some keystrokes. I also happen to find

  byte foo = 10

to read more nicely than any of these:

  var foo : byte = 10
  var foo := (u8)10
  var foo := 10'u8

Go is a good example. It does variable declaration quite concisely while avoiding parsing ambiguity (although it falls into the same trap as Nimrod on function declaration with its "func" keyword).

Type inference can be useful, but important secondary purposes of declaring types, beyond informing the compiler what type a variable is, are as documentation to yourself, and as a sort of compile-time assertion, to ensure that the variable type is indeed what you thought it was. Thus, a language with type inference should not treat manually declared types as some kind of corner case.

>as opposed to the more concise C family way of doing it

The "C family way of doing it" is problematic, and gets crazy complicated with more involved declarations (e.g involving function pointers and such).

Nimrods/Go/etc way is much better.

http://en.wikipedia.org/wiki/Most_vexing_parse

Reply on news.ycombinator.com