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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
