Hacker News Reader

Comment by chc4 | Hacker News Reader

I'm always slightly confused when languages target C instead of compiling themselves. Nim, for example. Is it really that much easier to deal with all the idiosyncrasies of C for a backend, and have to hope that the compiler will cleanup the mass of basic code blocks you emit, than emit LLVM bytecode or assembly? Not even having to use the LLVM C bindings, you can just emit the bytecode directives to a file and call the toolchain itself.

Is the idea that you can compile you base code once, and then work on the emitted C to extend the project?

View on HN

As camgunz said, emitting C code makes your compiler far more portable, as you can find C compilers for virtually every target (e.g., AFAIK, the current version of LLVM does not support SPARC architectures).

Another theoretical advantage of generating C code is that it should be easy to try adding bits of code written in these new languages to existing C/C++ projects. In this way you can test the new language on real life projects without the need of rewriting everything from scratch. (I have never followed this approach, although I have heard of people having done this [1].)

[1] http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret... The languages here were quite different, though (Python/OCaml): but the author followed the idea of slowly converting a project to a new language by first rewriting parts of it. Had the OCaml compiler emitted Python code, I bet the task would have been easier.

I've heard portability arguments; C is far more portable than LLVM. But I'm guessing more people know C than LLVM IR or 4 assembly languages, so C is an easier target.

EDIT: oh, also wildly easy interoperability with existing C/C++ code (so long as the C++ code provides a C interface).

Compiling down to C also makes wrapping C++ libraries much easier. Because when you compile down to C, it's not that much of a stretch to also allow compilation to C++. You can then make wrapping C++ code much easier in the language.

Nim is one language that I know of which takes advantage of that. Here is one example of a pretty large wrapper around a C++ library https://github.com/3dicc/Urhonimo, and here is the documentation for this feature http://nim-lang.org/docs/manual.html#implementation-specific...

Depending on the C standard you're emitting, portability and backward compatibility gains can potentially be huge.

I've even occasionally managed to get code from compiled-to-C languages working on platforms like RiscOS and Amiga.

You can often use any language for esoteric microcontrollers, as long as it's C.

Languages that can be compiled to C could be interesting for implementing embedded system firmware.

In this particular case, ooc is a syntax sugar for C, like CoffeeScript is a syntax sugar for JavaScript. It wouldn't make any sense not to compile to C.

Coffeescript compiles to JavaScript for a reason though. No language ever has a reason to compile to C unless your platform is really goofy.

I think the biggest benefit of compiling to C is that you can output comments about which C sections correspond to which lines in the higher level code, and then you can use step-through debuggers to see why your emitted code isn't working right.

You don't have to deal with all the idiosyncrasies of C, because you can restrict yourself to a small subset of C that is straightforward and easily understood.

LLVM bitcode is version dependent. Some of it is architecture dependent. Emitting C is way way easier.

Odd to see it not mentioned as another benefit, but by targeting C instead of say direct assembly you benefit from the decades of optimization research that has gone into modern C compilers.

Reply on news.ycombinator.com