[Vala] Proposal: ValaScript

[Yu Feng <rainwoodman gmail com>]

Dear All,

I am thinking about a subset or variation of Vala: Valascript.
(the proposed) Valascript is almost a subset of Vala:

* cannot define Classes and explicit functions
* Strong type checking; type inferring.
* Direct access to GLib based libraries via vala vapi mechanism
* Possibly with a garbage collector.
* Named lambda functions -- this will be the way most valascripts
define functions; need to extend the current lambda function support in
Vala first.
* session code block, i.e, statements not wrapped in any function body.
* Interpreted language
 
A sample session illustrating the idea(suppose >> is the prompt, and in
an interactive session)

> > Using Gtk;
> > lambda void* thread_func = (void* ) => {
&>   MainLoop loop = new MainLoop(NULL, true);
&>   loop.run();
&>   return NULL;
&> };
> > Thread::create(thread_func, false);
> > var window = new Gtk.Window();
> > var button = new Gtk.Button.with_label("this is a button");
> > window.add(button);
> > button.clicked += (sender) => {
&>   message("button clicked");
&> };
> > window.show();
> > # click the button and see
button clicked
> > lambda double f = (double x) => {
&>   return x*x;
&>   };
> > message("%lf", f(3.14));
9.86

The reason that a thread is required to run the mainloop separately is
because the script is ran in the thread of the interpreter, and (1)
there is no mainloop in the interpreter; (2) we don't want to block the
interaction with the window.

An alternative design is to always implicitly create a mainloop in the
interpreter, then let the interactive shell and the script share the
same mainloop. It is not very safe though.


Yu