Hacker News Reader

Comment by alcover | Hacker News Reader

To those having created languages, should I target LLVM or is transpiling to C a viable way (like I intend to) ?

Transpilers to C seem rare, maybe for a reason..

You could compile to C in the first revision of the compiler, but write it so that you could change to a LLVM back-end in the future. That is, unless your language does something that isn't a good fit for C, such as exceptions or continuations.

But do also look into other parts of the LLVM frameworks, especially MLIR.

Historically, there have been many compilers that produced C code, but some may have done so because of lack of compiler frameworks. The first C++ compilers compiled to C. Eiffel compiled to C. Nim compiles to C. I've also used a compiler framework that compiled to Java.

One of the bigger problems of transpiling to C is inheriting its oddities, such as the definition of overflow (or lack thereof) depending on the signedness of integers, etc., etc. Personally, I'd argue that transpiling to C combines most of the downsides of a new language with most of the downsides of C. I will admit, though, that the zero-effort FFI support of the approach is quite enticing.

you can use C to create any system you want including your preferred overflow, signedness, etc. Yes, it's that powerful. Then transpile to what you've created... which would still be transpiling to C. C lives outside the box, try to think that way.

Yes, that's how I see it. C can do anything - albeit ardously - and in the process of writing that transpiler to C in C I hope to make a huge leap in my understanding of C's model and of constructs in general.

Without compiler extensions galore, no C is not that powerful. Until C11, you couldn't even control alignment without hacky union workarounds that weren't great. You simply can't model exotic integer types in C like you can in LLVM IR. You can't disable struct padding without a GNU extension. The variance and portability of libc is pretty annoying too; you'd be surprised how many GNUisms you thought were in the spec. But worst of all, C's integer behavior is extremely unintuitive and basically force you to use case every operand and every binOp result to ensure desired behavior in all cases. You totally could transpile to C, but you'll basically have to master the C spec & its edge cases, write everything out in single-static-assignment form with explicit casts everywhere, avoid most of libc, use at least C11, accept some shortcomings, and avoid using most C language constructs and basically write assembly in C. Either do all that, or you'll inherit some of the quirks and shortcomings of C (and have your C compiler misinterpret your code). And even then, it probably won't optimize that well. Please, just output LLVM IR or something.

I'm creating a language and transpiling to C. At this point I'm about 80-90% of the way to v1 and transpiling to C is working well so far but I'm aware of the possibility that I may need to change it in the future. However, I absolutely love that a programmer using my language has the ability to write C code when needed, similar to how Python has C extensions.

Transpiling to C is certainly possible but the infrastructure for things (e.g. DWARF data for debugging) is much better when using LLVM IR directly. IIRC some operations are more pleasant (as in LLVM's definitions are more consistent/have fewer gotchas).

That said C transpilation is certainly a viable root (e.g. Idris does this)

Will Chrichton at Stanford Uni argued for targeting Rust rather than LLVM to get the benefits of a safer intermediate language and a standard library for free.

It is interesting to consider the trade-offs even if you go with C or LLVM:

https://willcrichton.net/notes/rust-the-new-llvm/

Reply on news.ycombinator.com