[ANN] LuaGravity 0.5

[fsanbr]

I'm pleased to announce the release of LuaGravity 0.5.
LuaGravity is a reactive language that implements the synchronous approach for concurrency.
It is roughly based on Esterel and FrTime, two synchronous languages, the former having an imperative style, the latter being functional.
LuaGravity is implemented as a set of runtime extensions to the Lua language.

Currently, it works only with DirectFB, but I would love to see it integrated with LÖVE someday.
I believe synchronous concurrency matches perfectly with games.

Homepage: http://www.lua.inf.puc-rio.br/luagravity/

--
Francisco Sant'Anna

[subrime]

Could you explain how this counts as concurrency?

How would more than one event be triggered at a given time?

And if things are limited to non-simultaneous events and your reactors are forced to act atomically, how will the program ever have more than one active execution point at a given time?

Am I misunderstanding concurrency (which I take to mean two or more things happening at a time)?

[fsanbr]

Concurrency (for me) is an abstract idea in which two things (processes, reactors, etc) happen at the same time and you (as an external viewer) cannot be sure about the exact order they execute.

In *asynchronous* concurrency, which most languages follow, these things (processes, actors, etc) are by default not aware of each other, each having its own notion of time. When these things need to synchronize, they use a special primitive for it (locks, message passing, etc).

In synchronous concurrency, these things (reactors, callbacks, etc) are always synchronized on a global time (i.e. events, clock tick), meaning that one thing cannot proceed to the next time while others are still processing the current time.
So, going back to LuaGravity, if two reactors are triggered due to the same event and do not depend on each other, they are running concurrently---the order in which they run is arbitrary.

You cannot have more than one event triggered at a time because events are the *exact* notion of time in synchronous languages (discrete time).

Parallelism, which is different from concurrency (again, in my point of view), LuaGravity *does not* provide.
The research version of LuaGravity (you can find info in the research paper), which is 100% deterministic, also allows parallelism between concurrent reactors (but never between different events).

Hope to have clarified the semantics of synchronous languages.

Regards,
Francisco

[subrime]

Thanks for clearing up what you mean by concurrency.

While your explanation makes sense in terms of events, time and reactors, I'm a little unsure about global effects... This example may demonstrate:

0) two reactors are linked to an event
1) the event occurs
2) one of the reactors runs and sets a global (eg a=10)
3) the other reactor runs and sets the same global differently (eg a=5)
4) time moves on... print(a) ( -> 5)

In this case an arbitrary running order for the two reactors means the value of the global is not conceptually deterministic. Without some kind of locking mechanism it seems like the only way to achieve a predictable result is to limit access to global variables.

Is this a part of the system or am I still missing something?

[fsanbr]

LuaGravity is *not* deterministic (see http://www.lua.inf.puc-rio.br/luagravit ... eterminism, there are other examples of non-determinism).
Your reasoning is perfect, you cannot be sure about the value of `a`.

Locking does not guarantee determinism, but only safe access to memory in critical sections.
The multi-threaded program below is still non-deterministic (`a` can yield 24 or 22).

Code: Select all

a = 10
threadA {
    lock {
        a = a + 2
   }
}
threadB {
    lock {
        a = a * 2
    }
}
start(threadA)
start(threadB)

There are no critical sections in LuaGravity, as all execution in reactors is already atomic.
Hence, no needs for locks.
(This is only possible because we assume zero-delay execution. Notice that this also applies to event-driven programming.)

Back to the limitation you raised, some people say that in event-driven programming the result would be deterministic, as you control the registering order of callbacks.
In LuaGravity we could also respect the order of `link` calls, however we still believe that a program like this *is wrong*: An external viewer cannot sense two values for the same thing at the same time (event is time).
Actually, in the research version of LuaGravity (see the paper) we raise a runtime error saying that the application is non-deterministic.
We removed this error feature due to performance and complexity, after realizing that natural programs usually don't have this kind of "bug".
(That all said, there are some applications where you do want non-determinism.)

Esterel is deterministic, but it only allows one "reactor" (I think he uses the term "process") to change the value of a variable.

[subrime]

Please forgive my bluntness, but for a system like love (which already provides a callback environment), and a language like lua (with coroutines), what is the point of LuaGravity?

[fsanbr]

With callbacks one must deal with inversion of control (no control of flow) and stack ripping (no locals).
In the other hand, coroutines by themselves do not behave reactively---the programmer must explicitly call and resume them.
Callbacks and coroutines are preconditions to a system such as LuaGravity, which tries to reconcile them transparently.

From an implementation point of view, basically LuaGravity is a layer on top of coroutines and event-driven programming.
We treat coroutines as kind of events so that you can link or await them. It's like saying on a `yield` which event/time/reactor should resume the coroutine afterwards.

Another facility are reactive expressions with support for variables, function lifting, integrations/derivatives and glitches avoidance.
(See the language FrTime/Functional Reactive Programming or http://www.lua.inf.puc-rio.br/luagravit ... xpressions.)

There are some examples of LuaGravity at http://www.lua.inf.puc-rio.br/luagravit ... n_examples.
You'll notice the absence of if's in the two first applications. If's are very common when using callbacks, where you must all the time decode/re-encode the current state of the program residing in heap objects.

Well, in 15 lines this is the best I can do.
I encourage you to try LuaGravity eventually.

-- Francisco