So, is Nim compiler only a translate to others languages? Like:
Nim -> C -> binary code Nim -> C++ -> binary code Nim -> JS
There is no meaningful distinction between a "translator" and a "compiler".
Is GCC a real compiler or only a translator to GNU assembler? Is Rust a real compiler or only a translator to LLVM IR?
Hi,
So, the Nim compiler translate my code twice?
Something like that:
Nim -> .cpp -> .exe
Yeah, you can think of it as translating the code “twice”, but that is not the whole picture.
You can break out the compilation process into any number of steps! Depends what you count as a “translation” step.
I think of nim being 1 step:
nim -> exe comes out.
But you can think of it as 2 steps:
nim -> C -> exe comes out.
But really C has its own steps, so maybe 4 steps:
nim -> C -> Assembler -> Linker -> exe comes out.
But really there are a ton of steps in the middle too, maybe 18 steps is more accurate:
Nim lexical Nim syntax Nim semantic Nim generics folding Nim macro expansion Nim code generator C preprocessor C lexical C syntax C intermediate code generator C code optimizer C target code generator Assembler preprocessor Assembler Lexical Assembler Syntax Assembler code generator Linker Exe comes out.
Is one step better than any other step? Does the number of steps matter? If you stuff compiles fast - and it does compile fast with nim - it does not matter at all.
How many “translation” steps does nim have? Depends how you count.
Nim is a Compiler. Nim is only a transpiler for JavaScript.
All code end up being binary code, AKA machine code, AKA ".exe", even highest level ones, try node --print_code -e 1+1 and you will see.
Thank you a lot Araq, moigagoo, treeform and juancarlospaco.
Is there a way to get the .c file before the compilation to binary?
Is there a way to get the .c file before the compilation to binary?
~/.cache/nim
Nim is only a transpiler for JavaScript.
Gah... trigger word! :D
For myself, I call current Nim implementation is translator only, it can distinct other possible Nim implementation via LLVM (low-level SSA) as the compiler.
Nim is a compiler with multiple codegen backends.
Transpilers, or source-to-source compilers, are tools that read source code written in one programming language, and produce the equivalent code in another language that has a similar level of abstraction.
The "equivalent code" and "similar level of abstraction" is the key point here. Existing nim backend languages (C, C++, JS) are nowhere near "similar level of abstraction". Well you could argue C++ is somewhat similar, but no, the C++ code generated by nim is very low-level comparing to nim or hand-written C++ code. It doesn't have classes, templates, #ifdefs, even header files, it is locked to a single platform/architecture, it is almost impossible to edit it manually.
Another way to think about it is imagine if nim introduced another backend which spits out native binaries, and this backend would reside in the nim binary as C/C++/JS backends do. Does nim suddenly become the compiler now? Or does is become a Schrödinger's compiler-transpiler depending on which arguments you run it with? :) Obviously, it still remains a compiler, just like it is now.