[Vala] Roadmap for extending Vala's reach



Hello all!

We currently have a very promiscous relationship with GLib and I would
like to propose some changes to make this more explicit.

Each --pkg argument would consist of a VAPI and a compiler plugin (from
wip/transform) for generating specific code and extending the language
syntax. One optional plugin per package seems sane to me.

No --pkg arguments at all:

 * basic Vala syntax
 * basic C codegen
 * standard C types (int, uint -> unsigned int, char, uchar, ...)
 * no API

At this point, one could introduce a different set of definitions for
supporting, let's say, a micro-controller C standard library in just a
matter of a --pkg flag.

With --pkg=posix

 * posix C API

With --pkg=glib-2.0

 * shadowed standard C types in GLib.* namespace, which would become in
   default with a 'using GLib;' declaration
 * GLib C API
 * support for basic introspection (--gir and the like)

No more imlicit 'using GLib;'. However, including it would shadow all
the numerical types and produce a nice GLib-friendly API.

With --pkg=gobject-2.0 

 * GObject API
 * typeof
 * signals
 * support for advanced introspection

With --pkg=gio-2.0 

 * GIO API
 * asynchronous primitives
 * DBus code generator

With --pkg=gtk-3.0

 * GTK API
 * [GtkBuilder] annotations

We can have a pure Posix C backend and compile anything with:

    valac --ccode --pkg=posix main.vala

    public int main () {} => int main (void) {}

Or if one would like to target Emscripten platform:

    valac --ccode --pkg=emscripten main.vala

    public int main () {} => #include<emscripten.h> int main (void) {}

For usual GLib code:

    valac --ccode --pkg=glib-2.0 main.vala

    using GLib;

    public int main () {} => gint main (void) {}

It would be breaking stuff that is not explicitly using --pkg=glib-2.0
and 'using GLib'. We could actually use the '--nostdpkg' switch to sort
of reset the compiler down to it's most basic feature set and wait
until 1.0 to drop it and have some good defaults.

At first, it would be to make --nostdpkg work flawlessly while
preserving entire backward-compatibility. That'll be good for a minor
release.

Tell me what you think about this!

-- 
Guillaume Poirier-Morency <guillaumepoiriermorency gmail com>

Étudiant au baccalauréat en informatique à l'Université de Montréal
Stagiaire de recherche à l'IRIC

Mon blog: https://arteymix.github.io/
Clé PGP: B1AD6EA5

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]