[Vala] Gel: Glib-Embedded-Language

[pancake <pancake youterm com>]

Hi again,

I've been reading a bit more of gel. I thought it was generating C code, 
but it is interpreted,
so it takes no sense to merge it in Vala. But I still think that having 
a lispy syntax for
Vala would be great.

About brackets vs parenthesis. You say in README that you choose [] 
because they are
easier to type. Thats not true at all, it depends on the keyboard and 
the layout. it's ok
for a PC keyboard with english layout, but not for spanish for example, 
and on smartphone
keyboards () are more accessible than [].

And for readability I think that () looks better than [].

I would love to see a REPL interface in Gel.

Nice work :D the idea of being able to access any objects from a running 
application using
a GObject-based lisp-like language sounds great.

--pancake

On 01/18/11 21:26, Sandino Flores Moreno wrote:
> My grain of salt.
>
> I started, just for fun, a programming language for glib named gel:
> https://github.com/tigrux/gel
>
> And the benchmark I made, calculates all the primes between 2 and 50k.
> https://github.com/tigrux/gel/blob/master/comparison/primes.gel
>
>
> [var sieve [array]]
>
> [for n [range 2 50000]
>      [if [all [lambda [i] [% n i]] sieve]
>          [append sieve n]
>      ]
> ]
>
> [print "Calculated " [len sieve] " primes"]
>
> [quit]


> 1) In the first stages, it used gobjects, it was taking around 2 minutes.
>
> 2) Then, I moved to use only compact classes, the time decreased to 40 seconds.
>
> 3) After that, I implemented a mechanism to reuse objects, based on a pool,
> to avoid calls to g_new, g_free and g_hash_table_new. It then
> decreased to 30 seconds.
> (that mechanism is currently out of git, because conflicted other experiments)
>
> 4) Finally, instead of using g_value_get_int, g_value_set_double, etc
> I used macros
> to directly get the fields from the GValue structure. The time
> decreased from 30 to 20 seconds.
>
> The same code, in python, takes only 2 seconds.
>
> So, no matter if your code is in C or not, there is always lot of room
> for improvements,
> specially because GLib/GObject tends to have much code to validate and be safe,
> that make it slow but trustful.
>
>
>
>
> 2011/1/18 Jan Hudec<bulb ucw cz>:
> > On Tue, Jan 18, 2011 at 09:18:06 -0300, Erick Pérez Castellanos wrote:
> > > I haven't prove it but theoretically can't be slower since Mono
> > > applications are running on the top of a virtual machine and Vala
> > > applications are native code executed, so kinda hard to think that
> > > Mono is faster than Vala, eh !!!
> > Theoretically, that's not true.
> >
> > Good just-in-timing run core can run virtual machine code at almost the same
> > speed as native code. And a good garbage-collector is faster than malloc/free
> > (it pays some cost for surviving object, but for many short-lived objects, it
> > is a lot faster) and compacts the working set, which improves cache
> > performance. And these days, memory access cost as much as tens of
> > instructions, so cache performance can make huge difference.
> >
> > Of course the cost of using garbage collector is bigger memory consumption,
> > because the objects are not recycled immediately.
> >
> > --
> >                                                  Jan 'Bulb' Hudec<bulb ucw cz>
> > _______________________________________________
> > vala-list mailing list
> > vala-list gnome org
> > http://mail.gnome.org/mailman/listinfo/vala-list
> _______________________________________________
> vala-list mailing list
> vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list