4 ms·

I like the Nim syntax, but I’m not certain why they chose to transpile it to C. Why not just go all the way, and encode it in assembly? Yes, I understand thei

I like the Nim syntax, but I’m not certain why they chose to transpile it to C. Why not just go all the way, and encode it in assembly? Yes, I understand their reasoning, to make use of all the advanced C compilers out there. And to make the code compatible with existing C libraries and APIs. But I feel this is more of a shortcut, and a crutch, that will prevent them from fulfilling their expectations, of being a C language and systems programming replacement. I think the better approach would have been to target assembly code instead, and then, build connections to existing C APIs.

WalterBright 7y ago
D doesn't compile to C code because I found C to be a rather limited platform. By generating native code, I could go beyond what C supported. The vagaries of various C compilers was also a problem.
- Reelin 7y ago
  Given that C has raw pointers and inline assembly, what is D doing that it couldn't (easily?) express?
  - simias 7y ago
    Inline assembly is a compiler extension and not portable. Beyond that, sure you can do whatever you want in C if you're willing to mess with assembly and non-portable memory tricks but at this point you're better off writing your own native backend. The whole point of generating C instead of machine code is to leverage the existing compiler infrastructure to support a vast number of architectures and generate efficient code. If you just dump inline assembly in a C function or rely on opaque memory shenanigans the C compiler won't be able to meaningfully optimize your code and it probably won't be portable.
  - WalterBright 7y ago
    1. cannot support anything but the C ABI 2. cannot support exception handling 3. cannot support types that C doesn't 4. stuck with C symbolic debug info, not your language's 5. cannot innovate with things like how strings are stored 6. many C compilers do not emit COMDATs 7. no thread local storage 8. chained to slow compilation speeds 9. stuck with trying to find a way to work around C compiler bugs 10. stuck with whatever C compiler the user has, i.e. one has to support multiple versions of multiple C compilers 11. C compiler can change, breaking your compiler The original C++ compiler, cfront, had a LOT of problems with these issues.
    - Reelin 7y ago
      Thanks for taking the time to respond, compilers are always interesting to learn about! Point 7 was (finally!) addressed by C11. Points 6, 8, 9, 10, & 11 are all good ones that hadn't occurred to me. It seems like points 1, 4, & 5 could be worked around, but I can see where the added complexity would be unwelcome. On the whole, I can see why you made the decision you did. However, I don't buy points 2 (exception handling) and 3 (type support). Certainly C doesn't have these things built in, but appropriate code transformations seem to suffice in practice. For example, the CHICKEN Scheme to C compiler employs continuation-passing style [1] and Embeddable Common Lisp [2] manages to compile to C without (to my knowledge) breaking either its type system or its condition and restart [3] system. [1] https://wiki.call-cc.org/chicken-compilation-process https://wiki.call-cc.org/chicken-compilation-process [2] https://www.cliki.net/ECL https://www.cliki.net/ECL [3] http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html http://www.gigamonkeys.com/book/beyond-exception-handling-co...
      - WalterBright 7y ago
        2. yes, it can be done with setjmp/longjmp, but that's a terrible solution 3. if the C compiler doesn't support 80 bit reals (and D does), you're out of luck. I looked at the C code generated by C++ cfront. No thanks. The worst is, the C compiler vendor owns you, and they couldn't care less about you.
beagle3 7y ago
Nim compiles to C, C++, Objective-C, and JS with the official distribution. There are community developed native code (NLVM which uses LLVM underneath), Lua and Python backends with various degrees of completeness. With the limited resources available to Araq, it more definitely makes sense to leverage 30 years of GCC optimizations and/or 20 years of LLVM and/or ICC experience, while at the same time supporting basically every platform under the sun. The Nim community is made of very pragmatic people, and I'm glad it is that way.

WalterBright 7y ago

D doesn't compile to C code because I found C to be a rather limited platform. By generating native code, I could go beyond what C supported. The vagaries of various C compilers was also a problem.

Reelin 7y ago
Given that C has raw pointers and inline assembly, what is D doing that it couldn't (easily?) express?
- simias 7y ago
  Inline assembly is a compiler extension and not portable. Beyond that, sure you can do whatever you want in C if you're willing to mess with assembly and non-portable memory tricks but at this point you're better off writing your own native backend. The whole point of generating C instead of machine code is to leverage the existing compiler infrastructure to support a vast number of architectures and generate efficient code. If you just dump inline assembly in a C function or rely on opaque memory shenanigans the C compiler won't be able to meaningfully optimize your code and it probably won't be portable.
- WalterBright 7y ago
  1. cannot support anything but the C ABI 2. cannot support exception handling 3. cannot support types that C doesn't 4. stuck with C symbolic debug info, not your language's 5. cannot innovate with things like how strings are stored 6. many C compilers do not emit COMDATs 7. no thread local storage 8. chained to slow compilation speeds 9. stuck with trying to find a way to work around C compiler bugs 10. stuck with whatever C compiler the user has, i.e. one has to support multiple versions of multiple C compilers 11. C compiler can change, breaking your compiler The original C++ compiler, cfront, had a LOT of problems with these issues.
  - Reelin 7y ago
    Thanks for taking the time to respond, compilers are always interesting to learn about! Point 7 was (finally!) addressed by C11. Points 6, 8, 9, 10, & 11 are all good ones that hadn't occurred to me. It seems like points 1, 4, & 5 could be worked around, but I can see where the added complexity would be unwelcome. On the whole, I can see why you made the decision you did. However, I don't buy points 2 (exception handling) and 3 (type support). Certainly C doesn't have these things built in, but appropriate code transformations seem to suffice in practice. For example, the CHICKEN Scheme to C compiler employs continuation-passing style [1] and Embeddable Common Lisp [2] manages to compile to C without (to my knowledge) breaking either its type system or its condition and restart [3] system. [1] https://wiki.call-cc.org/chicken-compilation-process https://wiki.call-cc.org/chicken-compilation-process [2] https://www.cliki.net/ECL https://www.cliki.net/ECL [3] http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html http://www.gigamonkeys.com/book/beyond-exception-handling-co...
    - WalterBright 7y ago
      2. yes, it can be done with setjmp/longjmp, but that's a terrible solution 3. if the C compiler doesn't support 80 bit reals (and D does), you're out of luck. I looked at the C code generated by C++ cfront. No thanks. The worst is, the C compiler vendor owns you, and they couldn't care less about you.

beagle3 7y ago

Nim compiles to C, C++, Objective-C, and JS with the official distribution. There are community developed native code (NLVM which uses LLVM underneath), Lua and Python backends with various degrees of completeness. With the limited resources available to Araq, it more definitely makes sense to leverage 30 years of GCC optimizations and/or 20 years of LLVM and/or ICC experience, while at the same time supporting basically every platform under the sun. The Nim community is made of very pragmatic people, and I'm glad it is that way.