A PR using a recently introduced language feature in the compiler, (see Improve compiler spec helpers for macro methods by HertzDevil · Pull Request #11139 · crystal-lang/crystal · Gi) sparked the questions, which earlier compiler version should be able to compiling the compile.
Currently, it is only ensured that the previous compiler release is able to build the next one (1.0 builds 1.1, 1.1 builds 1.2).
That’s technically sufficient. But I think it would be helpful if there was broader compatibility, for recreating compiler chains/bootstrapping. And it’s easy to accomplish because we already have backward compatbility, so the only thing to do is avoiding to use new language features in the compiler.
It’s more complicated with using new language features in stdlib, though. Because that can be used in the compiler as well. So maybe we should also make sure the compiler compiles with an older stdlib to avoid too narrow dependencies.
Maybe even any 1.x compiler should compile with 1.0 compiler. Alternatively, even saying it should at least compile two or three versions back would be useful.
In any case, if we want to establish such a policy, we should make sure to add a CI job for that.
5 Likes
Very good point. Maybe we can/should macro the code to allow it to take advantage on new features instead of having old code around. I mean, in a major version it would be nice to be able to quickly move to the new features.
1 Like
I think the best thing to do would be to eventually write a C backend. That is, emit C code as part of the compilation instead of LLVM. With that, you can compile the compiler just by having any C compiler, no need to worry about having a previous matching Crystal version.
It seems LLVM had support for emitting C code out of llvm IR, but they eventually removed it. Then it was resurrected here: GitHub - JuliaHubOSS/llvm-cbe: resurrected LLVM "C Backend", with improvements
It would be nice to see if it works for Crystal. It would also simplify porting Crystal to other platforms.
Regarding that specific PR, I see no problem in using splats inside arrays.
I don’t follow why a C backend would simplify things. Can you explain a bit more Ary?
Regarding the compiler policy, I think is fine to require 1.x to build 1.x+1.
Keeping 1.0 as the requirement helps to bisect easily, but it would make us test less new features. And the compiler is so far the biggest crystal codebase that I think we are all dealing with. So I prefer to push for dogfooding there.
That said, if we want to keep some more versions in between I’m fine.
5 Likes
Oh, you are right, a C backend doesn’t help with this.