5 ms·

A long-time disagreement between us :) > [in C] It's very difficult to avoid undefined behavior, True, but LLVM IR and other IRs have undefined behavior as we

by azakai 11y ago

A long-time disagreement between us :) > [in C] It's very difficult to avoid undefined behavior, True, but LLVM IR and other IRs have undefined behavior as well. > you won't be able to modify the compiler backend (and you will want to as you start optimizing), Not all languages need backend changes. And you can still add IR optimizations or backend changes that help your language, if you do. Yes, this might not be as easy, but then if you compile to LLVM IR, you might need IR changes for your special things anyhow. > you can't add new language intrinsics, good GC is pretty much incompatible with that, Good point, for most GC languages compiling to C is not a good option, which makes sense since C has no GC support. > and precise control over debug info is impossible. Yes, but using the C preprocessor you can get pretty far. > Compile to LLVM IR and/or GCC IR instead. More power that way, sure, but 1. It limits you to one compiler, while C has many. 2. LLVM IR changes over time (and recently had plenty of examples of this), so you'll need to track that. Whereas C is extremely stable, so long-term, it's much less work. 3. Emitting C is very easy (for those familiar with C), and also very easy to debug. I think compiling to C is an excellent option. Sometimes better, sometimes worse.

kibwen 11y ago
> True, but LLVM IR and other IRs have undefined behavior > as well. LLVM IR has less undefined behavior than C, and even despite the reduced surface area frontends have still historically wrestled with taming its UB (both PNaCL and Rust have documented their struggles). > It limits you to one compiler, while C has many. To quote Walter Bright on this topic (which I've linked elsewhere in this thread, but here it is again: http://forum.dlang.org/post/n1vbos$11ov$1@digitalmars.com http://forum.dlang.org/post/n1vbos$11ov$1@digitalmars.com): > 1. You're at the mercy of bugs in the C compiler you > cannot fix. > 2. C leaves quite a lot as "implementation defined", > causing endless compatibility issues with various C > compilers. > [...] > 6. You'll suffer from endless bug reports caused by a > mismatch between your compiler and the user's C > compiler, whatever that might be. > [...] > 10. The order of evaluation of C code expressions is > implementation defined. > 11. Installation problems, again, because you don't > control the user's C compiler.
- azakai 11y ago
  Sure, multiple implementations always brings with it those downsides you quoted. Same thing with web browsers, etc. But the benefits of multiple implementations are pretty significant as well, so it ends up worth it in some cases, and not in others.
  - kibwen 11y ago
    I agree with the comparison to web browsers, but even then how much deliberately implementation-defined behavior do modern web standards contain compared to C? I can think of Javascript object property enumeration order being unspecified, but nothing else springs to mind.
    - azakai 11y ago
      There's quite a lot, I'm afraid. For example, the precision of sin/cos (this led to bugs on real websites), the precision of random numbers (this led to a bunch of recent blogposts). And there are also non-semantic differences that end up being important, like one browser running certain things too slowly or taking too much memory. Multiple implementations is always more complicated ;) But in many cases it's better than a monoculture, in my opinion.
      - kibwen 11y ago
        Oh I'm not arguing in favor of a monoculture. But the OP's statement that "This would make it possible to leverage the C compilers that already exist for every platform out there" is naive because C's deliberate flexibility makes cross-platform and cross-compiler codegen fiendishly persnickety. Meanwhile, the only thing that you gain from all this extra effort is the ability to target platforms that GCC and LLVM don't already support, but these platforms are all likely to be obscure resource-constrained devices, and I just can't see developers on these platforms flocking to such a thoroughly-dynamic language as the OP is envisioning.
        azakai 11y ago
sklogic 11y ago
IR changes are not that significant. I followed LLVM from nearly the very beginning, and very rarely I was forced to amend something to keep up with the change. The biggest thing in the few past releases was the change in metadata (which got its own class hierarchy, separate from the values). The very amount of tests in the LLVM source tree ensures that nobody will be motivated to do any significant change unless it is really, really needed, otherwise you'd be forced to do a lot of painful work to update all the tests. Also, compiling to C pretty much rules out having a REPL for free and all the other fun, while with LLVM it's trivial.
- azakai 11y ago
  Aside from metadata, some other large changes that have been going on are * the removal of pointer types (still happening) * the use/user flip In my experience these have been significant in the amount of work it takes to track.
  - sklogic 11y ago
    Both were not that big - at least not for the C API and text IR users. Worse for the C++ users, obviously, but that was never promised to stay stable and not covered by such a huge number of tests to deter any breaking changes.
    - azakai 11y ago
      Agreed that using the C API can be easier. But for text IR though, the changes were extensive. Scripts were provided that helped, but still, it was a bunch of work to add types/remove types due to the pointer types changes.

by azakai 11y ago

kibwen 11y ago

> True, but LLVM IR and other IRs have undefined behavior > as well. LLVM IR has less undefined behavior than C, and even despite the reduced surface area frontends have still historically wrestled with taming its UB (both PNaCL and Rust have documented their struggles). > It limits you to one compiler, while C has many. To quote Walter Bright on this topic (which I've linked elsewhere in this thread, but here it is again: http://forum.dlang.org/post/n1vbos$11ov$1@digitalmars.com http://forum.dlang.org/post/n1vbos$11ov$1@digitalmars.com): > 1. You're at the mercy of bugs in the C compiler you > cannot fix. > 2. C leaves quite a lot as "implementation defined", > causing endless compatibility issues with various C > compilers. > [...] > 6. You'll suffer from endless bug reports caused by a > mismatch between your compiler and the user's C > compiler, whatever that might be. > [...] > 10. The order of evaluation of C code expressions is > implementation defined. > 11. Installation problems, again, because you don't > control the user's C compiler.

azakai 11y ago
Sure, multiple implementations always brings with it those downsides you quoted. Same thing with web browsers, etc. But the benefits of multiple implementations are pretty significant as well, so it ends up worth it in some cases, and not in others.
- kibwen 11y ago
  I agree with the comparison to web browsers, but even then how much deliberately implementation-defined behavior do modern web standards contain compared to C? I can think of Javascript object property enumeration order being unspecified, but nothing else springs to mind.
  - azakai 11y ago
    There's quite a lot, I'm afraid. For example, the precision of sin/cos (this led to bugs on real websites), the precision of random numbers (this led to a bunch of recent blogposts). And there are also non-semantic differences that end up being important, like one browser running certain things too slowly or taking too much memory. Multiple implementations is always more complicated ;) But in many cases it's better than a monoculture, in my opinion.
    - kibwen 11y ago
      Oh I'm not arguing in favor of a monoculture. But the OP's statement that "This would make it possible to leverage the C compilers that already exist for every platform out there" is naive because C's deliberate flexibility makes cross-platform and cross-compiler codegen fiendishly persnickety. Meanwhile, the only thing that you gain from all this extra effort is the ability to target platforms that GCC and LLVM don't already support, but these platforms are all likely to be obscure resource-constrained devices, and I just can't see developers on these platforms flocking to such a thoroughly-dynamic language as the OP is envisioning.
      - azakai 11y ago

sklogic 11y ago

IR changes are not that significant. I followed LLVM from nearly the very beginning, and very rarely I was forced to amend something to keep up with the change. The biggest thing in the few past releases was the change in metadata (which got its own class hierarchy, separate from the values). The very amount of tests in the LLVM source tree ensures that nobody will be motivated to do any significant change unless it is really, really needed, otherwise you'd be forced to do a lot of painful work to update all the tests. Also, compiling to C pretty much rules out having a REPL for free and all the other fun, while with LLVM it's trivial.

azakai 11y ago
Aside from metadata, some other large changes that have been going on are * the removal of pointer types (still happening) * the use/user flip In my experience these have been significant in the amount of work it takes to track.
- sklogic 11y ago
  Both were not that big - at least not for the C API and text IR users. Worse for the C++ users, obviously, but that was never promised to stay stable and not covered by such a huge number of tests to deter any breaking changes.
  - azakai 11y ago
    Agreed that using the C API can be easier. But for text IR though, the changes were extensive. Scripts were provided that helped, but still, it was a bunch of work to add types/remove types due to the pointer types changes.