Re: [Vala] GSOC Idea: LLVM Backend?

[pancake <pancake youterm com>]

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..

On 04/29/13 09:26, Luca Bruno wrote:
> Il 29/04/2013 06:13, Kenny Micklas ha scritto:
> > Hi all,
> >
> > I am a student at Brown University interested in participating in Google
> > Summer of Code. I am a Vala enthusiast and I have always been
> > interested in
> > the idea of writing an LLVM code generator for valac. The principle
> > benefits of this would be decoupling Vala from C, increased
> > flexibility in
> > the generated code, vastly better compile times, and potentially better
> > runtime performance too.
> >
> > I know this is not one of the suggested GSOC ideas for GNOME, but I was
> > wondering if the Vala team would think this is a good project, and
> > whether
> > or not there would be an appropriate mentor. If so, I will write up a
> > full
> > proposal for GSOC.
> Hi,
> thanks for your interest in vala.
> I'm not a possible mentor, but I have to say that an llvm code generator
> might not be of high value.
> The points you rised are rather marketing ideas rather than real useful
> gains.
> First of all, why flexibility in generated code?
> Then, about compile times, you can just compile the generated C code
> with clang... same goes for runtime performance.
>
> On the other hand, there's a wip/transform branch in vala. The purpose
> of the branch is to introduce an intermediate step for transforming the
> ast. For example, the current gdbus module works more on the C level,
> while with this branch you rewrite the vala ast into another vala ast
> calling dbus methods.
> That is you write vala inside the vala compiler itself.
> Potential: allow other transformers similar to [DBus], for example
> [RPC], or [Protobuf], or [DBTable], or whatever. That opens to a
> possible plugin system where each plugin can change the behavior of the
> vala code.
> The branch itself works quite well, it needs to be tested on existing
> vala projects to ensure there are no regressions, as well as adding new
> features and a plugin system.
> I don't know if this could be a gsoc project or not.
>
> Best regards,
> _______________________________________________
> vala-list mailing list
> vala-list gnome org
> https://mail.gnome.org/mailman/listinfo/vala-list