On Sat, 2014-04-05 at 01:03 +0400, Sergey "Shnatsel" Davidoff wrote:
Hello everyone,
Hi,
I've migrated to Vala from very high-level languages such as Python, so I always felt it would be useful to have an interactive console for Vala for quick prototyping and block-testing. More recently I'd stumbled upon LightTable IDE and was mighty impressed, but also baffled by the fact that it won't work for Vala because all its grand features only work with interpreted/JITed languages. So now I'm looking to write an interactive console for Vala :) First off, I wonder whether this was attempted before, and what were the results of those attempts. Second, knowing valac's Vala->C->assembly compilation algorithm, I can't help but wonder if I could adapt one of the existing C interpreters/consoles to work with Vala via libvala or something along those lines.
I don't know libvala API but I'd expect a bit of necessary glueing. For example:
var f = 1; // Puts var f = 1; into some template
1
f = f + 1; // The original template is likely to fail -
// you need to have f in scope It should be feasible though.
Layering the Vala-to-C translator atop an existing C interpreter would not only save a lot of work but also give the resulting Vala interpreter the same error checking and reporting behavior as valac has now, so at first glance this avenue looks very promising. I'd love to hear any comments on the feasibility of this approach, especially from people familiar with the Vala-to-C translator. If the above fails, writing a language frontend for some virtual machine (LLVM, JVM, etc) is also an option. A full-blown LLVM language frontend is probably beyond my skill at the moment, but might be a nice collaborative project if there's interest in having such a thing.
I've been looking on LLVM from slightly different perspective
(optimization). Unfortunatly the Vala piggy backs on C heavily so it's
hard. For example code:
int main() {
return GLib.FOO;
}
The VAPI file does not describe what the FOO is - only its type. It can
be a variable but it can be a macro. While the former is easy to handle
the latter needs to go through C preprocessor.
The best I came up with for the LLVM backend to Vala[1] is to have a
clang compile the stubs for VAPI and then (hopefully) LTO will optimize
it. Since it was large amount of work I just started to try to detect
the Vala-specific opportunities for optimization by naming but it hasn't
go anywhere yet[2].
If the initial prototypes looks promising I'll be able to start the real work on this in September since I've already signed up for Google Summer of Code with another project. Thanks in advance, -- Sergey "Shnatsel" Davidoff
Best regards [1] I.e. Vala is a frontend and LLVM is a backend [2] Main problem I found is that C++, especially the LLVM style, is not exactly best for quick prototyping. While I understand many reasons why something was done in one way or another in many cases I just wanted to quickly prototype.
Attachment:
signature.asc
Description: This is a digitally signed message part