3 ms·
Generating C is fine tbh. Lots of respectable language implementations do that, or did that at some point in their life. V has plenty of other issues, though.
by creata 1y ago
Generating C is fine tbh. Lots of respectable language implementations do that, or did that at some point in their life.
V has plenty of other issues, though.
- torginus 1y agoI don't think it's fine the way V does it. What V's compiler is essentially doing is that it parses the V code into an AST, then it walks the AST and tries to generate an equivalent C code on the fly: https://github.com/vlang/v/blob/master/vlib/v/gen/c/match.v https://github.com/vlang/v/blob/master/vlib/v/gen/c/match.v How a proper compiler should work (and how they actually do from what I've seen), is that they first take the AST, try to remove all fancy syntatic sugar by converting it to simpler constructs, and then they generate an intermediate representation that's either stack, or SSA based. It might skip the lowering of syntatic sugar, and generate IR directly. At some point either on the AST, or the IR, you might want to do control or data flow analysis to support some of your features. From that point on, the backend generates either LLVM IR, C or might even attempt to generate machine code itself. The problem with targeting C is that you lose access to stuff not accessible in C, like precise variable tracking on the heap/stack (needed for a good GC), or unwinding support needed for exceptions.