3 ms·

On the benefits of using C as a language back end

20 points by BafS 7y ago

FpUser 7y ago
What about debugging?
xedrac 7y ago
This looks like an improved version of Go. The website claims that it will guarantee no data races at compile time (work in progress). I'd like to know how he plans to accomplish this as it's not a trivial problem to solve completely. Also, a lack of algebraic (sum) data types makes it much less attractive to me. Otherwise, neat little language.
register 7y ago
Debugging is not a problem per se. As an example you can see how Nim generates debugging info while transpiling to C with the --debuginfo --linedir:on options. The real problem with C transpilation is proper garbage collection support. A C compiler doesn't track roots and that means that for a language transpiled to C it is not practically feasible as of today to support garbage collection algorithms that are not conservative. There are published tecniques that should allow implementing full non conservative GC on top of C but they have remained in research settings so far.As a matter of fact the de facto standard GC for such langauages is Bohem's which has known limitations.
- tom_mellior 7y ago
  A C compiler doesn't track roots, but it does not follow that precise GC is impossible in code that compiles to C. You "just" need to make sure that your translator emits the appropriate code. Nobody forces you to implement assignments in the guest language as literal C assignments. If a guest language assignment statement compiles to something like "assign(&target, value)", then your assign function can do whatever it takes to track roots.
  - register 7y ago
    Agreed that it can be done but at a considerable cost. Translating every assignment into a function call is within what I didn't consider feasible from a practical point of view. The best research papers I saw on this topic proposed to pass an additional "ghost stack" as a parameters in every function call that is structured in a specific way so that roots are not "optimized away" by the compiler.
tom_mellior 7y ago
> The V compiler hasn't crashed once for me, and I haven't received any crash reports from other users. https://github.com/vlang/v/issues/2838 https://github.com/vlang/v/issues/2838 "Compiler crash during filtering's assignment operation on a mutable array" https://github.com/vlang/v/issues/2565 https://github.com/vlang/v/issues/2565 "Compiler crash when using inexistent struct type in const block" (One of these is from two days after the author wrote the above statement, but the other isn't.) There are other reports where the V compiler seems to generate C code that does not compile, or only with very nasty type warnings, for example: https://github.com/vlang/v/issues/2960 https://github.com/vlang/v/issues/2960 https://github.com/vlang/v/issues/2981 https://github.com/vlang/v/issues/2981
- tom_mellior 7y ago
  (As always, I'm genuinely interested in the thoughts of whoever downvoted a factual, well-sourced post.)

20 points by BafS 7y ago

What about debugging?

This looks like an improved version of Go. The website claims that it will guarantee no data races at compile time (work in progress). I'd like to know how he plans to accomplish this as it's not a trivial problem to solve completely. Also, a lack of algebraic (sum) data types makes it much less attractive to me. Otherwise, neat little language.

Debugging is not a problem per se. As an example you can see how Nim generates debugging info while transpiling to C with the --debuginfo --linedir:on options. The real problem with C transpilation is proper garbage collection support. A C compiler doesn't track roots and that means that for a language transpiled to C it is not practically feasible as of today to support garbage collection algorithms that are not conservative. There are published tecniques that should allow implementing full non conservative GC on top of C but they have remained in research settings so far.As a matter of fact the de facto standard GC for such langauages is Bohem's which has known limitations.

tom_mellior 7y ago
A C compiler doesn't track roots, but it does not follow that precise GC is impossible in code that compiles to C. You "just" need to make sure that your translator emits the appropriate code. Nobody forces you to implement assignments in the guest language as literal C assignments. If a guest language assignment statement compiles to something like "assign(&target, value)", then your assign function can do whatever it takes to track roots.
- register 7y ago
  Agreed that it can be done but at a considerable cost. Translating every assignment into a function call is within what I didn't consider feasible from a practical point of view. The best research papers I saw on this topic proposed to pass an additional "ghost stack" as a parameters in every function call that is structured in a specific way so that roots are not "optimized away" by the compiler.

tom_mellior 7y ago

> The V compiler hasn't crashed once for me, and I haven't received any crash reports from other users. https://github.com/vlang/v/issues/2838 https://github.com/vlang/v/issues/2838 "Compiler crash during filtering's assignment operation on a mutable array" https://github.com/vlang/v/issues/2565 https://github.com/vlang/v/issues/2565 "Compiler crash when using inexistent struct type in const block" (One of these is from two days after the author wrote the above statement, but the other isn't.) There are other reports where the V compiler seems to generate C code that does not compile, or only with very nasty type warnings, for example: https://github.com/vlang/v/issues/2960 https://github.com/vlang/v/issues/2960 https://github.com/vlang/v/issues/2981 https://github.com/vlang/v/issues/2981

tom_mellior 7y ago
(As always, I'm genuinely interested in the thoughts of whoever downvoted a factual, well-sourced post.)