Re: [Vala] GSOC Idea: LLVM Backend?

[Luca Bruno <lethalman88 gmail com>]

Il 29/04/2013 10:02, pancake ha scritto:
> I think that having llvm backend instead of C will fix a lot of bugs 
> related to keyword, C macro collision and others, which cannot be 
> fixed by using the current approach. Also, compile times will benefit. 
> I doubt about runtime performance will be a point here.
>
> One of the favorable points of Vala is that it is suposed to generate 
> readable C code, which is probably the best transpiler i've seen out 
> there on this topic. But having the llvm backend will duplicate this 
> work.
>
> And this is the reason why the POSIX backend was removed, as well as 
> other attempts to make Vala generate C++ or ObjC code (already done in 
> some forks).
>
> There are 674 opened bugs in bugzilla, and the number only seems to 
> grow over the time. Many of them just need some feedback and that's 
> really annoying to me because the language is suposed to be stable for
> at least 2 years and only minor bindings fixes appears on every release..

This is not going to be fixed with an llvm backend. The C name collision 
are fixable with a quite simple rewrite, not to say it's not a critical 
issue, and it's simpler than rewriting the backend for llvm.
Also all the opened bugs are not going to be solved by the llvm backend, 
if you think so, please provide a plan for that.
The POSIX backend was removed because Vala is too gobject centric. 
Having classes and structs to work seamlessly for plain posix would 
require additional runtime code which is not the purpose of Vala, or at 
least not without a clear plan.
Also I'd like to know in what ways compile time would benefit, since 
you're going to replace the ccode tree with an llvm tree, I don't seem 
to find such a convenience.
Also notice that llvm api is c++ (and unstable), so our beloved compiler 
can't be written in vala itself. The clang C api is incomplete.

Best regards,